[Rd] R-2.3.1 MacOSX segfault (PR#9014)
Full_Name: Diego Diez
Version: 2.3.1
OS: Mac OSX 10.4.6
Submission from: (NULL) (133.103.101.222)
When running R in a X11 terminal, and trying to download a file with a wrong url
with method "internal", R segfaults. This does not happen when using R.app with
same method (??) or using "wget" method.
For example:
> download.file("http://cran.cnr.Berkeley.edu/bin/macosx/powerpc/contrib/2.3/foo.tgz";,
"foo.tgz")
trying URL 'http://cran.cnr.Berkeley.edu/bin/macosx/powerpc/contrib/2.3/foo.tgz'
*** caught segfault ***
address 0x5f4d4550, cause 'memory not mapped'
Traceback:
1:
download.file("http://cran.cnr.Berkeley.edu/bin/macosx/powerpc/contrib/2.3/foo.tgz";,
"foo.tgz")
Possible actions:
1: abort (with core dump)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection:
My session info.
> sessionInfo()
Version 2.3.1 (2006-06-01)
powerpc-apple-darwin8.6.0
attached base packages:
[1] "methods" "stats" "graphics" "grDevices" "utils" "datasets"
[7] "base"
Thanks.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] loading library from network share (PR#8982)
This is not supported: network shares are a Windows 'feature' and not part
of R's conception of file paths. The specific issue here is dirname(),
but it is widespread.
You can always map shares to network drives, and that is common practice
everywhere I have been which has extensive Windows networks.
We have changed the dirname case, but have no intention of supporting this
sort of file path in general, as one of the design goals of the Windows
port of R was to work as similarly to the Unix-alikes as possible (and to
share as much code as possible).
On Wed, 14 Jun 2006, [EMAIL PROTECTED] wrote:
> Full_Name: roy kuraisa
> Version: 2.2.1
> OS: Windows XP SP2
> Submission from: (NULL) (155.91.28.232)
>
>
> When loading a library from network share drive (e.g., \\nnn\f1\f2\p1), when
> First.lib is called, the libray name contains "/" instead of "\" resulting in
> an
> invalid Windows filepath.
>
> Here's an example:
>> From R,
>> library(foo.lib="kodak\\research_genetics\\rlibs");
> Within First.lib,
> .First.lib <-function(lib, pkg)
> {
>cat("lib name ",lib,"\n")
> }
> produces the output
> lib name //kodak/research_genetics/rlibs
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Error Condition Re: Invalid request
>This is a multi-part message in MIME format. Unrecognized request THIS Report any problems to '[EMAIL PROTECTED]'. For a list of the available requests send a message to [EMAIL PROTECTED] with a body consisting of nothing but the word HELP PS: Any subsequent requests that you might have submitted have been ignored. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] package compile error on RHEL x86_64 - FIXED
For the record: The error below has been resolved. As Professor Ripley said, it was a compiler problem. Upgrading to a more recent gcc rpm (gcc-3.4.5-2) and its dependencies made the errors go away. Thanks, Dan On 6/14/06, Dan Lipsitt <[EMAIL PROTECTED]> wrote: > I am unable to install the gmp package on an x86_64 (Xeon) machine. I > have had the same problem with other packages (eg. MCMCpack) as well. > I am running Red Hat Enterprise Linux 4.1. > I get the following error: > > g++ -shared -L/usr/local/lib64 -o gmp.so biginteger.o > biginteger_operator.o bigintegerR.o bigrational.o > bigrational_operator.o bigrationalR.o factor.o -L/usr/local/lib/ -lgmp > /usr/bin/ld: > /usr/lib/gcc/x86_64-redhat-linux/3.4.3/libstdc++.a(functexcept.o): > relocation R_X86_64_32 against `std::bad_exception::~bad_exception()' > can not be used when making a shared object; recompile with -fPIC > /usr/lib/gcc/x86_64-redhat-linux/3.4.3/libstdc++.a: could not read > symbols: Bad value > > However, I have found that if I run "R CMD SHLIB" twice in the src/ > directory, once to build the .o files, and once to link, I can build > the shared library. If I run it on the .o files instead of the .cc > files it uses gcc instead of g++. This appears to be the change that > allows the lib to build. "-fPIC" seems to have nothing to do with it. > > So my question is: How do I get "R CMD INSTALL" to link with gcc > instead of g++? I have tried adding "LINK.cc = $(LINK.c)" to the top > of src/Makevars.in and then running "R CMD check" in the top dir of > the package, but it uses g++ anyway. Any other fix or workaround > suggestions would be appreciated as well. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] loading library from network share (PR#8982)
Thanks for the info.
It's interesting that R can load the library using a network share naming
convention but that the library path has the "\" replaced with "/". I guess
it's too much to ask for R not to muck with the file name provided (for a
variety of reasons). My package works fine except for knowing the correct
library path.
As for mapping a drive, that's not a good solution for us because it would
require users to always create a specific map drive (which on their desktop
may not be available; when we add packages to other network shares, requires
additional maps; etc). Overall, it's not a very flexible solution for us.
My work around which, at least in my unique case, is a bit more flexible
(but a little more klunky) is to add code in .First.lib that substitutes
"\\" for "//" (because I need to read a cfg file in the "data" folder of the
package when it is loaded).
cheers, roy
-Original Message-
From: Prof Brian Ripley [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 21, 2006 1:57 AM
To: Kuraisa, Roy J (Rosetta)
Cc: [EMAIL PROTECTED]
Subject: Re: [Rd] loading library from network share (PR#8982)
This is not supported: network shares are a Windows 'feature' and not part
of R's conception of file paths. The specific issue here is dirname(),
but it is widespread.
You can always map shares to network drives, and that is common practice
everywhere I have been which has extensive Windows networks.
We have changed the dirname case, but have no intention of supporting this
sort of file path in general, as one of the design goals of the Windows
port of R was to work as similarly to the Unix-alikes as possible (and to
share as much code as possible).
On Wed, 14 Jun 2006, [EMAIL PROTECTED] wrote:
> Full_Name: roy kuraisa
> Version: 2.2.1
> OS: Windows XP SP2
> Submission from: (NULL) (155.91.28.232)
>
>
> When loading a library from network share drive (e.g., \\nnn\f1\f2\p1),
when
> First.lib is called, the libray name contains "/" instead of "\" resulting
in an
> invalid Windows filepath.
>
> Here's an example:
>> From R,
>> library(foo.lib="kodak\\research_genetics\\rlibs");
> Within First.lib,
> .First.lib <-function(lib, pkg)
> {
>cat("lib name ",lib,"\n")
> }
> produces the output
> lib name //kodak/research_genetics/rlibs
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] loading library from network share (PR#8982)
On Wed, 21 Jun 2006, [EMAIL PROTECTED] wrote:
> Thanks for the info.
>
> It's interesting that R can load the library using a network share naming
> convention but that the library path has the "\" replaced with "/". I guess
> it's too much to ask for R not to muck with the file name provided (for a
> variety of reasons). My package works fine except for knowing the correct
> library path.
>
> As for mapping a drive, that's not a good solution for us because it would
> require users to always create a specific map drive (which on their desktop
> may not be available; when we add packages to other network shares, requires
> additional maps; etc). Overall, it's not a very flexible solution for us.
It can easily be done via the domain controller: my sysadmins do it.
> My work around which, at least in my unique case, is a bit more flexible
> (but a little more klunky) is to add code in .First.lib that substitutes
> "\\" for "//" (because I need to read a cfg file in the "data" folder of the
> package when it is loaded).
This should work now that I have changed dirname (to do precisely that),
but as I have no suitable test examples I cannot be sure.
>
>
> cheers, roy
>
>
> -Original Message-
> From: Prof Brian Ripley [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, June 21, 2006 1:57 AM
> To: Kuraisa, Roy J (Rosetta)
> Cc: [EMAIL PROTECTED]
> Subject: Re: [Rd] loading library from network share (PR#8982)
>
>
> This is not supported: network shares are a Windows 'feature' and not part
> of R's conception of file paths. The specific issue here is dirname(),
> but it is widespread.
>
> You can always map shares to network drives, and that is common practice
> everywhere I have been which has extensive Windows networks.
>
> We have changed the dirname case, but have no intention of supporting this
> sort of file path in general, as one of the design goals of the Windows
> port of R was to work as similarly to the Unix-alikes as possible (and to
> share as much code as possible).
>
> On Wed, 14 Jun 2006, [EMAIL PROTECTED] wrote:
>
>> Full_Name: roy kuraisa
>> Version: 2.2.1
>> OS: Windows XP SP2
>> Submission from: (NULL) (155.91.28.232)
>>
>>
>> When loading a library from network share drive (e.g., \\nnn\f1\f2\p1),
> when
>> First.lib is called, the libray name contains "/" instead of "\" resulting
> in an
>> invalid Windows filepath.
>>
>> Here's an example:
>>> From R,
>>> library(foo.lib="kodak\\research_genetics\\rlibs");
>> Within First.lib,
>> .First.lib <-function(lib, pkg)
>> {
>>cat("lib name ",lib,"\n")
>> }
>> produces the output
>> lib name //kodak/research_genetics/rlibs
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>
>
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] is.Rs_own_BLAS() ?
Does anyone see a nice portable way to detect --- from inside R ---
if R is using its own BLAS or not?
{ And ideally, if not, can R find out which ``kind'' of
(optimized) BLAS it does run? }
And the same for LAPACK ?
One way of getting a partial answer seems to be
Rs_own_LAPACK_and_BLAS <-
list.files(file.path(R.home(), "lib"), pattern = "^libRlapack") > 0
(where I'd be grateful for confirmation from a Mac and a Windows user
that the above does work)
The reason for asking is a plan of a somewhat automated speed
comparison simulation which seems to depend quite a bit on the
architecture and the version of BLAS it uses.
Martin Maechler, ETH Zurich
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] is.Rs_own_BLAS() ?
On Wed, 21 Jun 2006, Martin Maechler wrote:
> Does anyone see a nice portable way to detect --- from inside R ---
> if R is using its own BLAS or not?
> { And ideally, if not, can R find out which ``kind'' of
> (optimized) BLAS it does run? }
>
> And the same for LAPACK ?
>
> One way of getting a partial answer seems to be
>
> Rs_own_LAPACK_and_BLAS <-
>list.files(file.path(R.home(), "lib"), pattern = "^libRlapack") > 0
>
> (where I'd be grateful for confirmation from a Mac and a Windows user
> that the above does work)
Not possible: R on Windows has a plug-in BLAS, and Simon has asked for the
same on MacOS X. And the BLAS and LAPACK are DLLs stored in R_HOME/bin,
not import libraries stored on R_HOME/lib (which no longer exists).
There are even architecture-specific Rblas.dll on CRAN (and have been for
some years).
Brian
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Suggestion for all.equal.factor
R-Devel,
all.equal.factor gives a warning message when comparing vectors of
factors of different lengths. I suspect this to be unintentional as I
believe tests of valid factors should be comparable without a warning.
For example:
> x1 <- as.factor(LETTERS)
> x2 <- as.factor(LETTERS)[1:10]
> all.equal.factor(x1, x2)
[1] "Lengths: 26, 10"
[2] "Lengths (26, 10) differ (string compare on first 10)"
Warning message:
longer object length
is not a multiple of shorter object length in: nax != nay
If it is not improper to compare objects of different lengths, I would
like to propose the following patch that removes this warning without
otherwise changing the behavior of all.factor.equal.
- if(n <- sum(nax != nay))
+ if(n <- length(nax) == length(nay) && sum(nax != nay))
My assumption here is that it is not meaningful to compare NA mismatches
on vectors of different lengths. Also, if the vectors do have different
lengths then this will be reported in the first line anyway.
Best,
Robert
> R.version
_
platform i386-pc-mingw32
arch i386
os mingw32
system i386, mingw32
status
major 2
minor 3.1
year 2006
month 06
day01
svn rev38247
language R
version.string Version 2.3.1 (2006-06-01)
Robert McGehee
Quantitative Analyst
Geode Capital Management, LLC
53 State Street, 5th Floor | Boston, MA | 02109
Tel: 617/392-8396Fax:617/476-6389
mailto:[EMAIL PROTECTED]
This e-mail, and any attachments hereto, are intended for us...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] .Call and data frames
Hello,
I'm trying to fetch a data frame through the C API,
and have no problem doing this when all columns
are numbers, but when there is a column of
strings I have a problem. On the C-side the
function looks like:
SEXP myfunc(SEXP df),
and it is called with a dataframe from
the R side with:
.Call("myfunc", somedataframe)
On the C side (actually C++ side) I use code
like this:
SEXP colnames = getAttrib(df, R_NamesSymbol)
cname = string(CHAR(STRING_ELT(colnames,i))
SEXP coldata = VECTOR_ELT(df,i) (data for i-th column)
if(isReal(colData))
x = REAL(colData)[j];
else if(isInteger(colData))
i = INTEGER(colData)[j];
else if(isString(colData))
s = CHAR(STRING_ELT(colData,j))
The problem is that the last test (isString) never passes,
even when I pass in a frame for which one or more cols
contain character strings. When the column contains
strings the isVector(colData) test passes, but no matter
how I try to fetch the string data I get a seg fault. That
is, forcing CHAR(STRING_ELT(colData,j)) will
fault, and so will VECTOR_ELT(colData,0), even
though colData passes the isVector test.
Any ideas?
Thanks,
ds
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] .Call and data frames
While I do not know how to handle this on the C level, I know that
you do not have characters in data frames, everything is factors
instead. Internally they are coded as a number of integer levels,
with the levels having labels (which is the character you see). So eg
(in R):
> test <- data.frame(tmp = letters[1:10])
> test
tmp
1a
2b
3c
4d
5e
6f
7g
8h
9i
10 j
> is.character(test$temp)
[1] FALSE
> as.numeric(test$tmp) # The internal code of the factor
[1] 1 2 3 4 5 6 7 8 9 10
> levels(test$tmp) # gives you the translation from internal code to
actual label
[1] "a" "b" "c" "d" "e" "f" "g" "h" "i" "j"
You probably need to convert the factor to a character, which I do
not know how to do in C on top of my head, but which is probably not
that difficult. At least now you should have some idea on where to look.
/Kasper
On Jun 21, 2006, at 10:07 PM, Dominick Samperi wrote:
> Hello,
>
> I'm trying to fetch a data frame through the C API,
> and have no problem doing this when all columns
> are numbers, but when there is a column of
> strings I have a problem. On the C-side the
> function looks like:
> SEXP myfunc(SEXP df),
> and it is called with a dataframe from
> the R side with:
>
> .Call("myfunc", somedataframe)
>
> On the C side (actually C++ side) I use code
> like this:
> SEXP colnames = getAttrib(df, R_NamesSymbol)
> cname = string(CHAR(STRING_ELT(colnames,i))
> SEXP coldata = VECTOR_ELT(df,i) (data for i-th column)
> if(isReal(colData))
> x = REAL(colData)[j];
> else if(isInteger(colData))
> i = INTEGER(colData)[j];
> else if(isString(colData))
> s = CHAR(STRING_ELT(colData,j))
>
> The problem is that the last test (isString) never passes,
> even when I pass in a frame for which one or more cols
> contain character strings. When the column contains
> strings the isVector(colData) test passes, but no matter
> how I try to fetch the string data I get a seg fault. That
> is, forcing CHAR(STRING_ELT(colData,j)) will
> fault, and so will VECTOR_ELT(colData,0), even
> though colData passes the isVector test.
>
> Any ideas?
> Thanks,
> ds
>
> __
> 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] .Call and data frames
On Wed, 21 Jun 2006, Kasper Daniel Hansen wrote:
> While I do not know how to handle this on the C level, I know that
> you do not have characters in data frames, everything is factors
> instead.
Not so. The default in data.frame() is to convert character vector to
factors, but there are many ways to have character vectors in data frames,
and this will become more common in 2.4.0 and later.
I suspect that this may well be Dominick's problem, though.
isVector is just a test of being one of the several types of vectors:
VECTOR_ELT is only appropriate for a VECSXP (a R-level list) and for this
sort of thing it is much safer and cleaner to test TYPEOF.
> Internally they are coded as a number of integer levels,
> with the levels having labels (which is the character you see). So eg
> (in R):
>
> > test <- data.frame(tmp = letters[1:10])
> > test
>tmp
> 1a
> 2b
> 3c
> 4d
> 5e
> 6f
> 7g
> 8h
> 9i
> 10 j
> > is.character(test$temp)
> [1] FALSE
> > as.numeric(test$tmp) # The internal code of the factor
> [1] 1 2 3 4 5 6 7 8 9 10
> > levels(test$tmp) # gives you the translation from internal code to
> actual label
> [1] "a" "b" "c" "d" "e" "f" "g" "h" "i" "j"
>
> You probably need to convert the factor to a character, which I do
> not know how to do in C on top of my head, but which is probably not
> that difficult. At least now you should have some idea on where to look.
>
> /Kasper
>
>
> On Jun 21, 2006, at 10:07 PM, Dominick Samperi wrote:
>
>> Hello,
>>
>> I'm trying to fetch a data frame through the C API,
>> and have no problem doing this when all columns
>> are numbers, but when there is a column of
>> strings I have a problem. On the C-side the
>> function looks like:
>> SEXP myfunc(SEXP df),
>> and it is called with a dataframe from
>> the R side with:
>>
>> .Call("myfunc", somedataframe)
>>
>> On the C side (actually C++ side) I use code
>> like this:
>> SEXP colnames = getAttrib(df, R_NamesSymbol)
>> cname = string(CHAR(STRING_ELT(colnames,i))
>> SEXP coldata = VECTOR_ELT(df,i) (data for i-th column)
>> if(isReal(colData))
>> x = REAL(colData)[j];
>> else if(isInteger(colData))
>> i = INTEGER(colData)[j];
>> else if(isString(colData))
>> s = CHAR(STRING_ELT(colData,j))
>>
>> The problem is that the last test (isString) never passes,
>> even when I pass in a frame for which one or more cols
>> contain character strings. When the column contains
>> strings the isVector(colData) test passes, but no matter
>> how I try to fetch the string data I get a seg fault. That
>> is, forcing CHAR(STRING_ELT(colData,j)) will
>> fault, and so will VECTOR_ELT(colData,0), even
>> though colData passes the isVector test.
>>
>> Any ideas?
>> Thanks,
>> ds
>>
>> __
>> 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
>
>
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
