[Rd] Reading clipboard with read.delim("clipboard") crash (PR#13957)
Full_Name: Liam Gretton
Version: 2.9.2
OS: openSUSE 11.1 (x86_64)
Submission from: (NULL) (143.210.13.77)
Reading a large number of rows of delimited data via the clipboard results in a
segfault or double free error. I've tested copying from various applications,
but gedit will do.
This problem exists in the openSUSE-supplied 2.8.1, I've just built 2.9.2 to see
if it's still there, and it is.
I can provide an example delimited file which demonstrates the problem; it
contains about 18000 rows and 7 columns of data. read.delim("clipboard") tends
to fail when only reading ~1500 rows, though I haven't been able to reproduce
the point at which it fails.
Reading exactly the same data from a file using read.csv("file.csv") is
successful.
Problem reproduced as so:
Data copied to the clipboard in Gnome.
> R
R version 2.9.2 (2009-08-24)
[snip]
> data <- read.delim("clipboard")
*** caught segfault ***
address 0x18, cause 'memory not mapped'
Traceback:
1: file(file, "r")
2: read.table(file = file, header = header, sep = sep, quote = quote, dec =
dec, fill = fill, comment.char = comment.char, ...)
3: read.delim("clipboard")
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
On a different (but similar) openSUSE 11.1 system, the command still fails but
reports:
*** glibc detected *** /usr/local/R-2.9.2/lib64/R/bin/exec/R: double free of
corruption (!prev): 0x0097cb70 ***
Details of R build:
./configure --prefix=/usr/local/R-2.9.2 --enable-R-shlib --enable-mbcs
--enable-threads=posix --with-blas --with-lapack --with-system-zlib
--with-system-bzlib --with-system-pcre --with-gnu-ld
No additional packages installed. 'make check' passed.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] basename returns "." not in filename (PR#13958)
Full_Name: Jens Oehlschlägel
Version: 2.9.2
OS: Win32
Submission from: (NULL) (85.181.152.156)
# Obviously an empty basename is allowed (if the filepath is a pure path)
> basename("/")
[1] ""
# but here we get the dot from the path
> basename("./")
[1] "."
> version
_
platform i386-pc-mingw32
arch i386
os mingw32
system i386, mingw32
status
major 2
minor 9.2
year 2009
month 08
day24
svn rev49384
language R
version.string R version 2.9.2 (2009-08-24)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] winbuilder down
Dear developers, the winbuilder service and CRAN windows binary package built service will be down for roughly 60 hours from now on due to a whole-weekend power outage in our floor. Best wishes, Uwe Ligges __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] basename returns "." not in filename (PR#13958)
jo...@web.de wrote:
> Full_Name: Jens Oehlschlägel
> Version: 2.9.2
> OS: Win32
> Submission from: (NULL) (85.181.152.156)
>
>
> # Obviously an empty basename is allowed (if the filepath is a pure path)
>> basename("/")
> [1] ""
>
> # but here we get the dot from the path
>> basename("./")
> [1] "."
Command line utility does likewise:
viggo:~/>basename ./
.
Point is, I gather, that trailing slashes are removed, e.g.,
viggo:~/>basename foo/
foo
So, not a bug.
--
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
Re: [Rd] basename returns "." not in filename (PR#13958)
On Sep 18, 2009, at 12:11 , Peter Dalgaard wrote:
jo...@web.de wrote:
Full_Name: Jens Oehlschlägel
Version: 2.9.2
OS: Win32
Submission from: (NULL) (85.181.152.156)
# Obviously an empty basename is allowed (if the filepath is a pure
path)
basename("/")
[1] ""
# but here we get the dot from the path
basename("./")
[1] "."
Command line utility does likewise:
viggo:~/>basename ./
.
Point is, I gather, that trailing slashes are removed, e.g.,
viggo:~/>basename foo/
foo
So, not a bug.
Indeed. The rationale is that foo/bar/ specifies a directory "bar" at
the path "/foo", hence the name is "bar" ("" would make no sense of
course).
Cheers,
Simon
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 2.10.0 Under development (unstable) (2009-09-15 r49711) just built segfaults on Debian Squeeze
I've just committed (r49747) some changes that should fix the re-entrancy bug Mark reported the other day. The problem was that R reads some files (e.g. Mark's .Rprofile) in a read-eval-print loop, and only parses them a few lines at a time. This means that within that loop, one of the evals could cause it to start parsing something else. One of the changes I put in a few days ago got confused by this. Hopefully the latest change hasn't introduced a new bug... BTW, one of the effects of this change is that a syntax error in .Rprofile should now be reported on the correct line number. In R 2.9.x the line number was relative to the current statement, so it was pretty meaningless. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] basename returns "." not in filename (PR#13958)
Mmh,
> > Point is, I gather, that trailing slashes are removed, e.g.,
> >
> > viggo:~/>basename foo/
> > foo
> >
> > So, not a bug.
This unfortunately means that we cannot distinguish between
1) a path with a filename
2) a path without a filename
For example in the next version of the ff-package we allow a user to specify a
'pattern' for all files of a ff dataframe which is path together with a
fileprefix, the above means we cannot specify an empty prefix "" for the
current working directory, because
> dirname("./.")
[1] "."
> basename("./.")
[1] "."
> dirname("./")
[1] "."
> basename("./")
[1] "."
Jens Oehlschlägel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] basename returns "." not in filename (PR#13958)
Jens,
On Sep 18, 2009, at 15:08 , Jens Oehlschlägel wrote:
Mmh,
Point is, I gather, that trailing slashes are removed, e.g.,
viggo:~/>basename foo/
foo
So, not a bug.
This unfortunately means that we cannot distinguish between
1) a path with a filename
2) a path without a filename
Of course you can - but that's unrelated to the bug report.
For example in the next version of the ff-package we allow a user to
specify a 'pattern' for all files of a ff dataframe which is path
together with a fileprefix, the above means we cannot specify an
empty prefix "" for the current working directory, because
dirname("./.")
[1] "."
basename("./.")
[1] "."
dirname("./")
[1] "."
basename("./")
[1] "."
I don't see the connection - I would suggest you read the IEEE Std
1003.1-2001 which defines the behavior of basename (and the R
documentation for basename clearly states the behavior as well). The
fact that you are trying to use the wrong tool for your purpose
doesn't mean that the tool is broken. I would advise you to ask on R-
help how to implement your pattern specification (just FWIW it's non-
standard and requirement of trailing slashes does lead to very nasty
problems for the user).
Cheers,
Simon
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] basename returns "." not in filename (PR#13958)
Jens,
On Sep 18, 2009, at 15:08 , Jens Oehlschl=E4gel wrote:
> Mmh,
>
>>> Point is, I gather, that trailing slashes are removed, e.g.,
>>>
>>> viggo:~/>basename foo/
>>> foo
>>>
>>> So, not a bug.
>
> This unfortunately means that we cannot distinguish between
> 1) a path with a filename
> 2) a path without a filename
>
Of course you can - but that's unrelated to the bug report.
> For example in the next version of the ff-package we allow a user to =20=
> specify a 'pattern' for all files of a ff dataframe which is path =20
> together with a fileprefix, the above means we cannot specify an =20
> empty prefix "" for the current working directory, because
>
>> dirname("./.")
> [1] "."
>> basename("./.")
> [1] "."
>> dirname("./")
> [1] "."
>> basename("./")
> [1] "."
>
I don't see the connection - I would suggest you read the IEEE Std =20
1003.1-2001 which defines the behavior of basename (and the R =20
documentation for basename clearly states the behavior as well). The =20=
fact that you are trying to use the wrong tool for your purpose =20
doesn't mean that the tool is broken. I would advise you to ask on R-=20
help how to implement your pattern specification (just FWIW it's non-=20
standard and requirement of trailing slashes does lead to very nasty =20
problems for the user).
Cheers,
Simon
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] basename returns "." not in filename (PR#13958)
On 18-Sep-09 19:08:15, Jens Oehlschlägel wrote:
> Mmh,
>> > Point is, I gather, that trailing slashes are removed, e.g.,
>> >
>> > viggo:~/>basename foo/
>> > foo
>> >
>> > So, not a bug.
>
> This unfortunately means that we cannot distinguish between
> 1) a path with a filename
> 2) a path without a filename
>
> For example in the next version of the ff-package we allow a user to
> specify a 'pattern' for all files of a ff dataframe which is path
> together with a fileprefix, the above means we cannot specify an empty
> prefix "" for the current working directory, because
>
>> dirname("./.")
> [1] "."
>> basename("./.")
> [1] "."
>> dirname("./")
> [1] "."
>> basename("./")
> [1] "."
>
> Jens Oehlschlägel
I am getting confused by this discussion. At least on Unixoid systems,
and I believe it holds for Windows systems too, "." stands for the
current directory ("working directory").
Moreover, "./" means exactly the same as ".": If you list the files
in "./" you will get exactly the same as if you list the files in ".".
Further, "/." means the same as "/"
and the same as "", so (on the same basis) "./." also
means exactly the same as ".".
Therefore the second "." in "./." is not a filename.
What the above examples of dirname and basename usage are returning
is simply a specific representation of the current working directlory.
Forgive me if I have not seen the point, but what I think I have seen
boils down to the interpretation I have given above.
Best wishes,
Ted.
E-Mail: (Ted Harding)
Fax-to-email: +44 (0)870 094 0861
Date: 18-Sep-09 Time: 22:35:34
-- XFMail --
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Package crashes R under Windows Vista
Dear all,
Please, please I really need your help, since I am not able to solve the
problem myself:
It seems that until now most Windows users of my Bioconductor package
"xps" use Windows XP, but recently a user tried to use it on Windows
Vista where it crashed R immediately. Since I assume that some users may
migrate to the upcoming Windows 7 where the problem will be the same, I
would appreciate any help to be able to support Vista/Windows 7, thank
you in advance.
The problem ist that my package consists mainly of C++ code which I must
compile with Visual C++ (Express Edition 2008), since it depends on the
ROOT C++ framework. Windows users download and install first the ROOT
Windows binary compiled with VC9 and then install the Windows binary of xps.
Thus package xps contains a "Makefile.win" where I use one of the
compiler options "/MT" or "/MD", respectively, see:
http://msdn.microsoft.com/en-us/library/2kzt1wy3.aspx
Since the Windows binary of ROOT is compiled with option "/MD" I should
in principle use this option, however, R does not accept this option.
Luckily, for Winodws XP I can compile xps with "/MT" and this works
perfectly fine.
The real problem is that neither option works on Windows Vista, although
I can run "R CMD INSTALL" in both cases. However, when loading
"library(xps)" using Rterm.exe I get the following two cases:
1, xps compiled on Vista with option "/MD":
new R session:
> library(xps,lib.loc="C:/home/Rabbitus/CRAN/myRlib")
Error in inDL(x, as.logical(local), as.logical(now), ...) :
cannot load shared library 'C:/home/CS/CRAN/myRlib/xps/libs/xps.dll':
LoadLibrary failure: A DLL-Initialisationroutine failed.
Then R crashes and Vista displays a Dialogbox with the following message:
R for Windows terminal front-end does no longer function
Anwendungszeitstempel:4a928a5c
Fehlermodulname:libCore.dll_unloaded
Fehlermodulversion:0.0.0.0
Fehlermodulzeitstempel:4a4b94a1
Ausnahmecode:c005
Ausnahmeoffset:0413a6f0
Betriebsystemversion:6.0.6001.2.1.0.768.3
Gebietsschema-ID:1031
Zusatzinformation 1:b2be
Zusatzinformation 2:82109204b3973566ace818217390e302
Zusatzinformation 3:1563
Zusatzinformation 4:deee40b8797d25628c21b9ef47e8a50c
2, xps compiled on Vista with option "/MT":
new R session:
> library(xps,lib.loc="C:/home/CS/CRAN/myRlib")
> scheme.test3 <-
root.scheme(paste(.path.package("xps"),"schemes/SchemeTest3.root",sep="/"))
> data.test3 <- import.data(scheme.test3, "DataTest3",
celdir=paste(.path.package("xps"),"raw",sep="/"))
==
=== STACKTRACE ===
==
==
= END STACKTRACE =
==
Then R crashes and Vista displays a Dialogbox with the following message:
R for Windows terminal front-end does no longer function
Problemsignatur:
Problemereignisname:APPCRASH
Anwendungsname:Rterm.exe
Anwendungsversion:2.92.49384.0
Anwendungszeitstempel:4a928a5c
Fehlermodulname:ntdll.dll
Fehlermodulversion:6.0.6001.18000
Fehlermodulzeitstempel:4791a7a6
Ausnahmecode:c005
Ausnahmeoffset:0006814c
Betriebsystemversion:6.0.6001.2.1.0.768.3
Gebietsschema-ID:1031
Zusatzinformation 1:92ec
Zusatzinformation 2:c556221fb8ba46fdaae5867fc20d6575
Zusatzinformation 3:c65f
Zusatzinformation 4:9d4dfe391e0e922aa627634d4d47a122
Here is the same information for Windows XP:
1, xps compiled on WinXP with option "/MD":
new R session:
> library(xps,lib.loc="C:/home/CS/CRAN/myRlib")
R crashes and the following Dialogbox from "Microsoft Visual C++ Runtime
Library" is displayed:
Runtime Error!
Program: c:\Programme\R\R-2.9.0\bin\Rterm.exe
R6034
An application has made an attempt to load the C runtime library
incorrectly.
Please contact the application's support team for more information.
2, xps compiled on WinXP with option "/MT":
new R session:
> library(xps,lib.loc="C:/home/CS/CRAN/myRlib")
Luckily, R runs w/o any problems and this is the setting of the current
Windows binary of "xps".
In summary, on WinXP package xps must be compiled with option "/MT" to
be used with R.
In contrast, on Vista library(xps) does not work when compiled with
either option:
- for option "/MT" library(xps) can be loaded but crashes R with
"Errormodulename: "ntdll.dll"
- for option "/MD" library(xps) cannot be loaded, since the ROOT library
"libCore.dll" cannot be loaded ("Errormodulename: "libCore.dll_unloaded")
It is important to note that on both WinXP AND Vista library "xps.dll"
compiled with option "/MD" does work perfectly fine when running from
within ROOT!
Please, can anybody tell me why Rterm on Vista crashes when running
library(xps)?
It seems that for option "/MD" Rterm is not able to load the ROOT c
[Rd] inconsistency in attaching attributes to NULL
In R-devel (svn 49628) and back to at least R 2.7.0 we get inconsistent results when attempting to attach attributes to a variable with the value NULL. If we use attributes<- it finishes but changes the value to list(). > a<-NULL > attributes(a)<-list(attr1="First attribute", attr2=2+2i) > a list() attr(,"attr1") [1] "First attribute" attr(,"attr2") [1] 2+2i If we use attr<- it refuses to attach the attribute > b<-NULL > attr(b, "attr1") <- "First attribute" Error in attr(b, "attr1") <- "First attribute" : attempt to set an attribute on NULL Is the second behavior the correct one and should attributes(x)<-list() abort if x is NULL? (attributes(NULL)<-list(attr="First") dies because NULL itself is not allowed on the left side of an assignment.) Bill Dunlap TIBCO Software Inc - Spotfire Division wdunlap tibco.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Package crashes R under Windows Vista
On 18/09/2009 6:12 PM, cstrato wrote:
Dear all,
Please, please I really need your help, since I am not able to solve the
problem myself:
It seems that until now most Windows users of my Bioconductor package
"xps" use Windows XP, but recently a user tried to use it on Windows
Vista where it crashed R immediately. Since I assume that some users may
migrate to the upcoming Windows 7 where the problem will be the same, I
would appreciate any help to be able to support Vista/Windows 7, thank
you in advance.
You are requiring specific Microsoft tools to compile a package, which
fails on one Microsoft OS, but not another. Isn't this a question you
should address to Microsoft?
For the record:
We support compiling in the compiler listed in the R-admin manual, which
is available from www.murdoch-sutherland.com/Rtools. If you choose to
use a different compiler, you should seek support from its supplier.
Duncan Murdoch
The problem ist that my package consists mainly of C++ code which I must
compile with Visual C++ (Express Edition 2008), since it depends on the
ROOT C++ framework. Windows users download and install first the ROOT
Windows binary compiled with VC9 and then install the Windows binary of xps.
Thus package xps contains a "Makefile.win" where I use one of the
compiler options "/MT" or "/MD", respectively, see:
http://msdn.microsoft.com/en-us/library/2kzt1wy3.aspx
Since the Windows binary of ROOT is compiled with option "/MD" I should
in principle use this option, however, R does not accept this option.
Luckily, for Winodws XP I can compile xps with "/MT" and this works
perfectly fine.
The real problem is that neither option works on Windows Vista, although
I can run "R CMD INSTALL" in both cases. However, when loading
"library(xps)" using Rterm.exe I get the following two cases:
1, xps compiled on Vista with option "/MD":
new R session:
> library(xps,lib.loc="C:/home/Rabbitus/CRAN/myRlib")
Error in inDL(x, as.logical(local), as.logical(now), ...) :
cannot load shared library 'C:/home/CS/CRAN/myRlib/xps/libs/xps.dll':
LoadLibrary failure: A DLL-Initialisationroutine failed.
Then R crashes and Vista displays a Dialogbox with the following message:
R for Windows terminal front-end does no longer function
Anwendungszeitstempel:4a928a5c
Fehlermodulname:libCore.dll_unloaded
Fehlermodulversion:0.0.0.0
Fehlermodulzeitstempel:4a4b94a1
Ausnahmecode:c005
Ausnahmeoffset:0413a6f0
Betriebsystemversion:6.0.6001.2.1.0.768.3
Gebietsschema-ID:1031
Zusatzinformation 1:b2be
Zusatzinformation 2:82109204b3973566ace818217390e302
Zusatzinformation 3:1563
Zusatzinformation 4:deee40b8797d25628c21b9ef47e8a50c
2, xps compiled on Vista with option "/MT":
new R session:
> library(xps,lib.loc="C:/home/CS/CRAN/myRlib")
> scheme.test3 <-
root.scheme(paste(.path.package("xps"),"schemes/SchemeTest3.root",sep="/"))
> data.test3 <- import.data(scheme.test3, "DataTest3",
celdir=paste(.path.package("xps"),"raw",sep="/"))
==
=== STACKTRACE ===
==
==
= END STACKTRACE =
==
Then R crashes and Vista displays a Dialogbox with the following message:
R for Windows terminal front-end does no longer function
Problemsignatur:
Problemereignisname:APPCRASH
Anwendungsname:Rterm.exe
Anwendungsversion:2.92.49384.0
Anwendungszeitstempel:4a928a5c
Fehlermodulname:ntdll.dll
Fehlermodulversion:6.0.6001.18000
Fehlermodulzeitstempel:4791a7a6
Ausnahmecode:c005
Ausnahmeoffset:0006814c
Betriebsystemversion:6.0.6001.2.1.0.768.3
Gebietsschema-ID:1031
Zusatzinformation 1:92ec
Zusatzinformation 2:c556221fb8ba46fdaae5867fc20d6575
Zusatzinformation 3:c65f
Zusatzinformation 4:9d4dfe391e0e922aa627634d4d47a122
Here is the same information for Windows XP:
1, xps compiled on WinXP with option "/MD":
new R session:
> library(xps,lib.loc="C:/home/CS/CRAN/myRlib")
R crashes and the following Dialogbox from "Microsoft Visual C++ Runtime
Library" is displayed:
Runtime Error!
Program: c:\Programme\R\R-2.9.0\bin\Rterm.exe
R6034
An application has made an attempt to load the C runtime library
incorrectly.
Please contact the application's support team for more information.
2, xps compiled on WinXP with option "/MT":
new R session:
> library(xps,lib.loc="C:/home/CS/CRAN/myRlib")
Luckily, R runs w/o any problems and this is the setting of the current
Windows binary of "xps".
In summary, on WinXP package xps must be compiled with option "/MT" to
be used with R.
In contrast, on Vista library(xps) does not work when compiled with
either option:
- for option "/MT" library(xps) can b
[Rd] what should names(x) be padded with when length(x) is increased?
R version 2.10.0 Under development (unstable) (2009-09-08 r49628)
Here are two somewhat related questions.
First, when we attach a too short names vector to a vector
the names vector is padded with NA's to the length of the
main vector: E.g.,
> x<-1:3
> names(x)<-c("One","Two")
> str(x)
Named int [1:3] 1 2 3
- attr(*, "names")= chr [1:3] "One" "Two" NA
I expected this length mismatch to cause an error, but I am
biassed by my long usage of S and S+. Is the extension by
padding with NA what is wanted?
Second, if we extend a named vector with length<- the main
vector is padded with NA's but the names are padded with
empty strings. Should those be NA's?
> x<-1:3
> names(x)<-c("One","Two")
> length(x)<-4
> str(x)
Named int [1:4] 1 2 3 NA
- attr(*, "names")= chr [1:4] "One" "Two" NA ""
The names "" and NA act alike in that subscript by either
returns structure(NA, names=NA_character_), but they
print differently
> x
One Two
123 NA
Bill Dunlap
TIBCO Software Inc - Spotfire Division
wdunlap tibco.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] what should names(x) be padded with when length(x) is increased?
The graphviz site, itself, lists resources/alternatives here:
http://www.graphviz.org/Resources.php
On Fri, Sep 18, 2009 at 6:34 PM, William Dunlap wrote:
> R version 2.10.0 Under development (unstable) (2009-09-08 r49628)
>
> Here are two somewhat related questions.
>
> First, when we attach a too short names vector to a vector
> the names vector is padded with NA's to the length of the
> main vector: E.g.,
> > x<-1:3
> > names(x)<-c("One","Two")
> > str(x)
> Named int [1:3] 1 2 3
> - attr(*, "names")= chr [1:3] "One" "Two" NA
> I expected this length mismatch to cause an error, but I am
> biassed by my long usage of S and S+. Is the extension by
> padding with NA what is wanted?
>
> Second, if we extend a named vector with length<- the main
> vector is padded with NA's but the names are padded with
> empty strings. Should those be NA's?
>
> > x<-1:3
> > names(x)<-c("One","Two")
> > length(x)<-4
> > str(x)
> Named int [1:4] 1 2 3 NA
> - attr(*, "names")= chr [1:4] "One" "Two" NA ""
>
> The names "" and NA act alike in that subscript by either
> returns structure(NA, names=NA_character_), but they
> print differently
> > x
> One Two
> 1 2 3 NA
>
>
> Bill Dunlap
> TIBCO Software Inc - Spotfire Division
> wdunlap tibco.com
>
> __
> 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] inconsistency in attaching attributes to NULL
William Dunlap wrote: > > In R-devel (svn 49628) and back to at least R 2.7.0 we get > inconsistent results when attempting to attach attributes to > a variable with the value NULL. > > If we use attributes<- it finishes but changes the value to list(). > >> a<-NULL >> attributes(a)<-list(attr1="First attribute", attr2=2+2i) >> a >list() >attr(,"attr1") >[1] "First attribute" >attr(,"attr2") >[1] 2+2i > > If we use attr<- it refuses to attach the attribute > >> b<-NULL >> attr(b, "attr1") <- "First attribute" >Error in attr(b, "attr1") <- "First attribute" : > attempt to set an attribute on NULL > > Is the second behavior the correct one and should attributes(x)<-list() > abort if x is NULL? > > (attributes(NULL)<-list(attr="First") dies because NULL itself is not > allowed on the left side of an assignment.) > > Bill Dunlap > > It's probably an unfortunate inconsistency that you are able to set attributes on a using attributes() <- when a is NULL. According to the R Language Definition (Section 2.1.6: NULL): R Language Definition wrote: > > The NULL object has no type and no modifiable properties. There is only > one NULL object in R, to which all instances refer. To test for NULL use > is.null. You cannot set attributes on NULL. > Looks like there's a missing error message that should be there :P -Charlie - Charlie Sharpsteen Undergraduate Environmental Resources Engineering Humboldt State University -- View this message in context: http://www.nabble.com/inconsistency-in-attaching-attributes-to-NULL-tp25516381p25516472.html Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
