[Rd] ave returns wrong data type (PR#13664)
Full_Name: Brendan Barnwell Version: 2.9.0 OS: Windows XP Pro Submission from: (NULL) (71.102.131.29) The ave() function returns an incorrect datatype. Specifically, ave(x, g, f) always returns a vector with the same mode as x, rather than using the mode of the vector returned by f. Observe: > x [1] "A" "B" "C" "A" "B" "C" "A" "B" "C" "A" "B" "C" "A" "B" "C" "A" "B" "C" "A" "B" "C" "A" "B" "C" "A" "B" "C" "A" "B" "C" > g [1] "X" "Y" "X" "Y" "X" "Y" "X" "Y" "X" "Y" "X" "Y" "X" "Y" "X" "Y" "X" "Y" "X" "Y" "X" "Y" "X" "Y" "X" "Y" "X" "Y" "X" "Y" > ave(x, g, FUN=length) [1] "15" "15" "15" "15" "15" "15" "15" "15" "15" "15" "15" "15" "15" "15" "15" "15" "15" "15" "15" "15" "15" "15" "15" "15" [25] "15" "15" "15" "15" "15" "15" Even though the length() function returns a vector of integers, ave() inappropriately converts this to a character vector. The bug is due to this line in the definition of ave(): split(x, g) <- lapply(split(x, g), FUN) By sticking the result of the lapply back into the original argument x, it coerces that result to the type of that argument. This contradicts the documentation, which says that the value of ave() is "a numeric vector". I would suggest that this documentation itself doesn't describe the desired behavior. The result vector should be of the type returned by FUN (just as it is for tapply). Otherwise it is impossible to use ave() to compute summary statistics whose type differs from that of the argument. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R build fails during make when configured with "--with-x=no" (PR#13665)
Full_Name: Jeet Sukumaran
Version: 2.9.0
OS: OS X / Rocks 5.1
Submission from: (NULL) (66.45.136.241)
If R is configured using the "--with=x=no" option, then the make fails with the
following error:
make[4]: Entering directory
`/home/jeet/Scratch/r-build/on-frontend/R-2.9.0/src/modules/vfonts'
gcc -std=gnu99 -I. -I../../../src/include -I../../../src/include
-I/usr/local/include -DHAVE_CONFIG_H -fpic -g -O2 -c g_alab_her.c -o
g_alab_her.o
gcc -std=gnu99 -I. -I../../../src/include -I../../../src/include
-I/usr/local/include -DHAVE_CONFIG_H -fpic -g -O2 -c g_cntrlify.c -o
g_cntrlify.o
gcc -std=gnu99 -I. -I../../../src/include -I../../../src/include
-I/usr/local/include -DHAVE_CONFIG_H -fpic -g -O2 -c g_fontdb.c -o
g_fontdb.o
gcc -std=gnu99 -I. -I../../../src/include -I../../../src/include
-I/usr/local/include -DHAVE_CONFIG_H -fpic -g -O2 -c g_her_glyph.c -o
g_her_glyph.o
gcc -std=gnu99 -shared -L/usr/local/lib64 -o vfonts.so g_alab_her.o g_cntrlify.o
g_fontdb.o g_her_glyph.o -lm
make[5]: Entering directory
`/home/jeet/Scratch/r-build/on-frontend/R-2.9.0/src/modules/vfonts'
make[5]: Leaving directory
`/home/jeet/Scratch/r-build/on-frontend/R-2.9.0/src/modules/vfonts'
make[4]: Leaving directory
`/home/jeet/Scratch/r-build/on-frontend/R-2.9.0/src/modules/vfonts'
make[3]: Leaving directory
`/home/jeet/Scratch/r-build/on-frontend/R-2.9.0/src/modules/vfonts'
make[3]: Entering directory `/home/jeet'
make[3]: *** No rule to make target `R'. Stop.
make[3]: Leaving directory `/home/jeet'
make[2]: *** [R] Error 1
make[2]: Leaving directory
`/home/jeet/Scratch/r-build/on-frontend/R-2.9.0/src/modules'
make[1]: *** [R] Error 1
make[1]: Leaving directory `/home/jeet/Scratch/r-build/on-frontend/R-2.9.0/src'
make: *** [R] Error 1
The problem appears to be with the "src/modules/Makefile". Specfically, lines
26-29:
@for d in "$(R_MODULES)"; do \
(cd $${d} && $(MAKE) $@) || exit 1; \
done
Here, R_MODULES is blank, resulting in the "cd" command transferring to the
user's home directory, where, of course, no Makefile is found resulting in the
error above.
Work-around appears to be to simply disable loop if R_MODULES is empty.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] ave returns wrong data type (PR#13664)
Note that according to ?ave, the first argument of ave(), 'x' should be a *numeric* vector. In your case 'x' is not numeric, it is a character vector. So I think that ave() works as documented, i.e., if you supply as first argument a numeric vector, then you do get as an output a numeric vector. Best, Dimitris brenb...@brenbarn.net wrote: Full_Name: Brendan Barnwell Version: 2.9.0 OS: Windows XP Pro Submission from: (NULL) (71.102.131.29) The ave() function returns an incorrect datatype. Specifically, ave(x, g, f) always returns a vector with the same mode as x, rather than using the mode of the vector returned by f. Observe: x [1] "A" "B" "C" "A" "B" "C" "A" "B" "C" "A" "B" "C" "A" "B" "C" "A" "B" "C" "A" "B" "C" "A" "B" "C" "A" "B" "C" "A" "B" "C" g [1] "X" "Y" "X" "Y" "X" "Y" "X" "Y" "X" "Y" "X" "Y" "X" "Y" "X" "Y" "X" "Y" "X" "Y" "X" "Y" "X" "Y" "X" "Y" "X" "Y" "X" "Y" ave(x, g, FUN=length) [1] "15" "15" "15" "15" "15" "15" "15" "15" "15" "15" "15" "15" "15" "15" "15" "15" "15" "15" "15" "15" "15" "15" "15" "15" [25] "15" "15" "15" "15" "15" "15" Even though the length() function returns a vector of integers, ave() inappropriately converts this to a character vector. The bug is due to this line in the definition of ave(): split(x, g) <- lapply(split(x, g), FUN) By sticking the result of the lapply back into the original argument x, it coerces that result to the type of that argument. This contradicts the documentation, which says that the value of ave() is "a numeric vector". I would suggest that this documentation itself doesn't describe the desired behavior. The result vector should be of the type returned by FUN (just as it is for tapply). Otherwise it is impossible to use ave() to compute summary statistics whose type differs from that of the argument. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Dimitris Rizopoulos Assistant Professor Department of Biostatistics Erasmus University Medical Center Address: PO Box 2040, 3000 CA Rotterdam, the Netherlands Tel: +31/(0)10/7043478 Fax: +31/(0)10/7043014 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R build fails during make when configured with "--with-x=no" (PR#13665)
j...@ku.edu wrote:
>
> If R is configured using the "--with=x=no" option, then the make fails with
> the
> following error:
> make[1]: *** [R] Error 1
> make[1]: Leaving directory
> `/home/jeet/Scratch/r-build/on-frontend/R-2.9.0/src'
> make: *** [R] Error 1
>
> The problem appears to be with the "src/modules/Makefile". Specfically, lines
> 26-29:
>
> @for d in "$(R_MODULES)"; do \
> (cd $${d} && $(MAKE) $@) || exit 1; \
> done
>
> Here, R_MODULES is blank, resulting in the "cd" command transferring to the
> user's home directory, where, of course, no Makefile is found resulting in the
> error above.
(Even more "fun" would ensue if in fact there were a Makefile there...)
> Work-around appears to be to simply disable loop if R_MODULES is empty.
Shell script and Make portability is a pain in the derriere, but
offhand, those double quotes just look wrong:
viggo:~/>for i in "" ; do echo $i; done
viggo:~/>for i in ; do echo $i; done
viggo:~/>for i in "foo bar" ; do echo $i; done
foo bar
viggo:~/>for i in foo bar ; do echo $i; done
foo
bar
Notice that the versions with quotes invariably do the Wrong Thing
--
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] R build fails during make when configured with "--with-x=no" (PR#13666)
j...@ku.edu wrote:
>=20
> If R is configured using the "--with=3Dx=3Dno" option, then the make fa=
ils with the
> following error:
> make[1]: *** [R] Error 1
> make[1]: Leaving directory `/home/jeet/Scratch/r-build/on-frontend/R-2.=
9.0/src'
> make: *** [R] Error 1
>=20
> The problem appears to be with the "src/modules/Makefile". Specfically,=
lines
> 26-29:
>=20
> @for d in "$(R_MODULES)"; do \
> (cd $${d} && $(MAKE) $@) || exit 1; \
> done
>=20
> Here, R_MODULES is blank, resulting in the "cd" command transferring to=
the
> user's home directory, where, of course, no Makefile is found resulting=
in the
> error above.
(Even more "fun" would ensue if in fact there were a Makefile there...)
> Work-around appears to be to simply disable loop if R_MODULES is empty.=
Shell script and Make portability is a pain in the derriere, but
offhand, those double quotes just look wrong:
viggo:~/>for i in "" ; do echo $i; done
viggo:~/>for i in ; do echo $i; done
viggo:~/>for i in "foo bar" ; do echo $i; done
foo bar
viggo:~/>for i in foo bar ; do echo $i; done
foo
bar
Notice that the versions with quotes invariably do the Wrong Thing
--=20
O__ Peter Dalgaard =C3=98ster 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
[Rd] Problems building R 2.9.0... on SGI and Sun once again
I've successfully built R 2.9.0 on Linux (amd64, i386 and ppc), but am
having a bit of trouble with legacy boxen. What should have gone into
the variable that is empty at the time it is used in "for f in $SOMETHING"
and why does it end up being empty?
Solaris 8 with Sun Studio 11 compilers:
building package 'methods'
gmake[4]: Entering directory `/scratch/atossava/R-2.9.0/src/library/methods'
all.R is unchanged
/bin/bash: -c: line 1: syntax error near unexpected token `;'
/bin/bash: -c: line 1: `for f in ; do if test -f ./${f}; then
../../../tools/install-sh -c -m 644 ./${f} ../../../library/methods; fi;
done'
gmake[4]: *** [front] Error 2
gmake[4]: Leaving directory `/scratch/atossava/R-2.9.0/src/library/methods'
IRIX 6.5 with MIPSpro 7.4.4 compilers:
building package 'methods'
gmake[4]: Entering directory `/wrk/atossava/R-2.9.0/src/library/methods'
all.R is unchanged
/bin/sh: syntax error at line 1 : `;' unexpected
gmake[4]: *** [front] Error 2
gmake[4]: Leaving directory `/wrk/atossava/R-2.9.0/src/library/methods'
--
Atro Tossavainen (Mr.) / The Institute of Biotechnology at
Systems Analyst, Techno-Amish & / the University of Helsinki, Finland,
+358-9-19158939 UNIX Dinosaur / employs me, but my opinions are my own.
< URL : http : / / www . helsinki . fi / %7E atossava / > NO FILE ATTACHMENTS
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] suggestion for R >= 3.0: computer-readable CHANGELOG
On Fri, Apr 17, 2009 at 2:09 PM, Philippe Grosjean
wrote:
> OK, then, I catch the practical point of view that is: nobody will use it
> and we cannot force people to use it. So, it means that we should think
> about tools to *automatically* generate a limited set of entries in the
> CHANGELOG.
Of course this tells you what was changed but not why. I'd like to
know a more top-level "what" and, more importantly, "why".
It would also pick up code formatting changes.
> Something like new functions appearing in a package, functions being
> deprecated, change in the function's interface (arguments definition),
> change in the dependence of packages could be tracked automatically if the
> previous version of the package is available. This should be the case for
> packages on CRAN and Bioconductor, after first release. So, those
> "changelog" tools should be best deployed at this level.
>
> Further details could be provided directly inside the code, using simple
> formatting, and proposed as a purely optional feature. I think at something
> like:
>
> foo <- function (x, mynewarg) {
> #CHANGE# arg:mynewarg:A new argument in my function
> ...
> }
>
> or
>
> bar <- function (y) {
> #CHANGE# fun:Short details about this new function
> }
>
My code is ugly enough without the extra help, and this would take
things to a new level of ugly.
Sorry to pick on this, but it is also optional and suffers from the
same issues as you mentioned above.
--
Max
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] print.closure at the R level
Hello,
Sorry if I have waisted any time of people truing this patch. There was
an issue with debugging (use of debug and browser that caused an
infinite recursion). I think this is now fixed.
At the R level, I have now this :
> print.function
function (x, useSource = TRUE, ...)
{
invisible(.Internal(print.function(x, useSource, ...)))
}
and the PrintValueRec dispatches like this at the C level:
case LANGSXP:
PrintLanguage(s, FALSE) ;
break;
case CLOSXP:
{
SEXP call;
PROTECT( call = lang2(install("print.function"), s));
eval(call,env);
UNPROTECT(1);
break;
}
so that LANGSXP are printed using the PrintLanguage function and CLOSXP
are printed using the R function print.function which in turns calls the
PrintClosure function (unless it is masked in R)
Romain
Romain Francois wrote:
Yesterday's patch did not print the attributes. This one seems fine:
> f <- function(){}
> attr( f, "yada" ) <- function( ) "lobster bisk"
> f
function(){}
attr(,"yada")
function( ) "lobster bisk"
Romain
Romain Francois wrote:
Duncan Murdoch wrote:
On 18/04/2009 10:12 AM, Romain Francois wrote:
Hello,
Could the code that auto prints a function/closure be extracted
from print.c so that there would be a print.closure function.
I would like to be able to mask a print.closure function so that I
have a custom auto-print. One reason for that is I plan to have
syntax highlighting within the R console.
The class of a closure is "function", so you'd want the method to be
print.function. Currently that doesn't work for auto printing, so
your suggestion is still interesting. (I'm not sure why auto
printing is special here...)
Duncan Murdoch
The attached patch implements exposing the print.function at the R
level.
Romain
__
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
--
Romain Francois
Independent R Consultant
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
Index: src/include/Internal.h
===
--- src/include/Internal.h (revision 48365)
+++ src/include/Internal.h (working copy)
@@ -370,6 +370,7 @@
SEXP do_printdefault(SEXP, SEXP, SEXP, SEXP);
SEXP do_printDeferredWarnings(SEXP, SEXP, SEXP, SEXP);
SEXP do_printdf(SEXP, SEXP, SEXP, SEXP);
+SEXP do_printfunction(SEXP, SEXP, SEXP, SEXP);
SEXP do_prmatrix(SEXP, SEXP, SEXP, SEXP);
SEXP do_proctime(SEXP, SEXP, SEXP, SEXP);
SEXP do_psort(SEXP, SEXP, SEXP, SEXP);
Index: src/include/Print.h
===
--- src/include/Print.h (revision 48365)
+++ src/include/Print.h (working copy)
@@ -80,4 +80,7 @@
#define R_MIN_DIGITS_OPT 1
#define R_MAX_DIGITS_OPT 22
+void PrintClosure( SEXP, Rboolean) ;
+void PrintLanguage( SEXP, Rboolean) ;
+
#endif
Index: src/library/base/R/print.R
===
--- src/library/base/R/print.R (revision 48365)
+++ src/library/base/R/print.R (working copy)
@@ -85,3 +85,8 @@
print(noquote(cbind("_"=unlist(x))), ...)
`[.simple.list` <- `[.listof`
+
+print.function <- function( x, useSource=TRUE, ...){
+ invisible( .Internal( print.function( x, useSource, ... ) ) )
+}
+
Index: src/main/names.c
===
--- src/main/names.c (revision 48365)
+++ src/main/names.c (working copy)
@@ -631,6 +631,7 @@
{"readline", do_readln, 0, 11, 1, {PP_FUNCALL, PREC_FN, 0}},
{"menu", do_menu, 0, 11, 1, {PP_FUNCALL, PREC_FN, 0}},
{"print.default",do_printdefault,0, 111, 9, {PP_FUNCALL, PREC_FN, 0}},
+{"print.function",do_printfunction,0, 111, 3, {PP_FUNCALL, PREC_FN, 0}},
{"prmatrix", do_prmatrix, 0, 111, 6, {PP_FUNCALL, PREC_FN, 0}},
{"invisible", do_invisible, 0, 101, 1, {PP_FUNCALL, PREC_FN, 0}},
{"gc", do_gc, 0, 11, 2, {PP_FUNCALL, PREC_FN, 0}},
Index: src/main/print.c
===
--- src/main/print.c (revision 48365)
+++ src/main/print.c (working copy)
@@ -154,6 +154,56 @@
return x;
}/* do_prmatrix */
+
+/* .Internal( print.function( f, useSource,... ) ) */
+SEXP attribute_hidden do_printfunction( SEXP call, SEXP op, SEXP args, SEXP rho){
+ SEXP s;
+ Rboolean useSource = TRUE;
+ s=CAR(args);
+ args = CDR(args); useSource=asLogical(CAR(args));
+
+ PrintClosure( s, useSource ) ;
+ return R_NilValue;
+}
+
+void PrintClosure( SEXP s, Rboolean useSource ){
+ SEXP t;
+ int i;
+ if( TYPEOF(s) != CLOSXP ) return ;
+ t = getAttrib(s, R_SourceSymbol);
+ if (!isString(t) || !useSource){
+ t = deparse1(s, 0, useSource | DEFAULTDEPARSE
Re: [Rd] bug in classesToAM()
Thanks! H.
John Chambers wrote:
Yes, thanks. Should be fixed now in r-devel and 2.9.0 patched.
John
hpa...@fhcrc.org wrote:
Hi,
I can't get the non-abbreviated class names of the
rows and the cols of the Adjacency Matrix:
setClass("ClassWithALongName")
setClass("SubclassOfClassWithALongName",
contains="ClassWithALongName")
Trying all possible values for 'abbreviate' (with R-2.9.0):
classesToAM("SubclassOfClassWithALongName", abbreviate=0)
SubclassOfClassWithALongName ClassWithALongName
SOCW0 1
CWAL0 0
classesToAM("SubclassOfClassWithALongName", abbreviate=1)
SOCW CWAL
SubclassOfClassWithALongName01
ClassWithALongName 00
classesToAM("SubclassOfClassWithALongName", abbreviate=2)
SOCW CWAL
SOCW01
CWAL00
classesToAM("SubclassOfClassWithALongName", abbreviate=3)
SOCW CWAL
SubclassOfClassWithALongName01
ClassWithALongName 00
This does not reflect what the man page is saying: "values
0, 1, 2, or 3 abbreviate neither, rows, columns or both".
Cheers,
H.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M2-B876
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fhcrc.org
Phone: (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] print.closure at the R level
> "RF" == Romain Francois
> on Mon, 20 Apr 2009 22:42:22 +0200 writes:
RF> Hello,
RF> Sorry if I have waisted any time of people truing this
RF> patch.
yes, you did waste (sic)
but thank you for the code suggestions anyway.
RF> There was an issue with debugging (use of debug
RF> and browser that caused an infinite recursion). I think
RF> this is now fixed.
[ actually I had found even simpler bugs in it, e.g.
you accidentally called C-level "print.function()" on "language",
some may have been fixed by your new patch too, but others are
not {e.g., print() *must* return its argument !}
]
However, I've already changed your old patch too much
(notably by using *our* C coding standards) to want to look at
your new patch in detail.
If you want we can communicate off-list about this,
tomorrow...
Martin Maechler, ETH Zurich
RF> At the R level, I have now this :
>> print.function
RF> function (x, useSource = TRUE, ...) {
RF> invisible(.Internal(print.function(x, useSource, ...)))
RF> }
RF> and the PrintValueRec dispatches like this at the C
RF> level:
RF> case LANGSXP: PrintLanguage(s, FALSE) ; break; case
RF> CLOSXP: { SEXP call; PROTECT( call =
RF> lang2(install("print.function"), s)); eval(call,env);
RF> UNPROTECT(1); break; }
RF> so that LANGSXP are printed using the PrintLanguage
RF> function and CLOSXP are printed using the R function
RF> print.function which in turns calls the PrintClosure
RF> function (unless it is masked in R)
RF> Romain
RF> Romain Francois wrote:
>> Yesterday's patch did not print the attributes. This one
>> seems fine:
>>
>> > f <- function(){} > attr( f, "yada" ) <- function( )
>> "lobster bisk" > f function(){} attr(,"yada") function( )
>> "lobster bisk"
>>
>> Romain
>>
>> Romain Francois wrote:
>>> Duncan Murdoch wrote:
On 18/04/2009 10:12 AM, Romain Francois wrote:
> Hello,
>
> Could the code that auto prints a function/closure be
> extracted from print.c so that there would be a
> print.closure function. I would like to be able to
> mask a print.closure function so that I have a custom
> auto-print. One reason for that is I plan to have
> syntax highlighting within the R console.
The class of a closure is "function", so you'd want the
method to be print.function. Currently that doesn't
work for auto printing, so your suggestion is still
interesting. (I'm not sure why auto printing is
special here...)
Duncan Murdoch
>>> The attached patch implements exposing the
>>> print.function at the R level.
>>>
>>> Romain
>>>
>>>
>>>
>>> __
>>> 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
RF> -- Romain Francois Independent R Consultant +33(0) 6 28
RF> 91 30 30 http://romainfrancois.blog.free.fr
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Sharing variables in seperate workspace
Hi all.
I'm for the first time trying to make a library in R 2.8.1 on Ubuntu
Linux. The library is very simple, R functions just need to share a
variable (that is defined in the R code) and maybe functions and export
functions for the user to .GlobalEnv. This variable should only be
directly accessible from the global workspace (without change of
environment) via a hereto dedicated function. It only consists of R
code. I'm not sure if I should rather ask R-help. If so, just tell me.
The package source is available at
http://www.delff.dk/~philip/bdplot/
the check output at
http://www.delff.dk/~philip/bdplot.Rcheck/
The package code was checked and stopped because of lack of examples.
Until that, everything is OK.
> ### ** Examples
>
> ~~ simple examples of the most important functions ~~
Error: unexpected symbol in "~~ simple examples"
Execution halted
I would like to get the code issue solved before moving the
documentation from the R scripts and have proceeded the to building and
installation. These two last steps gave no warnings or errors.
My problem is that I cannot change the mentioned variable (from now on
called .FOO) that belongs to the namespace of the package. I think it is
because .FOO variable in some locked state, maybe by default created as
read-only. It is called .FOO because I use exportPattern("^[[:alpha:]]+")
as NAMESPACE file. I don't import anything.
I have a function (bar) that, like par does with .Pars from the graphics
namespace, modifies the contents of a list. This function has in the
bottom (when the function name is called without () from the R command
line) a line
This is like par() has the graphics namespace mentioned, and therefore,
as I would expect. I can via this function read the contents of the
variable just by print(.FOO). This cannot be done from .GlobalEnv which
is as intended. The surprise is that I cannot write to it. If I do
.FOO$x <<- "value"
(names and values are arguments to the function, like with par().), I
get the error:
cannot change value of locked binding for '.FOO'
The double arrow, I use because <- does not affect the contents of .FOO
after the function has run. I don't know how I can use assign in this
case. I don't know a name for my package's environment. I have tried
with my package's name in both assign() and unlockBinding(), but my
package's name is not recognized as an environment (neither beginning
with a dot.). I also tryed unlockBinding() in the NAMESPACE file.
I don't know if this is normal, but I get
from print(parent.frame()) and things like
from print(environment())
This is surprising to me. I would expect
from environment().
How can I get to write to .FOO via bar()?
Thank you very much
Philip.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
