Re: [Rd] R-2.12.0 hangs while loading RGtk2 on FreeBSD
On 22.10.2010 22:10 (UTC+1), Rainer Hurling wrote:
On 22.10.2010 16:18 (UTC+2), Rainer Hurling wrote:
On 22.10.2010 14:57 (UTC+1), Michael Lawrence wrote:
On Thu, Oct 21, 2010 at 9:42 AM, Rainer Hurling rhur...@gwdg.de
mailto:rhur...@gwdg.de wrote:
[moved from R-help]
On 21.10.2010 18:09 (UTC+1), Prof Brian Ripley wrote:
If you do R CMD INSTALL --no-test-load this will skip the part
that is
hanging and you can try loading in stages (e.g. dyn.load on the
RGtk2.so).
With '--no-test-load' it installs and ends normal. Loading per
dyn.load(RGtk2.so) works, just as dyn.load(RGtk2.so,F) and
dyn.load(RGtk2.so,,F). Unloading works, too.
Normal loading over library(RGtk2) within R does not work. R than is
hanging.
It seems the problem is not with the library itself?
It looks like something is happening when initializing GTK+ and the
event loop. This happens in the function R_gtkInit in Rgtk.c. If you
could run R -d gdb and break on that function, perhaps you could step
through until it hangs.
Michael, thank you for answering. As I wrote earlier (on R-help@),
unfortunately I have no experience with debugging (I am not a
programmer). So I would need some more assistence.
Is there a difference between 'library(RGtk2)' and 'dyn.load(RGtk2)' in
initializing GTK+? I am able to dyn.load, but library does not work.
After starting with 'R -d gdb' is the following right?
(gdb) break R_gtkInit
Function R_gtkInit not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (R_gtkInit) pending.
When I try to proceed, it gives me the following message
(gdb) run
Starting program: /usr/local/lib/R/bin/exec/R
/libexec/ld-elf.so.1: Shared object libRblas.so not found,
required by R
Program exited with code 01.
Ok, I am one step further now:
(gdb) run
Starting program: /usr/local/lib/R/bin/exec/R
[..SNIP..]
library(RGtk2)
[New LWP 100174]
Breakpoint 2 at 0x318bd490: file Rgtk.c, line 104.
Pending breakpoint R_gtkInit resolved
[New Thread 2f408b00 (LWP 100174)]
[Switching to Thread 2f408b00 (LWP 100174)]
Breakpoint 2, R_gtkInit (rargc=0x30b11d10, rargv=0x30a98458,
success=0x30afbad0) at Rgtk.c:104
104 Rgtk.c: No such file or directory.
in Rgtk.c
(gdb)
What do you suggest I should do next?
Rgtk.c was not found from gdb because RGtk2 was not build with DEBUG=T
and R_KEEP_PKG_SOURCE=yes.
So this is the next try. I can trace the code until it hangs:
library(RGtk2)
[New LWP 100250]
Breakpoint 2 at 0x458bd490: file Rgtk.c, line 104.
Pending breakpoint R_gtkInit resolved
[New Thread 4322ef00 (LWP 100250)]
[Switching to Thread 4322ef00 (LWP 100250)]
Breakpoint 2, R_gtkInit (rargc=0x446d0980, rargv=0x44698618,
success=0x446d09e0) at Rgtk.c:104
104 {
(gdb) n
107 argc = (int) *rargc;
(gdb) n
104 {
(gdb) n
107 argc = (int) *rargc;
(gdb) n
109 if (!gdk_display_get_default()) {
(gdb) n
110 gtk_disable_setlocale();
(gdb) n
111 if (!gtk_init_check(argc, rargv)) {
(gdb) n
121 if (!GDK_DISPLAY()) {
(gdb) n
127 addInputHandler(R_InputHandlers,
ConnectionNumber(GDK_DISPLAY()),
(gdb) n
132 if (!pipe(fds)) {
(gdb) n
133 ifd = fds[0];
(gdb) n
134 ofd = fds[1];
(gdb) n
135 addInputHandler(R_InputHandlers, ifd,
R_gtk_timerInputHandler, 32);
(gdb) n
133 ifd = fds[0];
(gdb) n
134 ofd = fds[1];
(gdb) n
135 addInputHandler(R_InputHandlers, ifd,
R_gtk_timerInputHandler, 32);
(gdb) n
136 if (!g_thread_supported ()) g_thread_init (NULL);
(gdb) n
137 g_thread_create(R_gtk_timerThreadFunc, NULL, FALSE, NULL);
(gdb) n
Line 138 (R_CStackLimit = -1;) is hanging. It seems there is something
wrong with piping the file descriptor?
Thanks again,
Rainer
Thanks,
Michael
I think this is rather technical for R-help, so maybe move to
R-devel?
I moved to R-devel.
And can you check the RGtk2 version? A recent but not current
version
(2.12.17?) did hang initializing Gtk+ on some platforms and Michael
Lawrence had to be involved.
I am using RGtk2_2.12.18.tar.gz for month now.
On Thu, 21 Oct 2010, Rainer Hurling wrote:
Am 21.10.2010 16:12 (UTC+1) schrieb Prof Brian Ripley:
On Thu, 21 Oct 2010, Rainer Hurling wrote:
I am working with R-2.12.0 on FreeBSD 9.0-CURRENT
for a while now. I
successfully installed more than 300 packages (most
as dependencies of
others).
There are two packages I am not able to install:
RGtk2 and rggobi.
For example rggobi builds fine and after that it
wants to load:
--
# R CMD INSTALL rggobi_2.1.16.tar.gz
[..SNIP..]
gcc -std=gnu99 -shared -L/usr/local/lib -o rggobi.so
RSEval.o brush.o
colorSchemes.o conversion.o data.o dataset.o
display.o displays.o
edges.o ggobi.o identify.o init.o io.o keyHandlers.o
longitudinal.o
modes.o plot.o plots.o plugins.o print.o session.o
smooth.o ui.o
utils.o -pthread -L/usr/local/lib -lggobi
-lgtk-x11-2.0 -lxml2
-lgdk-x11-2.0 -latk-1.0
[Rd] Plans for tighter integration of reference classes in R.
Hello Everyone! Here are a couple of thought/questions on refClasses integration in R core functionality. First, coexistence with S4: X - setRefClass(classX, fields = c(a, b), + representation = list(c = character)) x - X$new() x...@c - sss x An object of class classX environment: 059bf6a4 Slot c: [1] sss The above is cool, S4 and refClasses apparently live happily together. But, x$.self An object of class classX environment: 059bf6a4 Slot c: character(0) This is not a surprise, taking into account the copping paradigm of R. Are there any plans to tighten S4refClasses integration? Or it's just not a good idea to mix them as in the above example? Second, R core integration (this bothers me much more): X$methods(m = function(t) a*t) environment(x$m) environment: 059bf6a4 environment(..) does not return the refObject but the basic type. I assume that it is the same with other core functionality. Usage of refObjects as parent.env is also probably precluded in the similar way (don't have a patched R, so can not test yet). Would it be possible, some day, to use refObjects as parent.env or function's environment without loosing the class? Parenthetically, the attributes of an object (including S3 classes) are not lost: env - structure(new.env(), a1 = fdsf, class = old_class) tf - function(x)x environment(tf) - env environment(tf) environment: 056570a0 attr(,a1) [1] fdsf attr(,class) [1] old_class class(environment(tf)) [1] old_class Thanks, Vitalie. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] new.env does not recognize parents from subclassesof environment
Looks like those ETH pages were nnot updated after the R-2.12.0 release
(they do not show current R-tached / R-devel), hence CCing Martin Maechler.
Best,
Uwe Ligges
On 22.10.2010 21:54, Vitally S. wrote:
John Chambersj...@stanford.edu writes:
You need to update your version of R (r-devel or 2.12 patched) to rev
53385 or later, and read NEWS, particularly the line:
- Assignment of an environment to functions or as an attribute to other
objects now works for subclasses of environment.
I am following the news in daily snapshots from here
ftp://ftp.stat.math.ethz.ch/Software/R
and the above line is still not in the NEWS of today's version.
Thanks for the patch. Looking forward to the stable release.
Vitally.
On 10/22/10 10:20 AM, Vitally S. wrote:
Yet another inconsistency. environment- does not work with S4:
setClass(myenv, contains = environment)
[1] myenv
env- new(myenv)
tf- function(x){x}
environment(tf)- env
Error in environment(tf)- env :
replacement object is not an environment
Vitally.
John Chambersj...@stanford.edu writes:
This is a problem related to the introduction of exact= into the [[ and [[-
functions. As Bill says, the
current
method misuses eval.parent() when that argument is added.
However, a simpler and more efficient solution is to migrate the checks for subclasses of
environment used in
other base code into the code for [[- (and for $-), at which point the
methods for these functions are no
longer
needed.
A solution on these lines is being tested now and will find its way into
r-devel and 2.12 patched.
One other point about the original posting:
Please don't use constructions like e...@.xdata. This depends on the current
implementation and is not part of
the
user-level definition. Use as(env, environment) or equivalent. (In this case,
the assignment of the object's
own
environment was irrelevant to the error.)
John Chambers
On 10/21/10 9:21 AM, William Dunlap wrote:
The traceback looks very similar to a problem
in R 2.11.1 reported earlier this month by Troy Robertson.
From: r-devel-boun...@r-project.org
[mailto:r-devel-boun...@r-project.org] On Behalf Of Troy Robertson
Sent: Wednesday, October 06, 2010 6:13 PM
To: 'r-devel@R-project.org'
Subject: Re: [Rd] Recursion error after upgrade to
R_2.11.1[Sec=Unclassified]
It was due to a miscount of how many frames to go
up before evaluating an expression in
getMethod([[-,.environment) because setMethod()
introduced a local function in the new method.
Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com
-Original Message-
From: r-devel-boun...@r-project.org
[mailto:r-devel-boun...@r-project.org] On Behalf Of Vitally S.
Sent: Thursday, October 21, 2010 9:00 AM
To: John Chambers
Cc: r-devel@r-project.org
Subject: Re: [Rd] new.env does not recognize parents from
subclassesof environment
Here is an infinite recursion error which occurs only with S4
subclasses assignment.
setClass(myenv, contains = environment)
#[1] myenv
env- new(myenv)
env[[.me]]- ∑
#Error: evaluation nested too deeply: infinite recursion /
options(expressions=)?
With basic types it works as expected:
env1- new.env()
env1[[.me]]- env1
May be this is related to active bindings that you mentioned,
but I am still
reporting it here.
Vitally.
Thanks for the report. Should now be fixed in r-devel and
2.12 patched (rev 53383).
Please do report any cases where a subclass of environment
doesn't work. There are some known cases in locking and
active binding, that will be fixed in due course.
The workaround for any such problem is usually as.environment().
On 10/20/10 3:17 AM, Vitaly S. wrote:
Dear Developers,
A lot has been changed in the R12.0 with respect to
behavior of environment
subclasses. Many thanks for that.
One small irregularity, though; new.env does not allow the
parent to be from S4
subclass.
setClass(myenv, contains=environment)
[1] myenv
new.env(parent=new(myenv))
Error in new.env(parent = new(myenv)) : 'enclos' must be
an environment
I wonder if this is a planed behavior.
The use of .xData slot obviously works:
new.env(parent=new(myenv)@.xData)
environment: 063bb9e8
Thanks,
Vitaly.
__
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
__
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
Re: [Rd] new.env does not recognize parents from subclassesof environment
On 23.10.2010 17:08, Uwe Ligges wrote:
Looks like those ETH pages were nnot updated after the R-2.12.0 release
(they do not show current R-tached / R-devel), hence CCing Martin Maechler.
... which I actually do now...
Uwe
Best,
Uwe Ligges
On 22.10.2010 21:54, Vitally S. wrote:
John Chambersj...@stanford.edu writes:
You need to update your version of R (r-devel or 2.12 patched) to rev
53385 or later, and read NEWS, particularly the line:
- Assignment of an environment to functions or as an attribute to other
objects now works for subclasses of environment.
I am following the news in daily snapshots from here
ftp://ftp.stat.math.ethz.ch/Software/R
and the above line is still not in the NEWS of today's version.
Thanks for the patch. Looking forward to the stable release.
Vitally.
On 10/22/10 10:20 AM, Vitally S. wrote:
Yet another inconsistency. environment- does not work with S4:
setClass(myenv, contains = environment)
[1] myenv
env- new(myenv)
tf- function(x){x}
environment(tf)- env
Error in environment(tf)- env :
replacement object is not an environment
Vitally.
John Chambersj...@stanford.edu writes:
This is a problem related to the introduction of exact= into the [[
and [[- functions. As Bill says, the
current
method misuses eval.parent() when that argument is added.
However, a simpler and more efficient solution is to migrate the
checks for subclasses of environment used in
other base code into the code for [[- (and for $-), at which
point the methods for these functions are no
longer
needed.
A solution on these lines is being tested now and will find its way
into r-devel and 2.12 patched.
One other point about the original posting:
Please don't use constructions like e...@.xdata. This depends on the
current implementation and is not part of
the
user-level definition. Use as(env, environment) or equivalent.
(In this case, the assignment of the object's
own
environment was irrelevant to the error.)
John Chambers
On 10/21/10 9:21 AM, William Dunlap wrote:
The traceback looks very similar to a problem
in R 2.11.1 reported earlier this month by Troy Robertson.
From: r-devel-boun...@r-project.org
[mailto:r-devel-boun...@r-project.org] On Behalf Of Troy Robertson
Sent: Wednesday, October 06, 2010 6:13 PM
To: 'r-devel@R-project.org'
Subject: Re: [Rd] Recursion error after upgrade to
R_2.11.1[Sec=Unclassified]
It was due to a miscount of how many frames to go
up before evaluating an expression in
getMethod([[-,.environment) because setMethod()
introduced a local function in the new method.
Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com
-Original Message-
From: r-devel-boun...@r-project.org
[mailto:r-devel-boun...@r-project.org] On Behalf Of Vitally S.
Sent: Thursday, October 21, 2010 9:00 AM
To: John Chambers
Cc: r-devel@r-project.org
Subject: Re: [Rd] new.env does not recognize parents from
subclassesof environment
Here is an infinite recursion error which occurs only with S4
subclasses assignment.
setClass(myenv, contains = environment)
#[1] myenv
env- new(myenv)
env[[.me]]- ∑
#Error: evaluation nested too deeply: infinite recursion /
options(expressions=)?
With basic types it works as expected:
env1- new.env()
env1[[.me]]- env1
May be this is related to active bindings that you mentioned,
but I am still
reporting it here.
Vitally.
Thanks for the report. Should now be fixed in r-devel and
2.12 patched (rev 53383).
Please do report any cases where a subclass of environment
doesn't work. There are some known cases in locking and
active binding, that will be fixed in due course.
The workaround for any such problem is usually as.environment().
On 10/20/10 3:17 AM, Vitaly S. wrote:
Dear Developers,
A lot has been changed in the R12.0 with respect to
behavior of environment
subclasses. Many thanks for that.
One small irregularity, though; new.env does not allow the
parent to be from S4
subclass.
setClass(myenv, contains=environment)
[1] myenv
new.env(parent=new(myenv))
Error in new.env(parent = new(myenv)) : 'enclos' must be
an environment
I wonder if this is a planed behavior.
The use of .xData slot obviously works:
new.env(parent=new(myenv)@.xData)
environment: 063bb9e8
Thanks,
Vitaly.
__
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
__
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
Re: [Rd] new.env does not recognize parents from subclassesof environment
2010/10/23 Uwe Ligges lig...@statistik.tu-dortmund.de:
On 23.10.2010 17:08, Uwe Ligges wrote:
Looks like those ETH pages were nnot updated after the R-2.12.0 release
(they do not show current R-tached / R-devel), hence CCing Martin
Maechler.
... which I actually do now...
Hmm, but why?
The daily snapshot page *does* show the current R-patched and R-devel
tar balls ?
Or what were you talking about ?
Regards,
Martin
Uwe
Best,
Uwe Ligges
On 22.10.2010 21:54, Vitally S. wrote:
John Chambersj...@stanford.edu writes:
You need to update your version of R (r-devel or 2.12 patched) to rev
53385 or later, and read NEWS, particularly the line:
- Assignment of an environment to functions or as an attribute to other
objects now works for subclasses of environment.
I am following the news in daily snapshots from here
ftp://ftp.stat.math.ethz.ch/Software/R
and the above line is still not in the NEWS of today's version.
Thanks for the patch. Looking forward to the stable release.
Vitally.
On 10/22/10 10:20 AM, Vitally S. wrote:
Yet another inconsistency. environment- does not work with S4:
setClass(myenv, contains = environment)
[1] myenv
env- new(myenv)
tf- function(x){x}
environment(tf)- env
Error in environment(tf)- env :
replacement object is not an environment
Vitally.
John Chambersj...@stanford.edu writes:
This is a problem related to the introduction of exact= into the [[
and [[- functions. As Bill says, the
current
method misuses eval.parent() when that argument is added.
However, a simpler and more efficient solution is to migrate the
checks for subclasses of environment used in
other base code into the code for [[- (and for $-), at which
point the methods for these functions are no
longer
needed.
A solution on these lines is being tested now and will find its way
into r-devel and 2.12 patched.
One other point about the original posting:
Please don't use constructions like e...@.xdata. This depends on the
current implementation and is not part of
the
user-level definition. Use as(env, environment) or equivalent.
(In this case, the assignment of the object's
own
environment was irrelevant to the error.)
John Chambers
On 10/21/10 9:21 AM, William Dunlap wrote:
The traceback looks very similar to a problem
in R 2.11.1 reported earlier this month by Troy Robertson.
From: r-devel-boun...@r-project.org
[mailto:r-devel-boun...@r-project.org] On Behalf Of Troy Robertson
Sent: Wednesday, October 06, 2010 6:13 PM
To: 'r-devel@R-project.org'
Subject: Re: [Rd] Recursion error after upgrade to
R_2.11.1[Sec=Unclassified]
It was due to a miscount of how many frames to go
up before evaluating an expression in
getMethod([[-,.environment) because setMethod()
introduced a local function in the new method.
Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com
-Original Message-
From: r-devel-boun...@r-project.org
[mailto:r-devel-boun...@r-project.org] On Behalf Of Vitally S.
Sent: Thursday, October 21, 2010 9:00 AM
To: John Chambers
Cc: r-devel@r-project.org
Subject: Re: [Rd] new.env does not recognize parents from
subclassesof environment
Here is an infinite recursion error which occurs only with S4
subclasses assignment.
setClass(myenv, contains = environment)
#[1] myenv
env- new(myenv)
env[[.me]]- ∑
#Error: evaluation nested too deeply: infinite recursion /
options(expressions=)?
With basic types it works as expected:
env1- new.env()
env1[[.me]]- env1
May be this is related to active bindings that you mentioned,
but I am still
reporting it here.
Vitally.
Thanks for the report. Should now be fixed in r-devel and
2.12 patched (rev 53383).
Please do report any cases where a subclass of environment
doesn't work. There are some known cases in locking and
active binding, that will be fixed in due course.
The workaround for any such problem is usually as.environment().
On 10/20/10 3:17 AM, Vitaly S. wrote:
Dear Developers,
A lot has been changed in the R12.0 with respect to
behavior of environment
subclasses. Many thanks for that.
One small irregularity, though; new.env does not allow the
parent to be from S4
subclass.
setClass(myenv, contains=environment)
[1] myenv
new.env(parent=new(myenv))
Error in new.env(parent = new(myenv)) : 'enclos' must be
an environment
I wonder if this is a planed behavior.
The use of .xData slot obviously works:
new.env(parent=new(myenv)@.xData)
environment: 063bb9e8
Thanks,
Vitaly.
__
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] new.env does not recognize parents from subclassesof environment
On 23.10.2010 17:25, Martin Maechler wrote:
2010/10/23 Uwe Liggeslig...@statistik.tu-dortmund.de:
On 23.10.2010 17:08, Uwe Ligges wrote:
Looks like those ETH pages were nnot updated after the R-2.12.0 release
(they do not show current R-tached / R-devel), hence CCing Martin
Maechler.
... which I actually do now...
Hmm, but why?
The daily snapshot page *does* show the current R-patched and R-devel
tar balls ?
Or what were you talking about ?
We are talking about the
http://stat.ethz.ch/R-manual/
page. R-devel NEWS show R-2.12.0, just as on example.
Uwe
Regards,
Martin
Uwe
Best,
Uwe Ligges
On 22.10.2010 21:54, Vitally S. wrote:
John Chambersj...@stanford.edu writes:
You need to update your version of R (r-devel or 2.12 patched) to rev
53385 or later, and read NEWS, particularly the line:
- Assignment of an environment to functions or as an attribute to other
objects now works for subclasses of environment.
I am following the news in daily snapshots from here
ftp://ftp.stat.math.ethz.ch/Software/R
and the above line is still not in the NEWS of today's version.
Thanks for the patch. Looking forward to the stable release.
Vitally.
On 10/22/10 10:20 AM, Vitally S. wrote:
Yet another inconsistency. environment- does not work with S4:
setClass(myenv, contains = environment)
[1] myenv
env- new(myenv)
tf- function(x){x}
environment(tf)- env
Error in environment(tf)- env :
replacement object is not an environment
Vitally.
John Chambersj...@stanford.edu writes:
This is a problem related to the introduction of exact= into the [[
and [[- functions. As Bill says, the
current
method misuses eval.parent() when that argument is added.
However, a simpler and more efficient solution is to migrate the
checks for subclasses of environment used in
other base code into the code for [[- (and for $-), at which
point the methods for these functions are no
longer
needed.
A solution on these lines is being tested now and will find its way
into r-devel and 2.12 patched.
One other point about the original posting:
Please don't use constructions like e...@.xdata. This depends on the
current implementation and is not part of
the
user-level definition. Use as(env, environment) or equivalent.
(In this case, the assignment of the object's
own
environment was irrelevant to the error.)
John Chambers
On 10/21/10 9:21 AM, William Dunlap wrote:
The traceback looks very similar to a problem
in R 2.11.1 reported earlier this month by Troy Robertson.
From: r-devel-boun...@r-project.org
[mailto:r-devel-boun...@r-project.org] On Behalf Of Troy Robertson
Sent: Wednesday, October 06, 2010 6:13 PM
To: 'r-devel@R-project.org'
Subject: Re: [Rd] Recursion error after upgrade to
R_2.11.1[Sec=Unclassified]
It was due to a miscount of how many frames to go
up before evaluating an expression in
getMethod([[-,.environment) because setMethod()
introduced a local function in the new method.
Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com
-Original Message-
From: r-devel-boun...@r-project.org
[mailto:r-devel-boun...@r-project.org] On Behalf Of Vitally S.
Sent: Thursday, October 21, 2010 9:00 AM
To: John Chambers
Cc: r-devel@r-project.org
Subject: Re: [Rd] new.env does not recognize parents from
subclassesof environment
Here is an infinite recursion error which occurs only with S4
subclasses assignment.
setClass(myenv, contains = environment)
#[1] myenv
env- new(myenv)
env[[.me]]- ∑
#Error: evaluation nested too deeply: infinite recursion /
options(expressions=)?
With basic types it works as expected:
env1- new.env()
env1[[.me]]- env1
May be this is related to active bindings that you mentioned,
but I am still
reporting it here.
Vitally.
Thanks for the report. Should now be fixed in r-devel and
2.12 patched (rev 53383).
Please do report any cases where a subclass of environment
doesn't work. There are some known cases in locking and
active binding, that will be fixed in due course.
The workaround for any such problem is usually as.environment().
On 10/20/10 3:17 AM, Vitaly S. wrote:
Dear Developers,
A lot has been changed in the R12.0 with respect to
behavior of environment
subclasses. Many thanks for that.
One small irregularity, though; new.env does not allow the
parent to be from S4
subclass.
setClass(myenv, contains=environment)
[1] myenv
new.env(parent=new(myenv))
Error in new.env(parent = new(myenv)) : 'enclos' must be
an environment
I wonder if this is a planed behavior.
The use of .xData slot obviously works:
new.env(parent=new(myenv)@.xData)
environment: 063bb9e8
Thanks,
Vitaly.
__
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] Plans for tighter integration of reference classes in R.
For reference classes (and other R code) it's important to distinguish the application program interface from the implementation. Anyone is welcome to explore the implementation, but we reserve the right to change that, particularly with a new feature in the language. The draft API for reference classes is the ?ReferenceClasses documentation page at this stage. Second point first: The actual environment of a function is tightly bound to low-level implementation at the C level. Only a _really_ strong practical argument would even tempt us to change that, such as by going away from the requirement that the type of the environment be ENVSXP. (As mentioned in another thread, one point in favor of reference classes is that they have not messed with internals of R evaluation, just used existing techniques.) The API says nothing about what the environment of a reference method is, only that you aren't allowed to use any of the other R tricks that depend on the environment, such as generic functions. Assigning attributes directly to an environment is a bad idea, as discussed in the past on this list. That's why we went to the S4 mechanism for subclasses of environments. As for .self, the documentation says that the entire object can be referred to in a method by the reserved name .self||. That's a bit vague, and it's possible that one could update the slots of .self as part of slot assignment, but absent a serious example, it may be better to just clarify the documentation. On 10/23/10 5:43 AM, Vitalie S. wrote: Hello Everyone! Here are a couple of thought/questions on refClasses integration in R core functionality. First, coexistence with S4: X- setRefClass(classX, fields = c(a, b), + representation = list(c = character)) x- X$new() x...@c- sss x An object of class classX environment: 059bf6a4 Slot c: [1] sss The above is cool, S4 and refClasses apparently live happily together. But, x$.self An object of class classX environment: 059bf6a4 Slot c: character(0) This is not a surprise, taking into account the copping paradigm of R. Are there any plans to tighten S4refClasses integration? Or it's just not a good idea to mix them as in the above example? Second, R core integration (this bothers me much more): X$methods(m = function(t) a*t) environment(x$m) environment: 059bf6a4 environment(..) does not return the refObject but the basic type. I assume that it is the same with other core functionality. Usage of refObjects as parent.env is also probably precluded in the similar way (don't have a patched R, so can not test yet). Would it be possible, some day, to use refObjects as parent.env or function's environment without loosing the class? Parenthetically, the attributes of an object (including S3 classes) are not lost: env- structure(new.env(), a1 = fdsf, class = old_class) tf- function(x)x environment(tf)- env environment(tf) environment: 056570a0 attr(,a1) [1] fdsf attr(,class) [1] old_class class(environment(tf)) [1] old_class Thanks, Vitalie. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] new.env does not recognize parents from subclassesof environment
On Sat, Oct 23, 2010 at 18:23, Peter Dalgaard pda...@gmail.com wrote: On 10/23/2010 05:27 PM, Uwe Ligges wrote: On 23.10.2010 17:25, Martin Maechler wrote: 2010/10/23 Uwe Liggeslig...@statistik.tu-dortmund.de: On 23.10.2010 17:08, Uwe Ligges wrote: Looks like those ETH pages were nnot updated after the R-2.12.0 release (they do not show current R-tached / R-devel), hence CCing Martin Maechler. ... which I actually do now... Hmm, but why? The daily snapshot page *does* show the current R-patched and R-devel tar balls ? Or what were you talking about ? We are talking about the http://stat.ethz.ch/R-manual/ Thank you Uwe. The other e-mail cited John mentioning the ./Software/ page. Indeed those are outdated. and for about 6 weeks. The reason has been ssh host keys changed, disabling a cron job to run the updates... I hope this will be ok, within a couple of hours. page. R-devel NEWS show R-2.12.0, just as on example. Uwe You need to get NEWS from $BUILDDIR these days. Anything left in $SRCDIR is probably a relic. Yes, of course, but that has not been the problem here. Thank you Peter (and Uwe) Martin -- Peter Dalgaard Center for Statistics, Copenhagen Business School Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
