[Rd] TEXINPUTS and Sweave
Is there a way to set TEXINPUTS for CRAN builds so that style files shipped with packages can be found if they are not in the working directory? Apparently there is an additional problem under Windows/MikTeX because recent versions of MikTeX ignore TEXINPUTS! Thanks, Dominick [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] expressions as active bindings?
Hello everyone!
Would it be possible some day to use expressions as active bindings?
Something like
makeActiveExpression(foo, Expr0, env)
where Expr0 is executed in _env_ whenever foo is refereed.
The motivation for this question is fourfold:
- need to use - if the active binding is a function,
- need to create objects in the environments beforehand, to make sure - does
not assign them in a wrong place.
- need to set the environment for function
- active expressions would be faster (would not require the function
invocation)
So instead of :
te - new.env()
te$tempa - 0
myfun - function(x){tempa - 33}
environment(myfun) - te
makeActiveBinding(a, myfun, te)
one would just use:
makeActiveExpression(a, tempa - 33) ?
I noticed that active bindings are very fast:
te$b - expression(tempb - 55)
system.time(evalq(for(i in 1:1e5) a, te))
user system elapsed
0.140.000.14
system.time(evalq(for(i in 1:1e5) eval(b), te))
user system elapsed
0.570.020.57
So, I would assume the active expressions would be even faster.
Thanks,
Vitalie.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] must .Call C functions return SEXP?
On Thu, Oct 28, 2010 at 12:15:56AM -0400, Simon Urbanek wrote: Reason I ask, is I've written some R code which allocates two long lists, and then calls a C function with .Call. My C code writes to those two pre-allocated lists, That's bad! All arguments are essentially read-only so you should never write into them! I don't see how. (So, what am I missing?) The R docs themselves state that the main point of using .Call rather than .C is that .Call does not do any extra copying and gives one direct access to the R objects. (This is indeed very useful, e.g. to reorder a large matrix in seconds rather than hours.) I could allocate the two lists in my C code, but so far it was more convenient to so in R. What possible difference in behavior can there be between the two approaches? R has pass-by-value(!) semantics, so semantically you code has nothing to do with the result.1 and result.2 variables since only their *values* are guaranteed to be passed (possibly a copy). Clearly C code called from .Call must be allowed to construct R objects, as that's how much of R itself is implemented, and further down, it's what you recommend I should do instead. But why does it follow that C code must never modify an object initially allocated by R code? Are you saying there is some special magic difference in the state of an object allocated by R's C code vs. one allocated by R code? If so, what is it? What is the potential problem here, that the garbage collector will suddenly run while my C code is in the middle of writing to an R list? Yes, if the gc is going to move the object elsewhere, that would be very bad. But it looks to me like that cannot happen, because lots of the R implementation itself would fail badly if it did. E.g.: The PROTECT call is used to increment reference counts, but I see no guarantees that it is atomic with the operations that allocate objects. I see no mutexes or other barriers in C code to prevent the gc from running, thus implying that it *can't* run until the C function completes. And R is single threaded, of course. But what about signal handlers, could they ever invoke R's gc? Also, I was initially surprised not to find any matrix C APIs, but grepping for examples (sorry, I don't remember exactly which functions) showed me that the apparently accepted way to do matrix operations from C is to simply assume R's column-first dense matrix order, and access the 2D matrix as a flat 1D vector. (Which is easy.) The fact that internally R attempts to avoid copying for performance reasons is the only reason why your code may have appeared to work, but it's invalid! I will probably change my code to allocate a new list from the C code and return that, as you recommend. My main reason for doing the allocation in R was just that it was simpler, especially given the very limited documentation of R's C API. But, I didn't see anything in the Writing R Extensions doc saying that what my code is doing is invalid, and more importantly, I don't see why it would or should be invalid... I'd still like to better understand why you think doing the initial allocation of an object in R rather than C code is such a problem. So far, I don't see any way that the R interpreter could ever tell the difference. Wait, or is the only objection here that I'm using C in a way that makes pass-by-reference semantics visible to my R code? Which will work completely correctly, but is not the The Proper R Way? I don't actually need pass-by-reference behavior here at all, but I can imagine cases where I might want it, so I'd like to understand your objections better. Is using C to implement pass-by-reference actually Broken, or merely Ugly? From my reasons above, I think it will always work correctly and thus is not Broken. But of course given R's devotion to pass-by-value, it could be considered unacceptably Ugly. -- Andrew Piskorski a...@piskorski.com http://www.piskorski.com/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Reference Classes: Generalizing Reference Class Generator objects?
Is it possible to override the $new(...) in the reference class
generator? I have tried adding a new method to the methods of the
class, but that is obviously not correct. I have also tried adding it to
the class generator, but the class generator still uses the default
constructor.
As a simple example, this is the current interface:
TestClass - setRefClass (TestClass,
fields = list (text = character),
methods = list (
print = function () {cat(text)})
)
test - TestClass$new (text=Hello World)
test$print()
I would like to override $new(...) to be something like (add a \n to
the end of the input, no need to specify input fields):
TestClass$methods (new = function (text) {
text - paste (text, \n)
methods:::new (def, text=text)
})
The constructor would then be:
test - TestClass$new (Hello World)
This is a subtle, but useful change. I have also tried adding to
TestClass a method $newInstance(text), but that was not successful. If
this is not possible, could we consider augmenting the Reference Class
interface to include constructors?
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] must .Call C functions return SEXP?
On Oct 28, 2010, at 9:48 AM, Andrew Piskorski wrote:
On Thu, Oct 28, 2010 at 12:15:56AM -0400, Simon Urbanek wrote:
Reason I ask, is I've written some R code which allocates two long
lists, and then calls a C function with .Call. My C code writes to
those two pre-allocated lists,
That's bad! All arguments are essentially read-only so you should
never write into them!
I don't see how. (So, what am I missing?) The R docs themselves
state that the main point of using .Call rather than .C is that .Call
does not do any extra copying and gives one direct access to the R
objects. (This is indeed very useful, e.g. to reorder a large matrix
in seconds rather than hours.)
Exactly - direct access without copying which means that you are responsible
for not modifying anything you don't own. Again, remember that R has copy by
value semantics so functions can never modify their arguments (at least from
user's point of view).
I could allocate the two lists in my C code, but so far it was more
convenient to so in R.
You don't just allocate them, you also assign them to an environment which is
where the trouble starts. Let's look at a very simple example:
/* do NOT do that kids!! */
SEXP foo(SEXP x) {
REAL(x)[0] = 1;
return x;
}
The expected behavior if R was not performing any tricks behind the scenes
should be in theory:
a = 0
.Call(foo, a)
[1] 1
a
[1] 0
The reason is that in the S language all arguments are passed by value so
.Call(foo, a) really means .Call(foo, 0) so you only change the 0 but not
a. However, R attempts to prevent copying so both the environment holding a
*and* the argument passed to .Call will share memory.
Now, why is it a bad idea to modify arguments? This is why (this is actually
run in R):
a = 0
b = a
.Call(foo, a)
[1] 1
a
[1] 1
b
[1] 1
Because R assumes that you don't mess with the arguments, it also optimizes b
to point to the same object as a which you then modify. Therefor the moment you
start modifying argument all bets are off, because you cannot know which
objects have been optimized to share the same memory so you don't know what
else you'll modify. (More on how you can detect it further down).
There are also rational problems with that:
.Call(foo, 0)
[1] 1
How can you change a 0 constant to 1 ?!?
What possible difference in behavior can there be between the two approaches?
The only way to allocate vectors is with things like numeric(10) but you may
*not* assign it anywhere - that's why .C uses construct like .C(numeric(10),
...) to create result space for DUP=FALSE but the only reason to do so is
because it has no choice. You could call .Call(numeric(10), ...) but that sort
of defeats the purpose and is somewhat dangerous from user's point of view
since your C code would assume that you don't pass anything else (like a
variable or a constant) but a malicious user could pass anything...
R has pass-by-value(!) semantics, so semantically you code has
nothing to do with the result.1 and result.2 variables since only
their *values* are guaranteed to be passed (possibly a copy).
Clearly C code called from .Call must be allowed to construct R
objects, as that's how much of R itself is implemented, and further
down, it's what you recommend I should do instead.
But why does it follow that C code must never modify an object
initially allocated by R code? Are you saying there is some special
magic difference in the state of an object allocated by R's C code
vs. one allocated by R code? If so, what is it?
It's magic of all objects - regardless where they are allocated - and it is
essentially the NAMED bits that decide whether an object is to be copied or
not. The object you passed from R was not yours in that it was shared with
the environment you assigned it to (using result.1 - ..) and your function. If
you allocate it in C you know that it's not owned by anyone else so you can
safely modify it.
Now, we can go more into the internals and you can actually use NAMED to detect
the cases. I'm still not recommending it for the use you mentioned (mostly
because it may change without notice), but it should give you the full picture.
Let's modify the example above by adding Rprintf(NAMED=%d\n, NAMED(x));
Here are the different cases:
.Call(foo, numeric(1))
NAMED=0
[1] 1
# numeric(1) is a direct allocation so it has no reference
a = numeric(1)
.Call(foo, a)
NAMED=1
[1] 1
# numeric(1) was direct allocation then assigned to a - so it has one reference
b = a
.Call(foo, a)
NAMED=2
[1] 1
# the numeric(1) value in both a and b has now two references
# note that it is not a real reference count - it has only the three states
above, so removing b doesn't help
.Call(foo, 1)
NAMED=2
[1] 1
# constants are always flagged to duplicate because they all could share memory
(the real story is a bit different but that's one explanation ;))
So if you wanted to optimize you could treat the above cases
Re: [Rd] must .Call C functions return SEXP?
-Original Message-
From: r-devel-boun...@r-project.org
[mailto:r-devel-boun...@r-project.org] On Behalf Of Andrew Piskorski
Sent: Thursday, October 28, 2010 6:48 AM
To: Simon Urbanek
Cc: r-devel@r-project.org
Subject: Re: [Rd] must .Call C functions return SEXP?
On Thu, Oct 28, 2010 at 12:15:56AM -0400, Simon Urbanek wrote:
Reason I ask, is I've written some R code which allocates two long
lists, and then calls a C function with .Call. My C code
writes to
those two pre-allocated lists,
That's bad! All arguments are essentially read-only so you should
never write into them!
I don't see how. (So, what am I missing?) The R docs themselves
state that the main point of using .Call rather than .C is that .Call
does not do any extra copying and gives one direct access to the R
objects. (This is indeed very useful, e.g. to reorder a large matrix
in seconds rather than hours.)
I could allocate the two lists in my C code, but so far it was more
convenient to so in R. What possible difference in behavior can there
be between the two approaches?
Here is an example of how you break the rule that R-language functions
do not change their arguments if you use .Call in the way that you
describe. The C code is in alter_argument.c:
#include R.h
#include Rinternals.h
SEXP alter_argument(SEXP arg)
{
SEXP dim ;
PROTECT(dim = allocVector(INTSXP, 2));
INTEGER(dim)[0] = 1 ;
INTEGER(dim)[1] = LENGTH(arg) ;
setAttrib(arg, R_DimSymbol, dim);
UNPROTECT(1) ;
return dim ;
}
Make a shared library out of this. E.g., on Linux do
R CMD SHLIB -o Ralter_argument.so alter_argument.so
and load it into R with
dyn.open(./Ralter_argument.so)
(Or, on any platform, put it into a package along with
the following R code and build it.)
The associated R code is
myDim - function(v).Call(alter_argument, v)
f - function(z) myDim(z)[2]
Now try using it:
myData - 6:10
myData
[1] 6 7 8 9 10
f(myData)
[1] 5
myData
[,1] [,2] [,3] [,4] [,5]
[1,]6789 10
The argument to f was changed! This should never happen in R.
If you are very careful you might be able ensure that
no part of the argument to be altered can come from
outside the function calling .Call(). It can be tricky
to ensure that, especially when the argument is more complicated
than an atomic vector.
If you live outside the law you must be honest - Bob Dylan.
In R, .Call() does not copy its arguments but the C code
writer is expected to do so if they will be altered.
In S+ (and S), .Call() copies the arguments if altering
them would make a user-visible change in the environment,
unless you specify that the C code will not be altering them.
Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com
R has pass-by-value(!) semantics, so semantically you code has
nothing to do with the result.1 and result.2 variables since only
their *values* are guaranteed to be passed (possibly a copy).
Clearly C code called from .Call must be allowed to construct R
objects, as that's how much of R itself is implemented, and further
down, it's what you recommend I should do instead.
But why does it follow that C code must never modify an object
initially allocated by R code? Are you saying there is some special
magic difference in the state of an object allocated by R's C code
vs. one allocated by R code? If so, what is it?
What is the potential problem here, that the garbage collector will
suddenly run while my C code is in the middle of writing to an R list?
Yes, if the gc is going to move the object elsewhere, that would be
very bad. But it looks to me like that cannot happen, because lots of
the R implementation itself would fail badly if it did.
E.g.: The PROTECT call is used to increment reference counts, but I
see no guarantees that it is atomic with the operations that allocate
objects. I see no mutexes or other barriers in C code to prevent the
gc from running, thus implying that it *can't* run until the C
function completes.
And R is single threaded, of course. But what about signal handlers,
could they ever invoke R's gc?
Also, I was initially surprised not to find any matrix C APIs, but
grepping for examples (sorry, I don't remember exactly which
functions) showed me that the apparently accepted way to do matrix
operations from C is to simply assume R's column-first dense matrix
order, and access the 2D matrix as a flat 1D vector. (Which is easy.)
The fact that internally R attempts to avoid copying for performance
reasons is the only reason why your code may have appeared to work,
but it's invalid!
I will probably change my code to allocate a new list from the C code
and return that, as you recommend. My main reason for doing the
allocation in R was just that it was simpler, especially given the
very limited documentation of R's C API.
But, I didn't see anything
Re: [Rd] Reference Classes: Generalizing Reference Class Generator objects?
Sorry - you don't need to assign the value of initFields(). I was
going to do it in two lines but then realised one was enough... :)
TestClass - setRefClass (TestClass,
fields = list (text = character),
methods = list (
initialize = function (text) {
initFields(text=paste(text,\n)) },
print = function () { cat(text) } )
)
All the best,
Jon
On 28 October 2010 15:13, Daniel Lee bear...@alum.mit.edu wrote:
Is it possible to override the $new(...) in the reference class generator? I
have tried adding a new method to the methods of the class, but that is
obviously not correct. I have also tried adding it to the class generator,
but the class generator still uses the default constructor.
As a simple example, this is the current interface:
TestClass - setRefClass (TestClass,
fields = list (text = character),
methods = list (
print = function () {cat(text)})
)
test - TestClass$new (text=Hello World)
test$print()
I would like to override $new(...) to be something like (add a \n to the
end of the input, no need to specify input fields):
TestClass$methods (new = function (text) {
text - paste (text, \n)
methods:::new (def, text=text)
})
The constructor would then be:
test - TestClass$new (Hello World)
This is a subtle, but useful change. I have also tried adding to TestClass a
method $newInstance(text), but that was not successful. If this is not
possible, could we consider augmenting the Reference Class interface to
include constructors?
__
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
[Rd] Unexpected behabiour of min, tapply and POSIXct/POSIXlt classes?
Hello, I found rather surprising the behaviour of POSIXct and POSIXlt classes when combined with min and tapply. The details can be deduced from the script below: # Start of the script before - Sys.time() Sys.sleep( 1 ) now1 - now2 - Sys.time() my.times - c( before, now1, now2 ) class( my.times ) ## [1] POSIXct POSIXt min( my.times ) ## [1] 2010-10-28 18:52:17 CEST ### So far, so good... but: my.period - c( a, b, b ) tapply( my.times, my.period, min ) ## a b ## 1288284737 1288284780 ## Where did my POSIXct class go? my.times.lt - as.POSIXlt( my.times ) min( my.times.lt ) ## [1] 2010-10-28 18:52:17 CEST; good! tapply( my.times.lt, my.period, min ) # $a # [1] 17.449 # # $b # [1] 52 # # Mensajes de aviso perdidos # In ansmat[index] - ans : # número de items para para sustituir no es un múltiplo de la longitud del reemplazo # # ¿? :( # End of the script Here are the details of my session (as reported by sessionInfo): R version 2.12.0 (2010-10-15) Platform: i386-pc-mingw32/i386 (32-bit) locale: [1] LC_COLLATE=Spanish_Spain.1252 LC_CTYPE=Spanish_Spain.1252 LC_MONETARY=Spanish_Spain.1252 LC_NUMERIC=C [5] LC_TIME=Spanish_Spain.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base other attached packages: [1] RODBC_1.3-2 plotrix_3.0 loaded via a namespace (and not attached): [1] tools_2.12.0 I am running R on a Windows XP Box. Thank you very much, Carlos J. Gil Bellosta http://www.datanalytics.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Unexpected behabiour of min, tapply and POSIXct/POSIXlt classes?
Hi Carlos, this definitely does not belong to r-devel, just ask it on the normal help list or on www.stackoverflow.com next time. If you read the help file, this behaviour is exactly as expected : ---start quote--- Note that if the return value has a class (e.g. an object of class Date) the class is discarded. ---end quote--- see ?tapply. So you do: tapply( my.times, my.period, min , simplify=F) There's your class. Cheers Joris On Thu, Oct 28, 2010 at 7:11 PM, Carlos J. Gil Bellosta c...@datanalytics.com wrote: Hello, I found rather surprising the behaviour of POSIXct and POSIXlt classes when combined with min and tapply. The details can be deduced from the script below: # Start of the script before - Sys.time() Sys.sleep( 1 ) now1 - now2 - Sys.time() my.times - c( before, now1, now2 ) class( my.times ) ## [1] POSIXct POSIXt min( my.times ) ## [1] 2010-10-28 18:52:17 CEST ### So far, so good... but: my.period - c( a, b, b ) tapply( my.times, my.period, min ) ## a b ## 1288284737 1288284780 ## Where did my POSIXct class go? my.times.lt - as.POSIXlt( my.times ) min( my.times.lt ) ## [1] 2010-10-28 18:52:17 CEST; good! tapply( my.times.lt, my.period, min ) # $a # [1] 17.449 # # $b # [1] 52 # # Mensajes de aviso perdidos # In ansmat[index] - ans : # número de items para para sustituir no es un múltiplo de la longitud del reemplazo # # ¿? :( # End of the script Here are the details of my session (as reported by sessionInfo): R version 2.12.0 (2010-10-15) Platform: i386-pc-mingw32/i386 (32-bit) locale: [1] LC_COLLATE=Spanish_Spain.1252 LC_CTYPE=Spanish_Spain.1252 LC_MONETARY=Spanish_Spain.1252 LC_NUMERIC=C [5] LC_TIME=Spanish_Spain.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base other attached packages: [1] RODBC_1.3-2 plotrix_3.0 loaded via a namespace (and not attached): [1] tools_2.12.0 I am running R on a Windows XP Box. Thank you very much, Carlos J. Gil Bellosta http://www.datanalytics.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Joris Meys Statistical consultant Ghent University Faculty of Bioscience Engineering Department of Applied mathematics, biometrics and process control tel : +32 9 264 59 87 joris.m...@ugent.be --- Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Reference Classes: Generalizing Reference Class Generator objects?
Thank you. Your example really clarifies what the $initialize(...)
function is supposed to do.
Do you know if there is a straightforward way to dispatch the $new(...)
method based on the signature of the arguments? I am thinking along the
lines of S4 methods with valid signatures.
Thanks again for the example.
On 10/28/2010 12:12 PM, Jon Clayden wrote:
Sorry - you don't need to assign the value of initFields(). I was
going to do it in two lines but then realised one was enough... :)
TestClass- setRefClass (TestClass,
fields = list (text = character),
methods = list (
initialize = function (text) {
initFields(text=paste(text,\n)) },
print = function () { cat(text) } )
)
All the best,
Jon
On 28 October 2010 15:13, Daniel Leebear...@alum.mit.edu wrote:
Is it possible to override the $new(...) in the reference class generator? I
have tried adding a new method to the methods of the class, but that is
obviously not correct. I have also tried adding it to the class generator,
but the class generator still uses the default constructor.
As a simple example, this is the current interface:
TestClass- setRefClass (TestClass,
fields = list (text = character),
methods = list (
print = function () {cat(text)})
)
test- TestClass$new (text=Hello World)
test$print()
I would like to override $new(...) to be something like (add a \n to the
end of the input, no need to specify input fields):
TestClass$methods (new = function (text) {
text- paste (text, \n)
methods:::new (def, text=text)
})
The constructor would then be:
test- TestClass$new (Hello World)
This is a subtle, but useful change. I have also tried adding to TestClass a
method $newInstance(text), but that was not successful. If this is not
possible, could we consider augmenting the Reference Class interface to
include constructors?
__
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] Reference Classes: Generalizing Reference Class Generator objects?
?ReferenceClasses says Reference methods can not themselves be
generic functions; if you want additional function-based method
dispatch, write a separate generic function and call that from the
method. So I think you'd need to take that approach in your
initialize method.
Hope this helps,
Jon
On 28 October 2010 18:25, Daniel Lee bear...@alum.mit.edu wrote:
Thank you. Your example really clarifies what the $initialize(...) function
is supposed to do.
Do you know if there is a straightforward way to dispatch the $new(...)
method based on the signature of the arguments? I am thinking along the
lines of S4 methods with valid signatures.
Thanks again for the example.
On 10/28/2010 12:12 PM, Jon Clayden wrote:
Sorry - you don't need to assign the value of initFields(). I was
going to do it in two lines but then realised one was enough... :)
TestClass- setRefClass (TestClass,
fields = list (text = character),
methods = list (
initialize = function (text) {
initFields(text=paste(text,\n)) },
print = function () { cat(text) } )
)
All the best,
Jon
On 28 October 2010 15:13, Daniel Leebear...@alum.mit.edu wrote:
Is it possible to override the $new(...) in the reference class
generator? I
have tried adding a new method to the methods of the class, but that is
obviously not correct. I have also tried adding it to the class
generator,
but the class generator still uses the default constructor.
As a simple example, this is the current interface:
TestClass- setRefClass (TestClass,
fields = list (text = character),
methods = list (
print = function () {cat(text)})
)
test- TestClass$new (text=Hello World)
test$print()
I would like to override $new(...) to be something like (add a \n to
the
end of the input, no need to specify input fields):
TestClass$methods (new = function (text) {
text- paste (text, \n)
methods:::new (def, text=text)
})
The constructor would then be:
test- TestClass$new (Hello World)
This is a subtle, but useful change. I have also tried adding to
TestClass a
method $newInstance(text), but that was not successful. If this is not
possible, could we consider augmenting the Reference Class interface to
include constructors?
__
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] R-2.12.0 hangs while loading RGtk2 on FreeBSD
On Wed, Oct 27, 2010 at 12:09 PM, Rainer Hurling rhur...@gwdg.de wrote:
On 27.10.2010 15:07 (UTC+1), Michael Lawrence wrote:
On Sat, Oct 23, 2010 at 2:49 AM, Rainer Hurling rhur...@gwdg.de
mailto:rhur...@gwdg.de wrote:
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
mailto: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
[Rd] make check-all error on Win 7 with 2-12-.0: vfork: Resource temporarily unavailable
Hi all, I just built R from src on Windows 7 using Rtools212.exe. The build went as usual (R, bitmaps, and manuals all OK) but make check-all failed when running the examples for package 'tcltk': ... running code in 'demos2.R' ... OK running tests of primitives running code in 'primitives.R' ... OK make[2]: vfork: Resource temporarily unavailable make[1]: *** [test-all-devel] Error 1 make: *** [check-all] Error 2 There was no error when I ran make check-all a second time. Just FYI in case this means anything to the heavy-weight developers out there. -Andy __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] must .Call C functions return SEXP?
See comments on Rcpp below.
On Thu, Oct 28, 2010 at 11:28 AM, William Dunlap wdun...@tibco.com wrote:
-Original Message-
From: r-devel-boun...@r-project.org
[mailto:r-devel-boun...@r-project.org] On Behalf Of Andrew Piskorski
Sent: Thursday, October 28, 2010 6:48 AM
To: Simon Urbanek
Cc: r-devel@r-project.org
Subject: Re: [Rd] must .Call C functions return SEXP?
On Thu, Oct 28, 2010 at 12:15:56AM -0400, Simon Urbanek wrote:
Reason I ask, is I've written some R code which allocates two long
lists, and then calls a C function with .Call. My C code
writes to
those two pre-allocated lists,
That's bad! All arguments are essentially read-only so you should
never write into them!
I don't see how. (So, what am I missing?) The R docs themselves
state that the main point of using .Call rather than .C is that .Call
does not do any extra copying and gives one direct access to the R
objects. (This is indeed very useful, e.g. to reorder a large matrix
in seconds rather than hours.)
I could allocate the two lists in my C code, but so far it was more
convenient to so in R. What possible difference in behavior can there
be between the two approaches?
Here is an example of how you break the rule that R-language functions
do not change their arguments if you use .Call in the way that you
describe. The C code is in alter_argument.c:
#include R.h
#include Rinternals.h
SEXP alter_argument(SEXP arg)
{
SEXP dim ;
PROTECT(dim = allocVector(INTSXP, 2));
INTEGER(dim)[0] = 1 ;
INTEGER(dim)[1] = LENGTH(arg) ;
setAttrib(arg, R_DimSymbol, dim);
UNPROTECT(1) ;
return dim ;
}
Make a shared library out of this. E.g., on Linux do
R CMD SHLIB -o Ralter_argument.so alter_argument.so
and load it into R with
dyn.open(./Ralter_argument.so)
(Or, on any platform, put it into a package along with
the following R code and build it.)
The associated R code is
myDim - function(v).Call(alter_argument, v)
f - function(z) myDim(z)[2]
Now try using it:
myData - 6:10
myData
[1] 6 7 8 9 10
f(myData)
[1] 5
myData
[,1] [,2] [,3] [,4] [,5]
[1,]6789 10
The argument to f was changed! This should never happen in R.
If you are very careful you might be able ensure that
no part of the argument to be altered can come from
outside the function calling .Call(). It can be tricky
to ensure that, especially when the argument is more complicated
than an atomic vector.
If you live outside the law you must be honest - Bob Dylan.
This thread seems to suggest (following Bob Dylan) that one needs
to be very careful when using C/C++ to modify R's memory
directly, because you may modify other R variables that point
to the same memory (due to R's copy-by-value semantics and
optimizations).
What are the implications for the Rcpp package where R
objects are exposed to the C++ side in precisely this way,
permitting unrestricted modifications? (In the original
or classic version of this package direct writes to R's
memory were done only for performance reasons.)
Seems like extra precautions need to be taken to
avoid the aliasing problem.
Dominick
In R, .Call() does not copy its arguments but the C code
writer is expected to do so if they will be altered.
In S+ (and S), .Call() copies the arguments if altering
them would make a user-visible change in the environment,
unless you specify that the C code will not be altering them.
Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com
R has pass-by-value(!) semantics, so semantically you code has
nothing to do with the result.1 and result.2 variables since only
their *values* are guaranteed to be passed (possibly a copy).
Clearly C code called from .Call must be allowed to construct R
objects, as that's how much of R itself is implemented, and further
down, it's what you recommend I should do instead.
But why does it follow that C code must never modify an object
initially allocated by R code? Are you saying there is some special
magic difference in the state of an object allocated by R's C code
vs. one allocated by R code? If so, what is it?
What is the potential problem here, that the garbage collector will
suddenly run while my C code is in the middle of writing to an R list?
Yes, if the gc is going to move the object elsewhere, that would be
very bad. But it looks to me like that cannot happen, because lots of
the R implementation itself would fail badly if it did.
E.g.: The PROTECT call is used to increment reference counts, but I
see no guarantees that it is atomic with the operations that allocate
objects. I see no mutexes or other barriers in C code to prevent the
gc from running, thus implying that it *can't* run until the C
function completes.
And R is single threaded, of course. But what about signal handlers,
could they ever
Re: [Rd] R-2.12.0 hangs while loading RGtk2 on FreeBSD
On 28.10.2010 20:07 (UTC+1), Michael Lawrence wrote:
On Wed, Oct 27, 2010 at 12:09 PM, Rainer Hurling rhur...@gwdg.de
mailto:rhur...@gwdg.de wrote:
On 27.10.2010 15:07 (UTC+1), Michael Lawrence wrote:
On Sat, Oct 23, 2010 at 2:49 AM, Rainer Hurling rhur...@gwdg.de
mailto:rhur...@gwdg.de
mailto:rhur...@gwdg.de mailto:rhur...@gwdg.de wrote:
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
mailto:rhur...@gwdg.de mailto:rhur...@gwdg.de
mailto:rhur...@gwdg.de mailto:rhur...@gwdg.de
mailto: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
Re: [Rd] must .Call C functions return SEXP?
On Thu, Oct 28, 2010 at 10:59:26AM -0400, Simon Urbanek wrote: Because R assumes that you don't mess with the arguments, it also optimizes b to point to the same object as a which you then modify. I hope it sheds some light on it. Indeed! Thank you Simon, that was a thorough and illuminating answer. (Now I have better understanding of how the machine works, and what the dangerous sharp bits are. :) -- Andrew Piskorski a...@piskorski.com http://www.piskorski.com/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] make check-all error on Win 7 with 2-12-.0: vfork: Resource temporarily unavailable
This is a problem in the toolset (Cygwin), not in R, and indicates the machine was too busy (more or less as it says). On Thu, 28 Oct 2010, Andy Bunn wrote: Hi all, I just built R from src on Windows 7 using Rtools212.exe. The build went as usual (R, bitmaps, and manuals all OK) but make check-all failed when running the examples for package 'tcltk': ... running code in 'demos2.R' ... OK running tests of primitives running code in 'primitives.R' ... OK make[2]: vfork: Resource temporarily unavailable make[1]: *** [test-all-devel] Error 1 make: *** [check-all] Error 2 There was no error when I ran make check-all a second time. Just FYI in case this means anything to the heavy-weight developers out there. -Andy __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, rip...@stats.ox.ac.uk 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] [Rcpp-devel] must .Call C functions return SEXP?
On Thu, Oct 28, 2010 at 1:44 PM, Dominick Samperi djsamp...@gmail.com wrote:
See comments on Rcpp below.
On Thu, Oct 28, 2010 at 11:28 AM, William Dunlap wdun...@tibco.com wrote:
-Original Message-
From: r-devel-boun...@r-project.org
[mailto:r-devel-boun...@r-project.org] On Behalf Of Andrew Piskorski
Sent: Thursday, October 28, 2010 6:48 AM
To: Simon Urbanek
Cc: r-devel@r-project.org
Subject: Re: [Rd] must .Call C functions return SEXP?
On Thu, Oct 28, 2010 at 12:15:56AM -0400, Simon Urbanek wrote:
Reason I ask, is I've written some R code which allocates two long
lists, and then calls a C function with .Call. My C code
writes to
those two pre-allocated lists,
That's bad! All arguments are essentially read-only so you should
never write into them!
I don't see how. (So, what am I missing?) The R docs themselves
state that the main point of using .Call rather than .C is that .Call
does not do any extra copying and gives one direct access to the R
objects. (This is indeed very useful, e.g. to reorder a large matrix
in seconds rather than hours.)
I could allocate the two lists in my C code, but so far it was more
convenient to so in R. What possible difference in behavior can there
be between the two approaches?
Here is an example of how you break the rule that R-language functions
do not change their arguments if you use .Call in the way that you
describe. The C code is in alter_argument.c:
#include R.h
#include Rinternals.h
SEXP alter_argument(SEXP arg)
{
SEXP dim ;
PROTECT(dim = allocVector(INTSXP, 2));
INTEGER(dim)[0] = 1 ;
INTEGER(dim)[1] = LENGTH(arg) ;
setAttrib(arg, R_DimSymbol, dim);
UNPROTECT(1) ;
return dim ;
}
Make a shared library out of this. E.g., on Linux do
R CMD SHLIB -o Ralter_argument.so alter_argument.so
and load it into R with
dyn.open(./Ralter_argument.so)
(Or, on any platform, put it into a package along with
the following R code and build it.)
The associated R code is
myDim - function(v).Call(alter_argument, v)
f - function(z) myDim(z)[2]
Now try using it:
myData - 6:10
myData
[1] 6 7 8 9 10
f(myData)
[1] 5
myData
[,1] [,2] [,3] [,4] [,5]
[1,] 6 7 8 9 10
The argument to f was changed! This should never happen in R.
If you are very careful you might be able ensure that
no part of the argument to be altered can come from
outside the function calling .Call(). It can be tricky
to ensure that, especially when the argument is more complicated
than an atomic vector.
If you live outside the law you must be honest - Bob Dylan.
This thread seems to suggest (following Bob Dylan) that one needs
to be very careful when using C/C++ to modify R's memory
directly, because you may modify other R variables that point
to the same memory (due to R's copy-by-value semantics and
optimizations).
What are the implications for the Rcpp package where R
objects are exposed to the C++ side in precisely this way,
permitting unrestricted modifications? (In the original
or classic version of this package direct writes to R's
memory were done only for performance reasons.)
Seems like extra precautions need to be taken to
avoid the aliasing problem.
The current Rcpp facilities has the same benefits and dangers as the C
macros used in .Call. You get access to the memory of the R object
passed as an argument, saving a copy step. You shouldn't modify that
memory. If you do, bad things can happen and they will be your fault.
If you want to get a read-write copy you clone the argument (in Rcpp
terminology).
To Bill: I seem to remember the Dylan quote as To live outside the
law you must be honest.
Dominick
In R, .Call() does not copy its arguments but the C code
writer is expected to do so if they will be altered.
In S+ (and S), .Call() copies the arguments if altering
them would make a user-visible change in the environment,
unless you specify that the C code will not be altering them.
Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com
R has pass-by-value(!) semantics, so semantically you code has
nothing to do with the result.1 and result.2 variables since only
their *values* are guaranteed to be passed (possibly a copy).
Clearly C code called from .Call must be allowed to construct R
objects, as that's how much of R itself is implemented, and further
down, it's what you recommend I should do instead.
But why does it follow that C code must never modify an object
initially allocated by R code? Are you saying there is some special
magic difference in the state of an object allocated by R's C code
vs. one allocated by R code? If so, what is it?
What is the potential problem here, that the garbage collector will
suddenly run while my C code is in the middle of writing to an R list?
Yes, if the gc is going to move the object
Re: [Rd] [Rcpp-devel] must .Call C functions return SEXP?
On Thu, Oct 28, 2010 at 6:04 PM, Douglas Bates ba...@stat.wisc.edu wrote:
On Thu, Oct 28, 2010 at 1:44 PM, Dominick Samperi djsamp...@gmail.com
wrote:
See comments on Rcpp below.
On Thu, Oct 28, 2010 at 11:28 AM, William Dunlap wdun...@tibco.com
wrote:
-Original Message-
From: r-devel-boun...@r-project.org
[mailto:r-devel-boun...@r-project.org] On Behalf Of Andrew Piskorski
Sent: Thursday, October 28, 2010 6:48 AM
To: Simon Urbanek
Cc: r-devel@r-project.org
Subject: Re: [Rd] must .Call C functions return SEXP?
On Thu, Oct 28, 2010 at 12:15:56AM -0400, Simon Urbanek wrote:
Reason I ask, is I've written some R code which allocates two long
lists, and then calls a C function with .Call. My C code
writes to
those two pre-allocated lists,
That's bad! All arguments are essentially read-only so you should
never write into them!
I don't see how. (So, what am I missing?) The R docs themselves
state that the main point of using .Call rather than .C is that .Call
does not do any extra copying and gives one direct access to the R
objects. (This is indeed very useful, e.g. to reorder a large matrix
in seconds rather than hours.)
I could allocate the two lists in my C code, but so far it was more
convenient to so in R. What possible difference in behavior can there
be between the two approaches?
Here is an example of how you break the rule that R-language functions
do not change their arguments if you use .Call in the way that you
describe. The C code is in alter_argument.c:
#include R.h
#include Rinternals.h
SEXP alter_argument(SEXP arg)
{
SEXP dim ;
PROTECT(dim = allocVector(INTSXP, 2));
INTEGER(dim)[0] = 1 ;
INTEGER(dim)[1] = LENGTH(arg) ;
setAttrib(arg, R_DimSymbol, dim);
UNPROTECT(1) ;
return dim ;
}
Make a shared library out of this. E.g., on Linux do
R CMD SHLIB -o Ralter_argument.so alter_argument.so
and load it into R with
dyn.open(./Ralter_argument.so)
(Or, on any platform, put it into a package along with
the following R code and build it.)
The associated R code is
myDim - function(v).Call(alter_argument, v)
f - function(z) myDim(z)[2]
Now try using it:
myData - 6:10
myData
[1] 6 7 8 9 10
f(myData)
[1] 5
myData
[,1] [,2] [,3] [,4] [,5]
[1,]6789 10
The argument to f was changed! This should never happen in R.
If you are very careful you might be able ensure that
no part of the argument to be altered can come from
outside the function calling .Call(). It can be tricky
to ensure that, especially when the argument is more complicated
than an atomic vector.
If you live outside the law you must be honest - Bob Dylan.
This thread seems to suggest (following Bob Dylan) that one needs
to be very careful when using C/C++ to modify R's memory
directly, because you may modify other R variables that point
to the same memory (due to R's copy-by-value semantics and
optimizations).
What are the implications for the Rcpp package where R
objects are exposed to the C++ side in precisely this way,
permitting unrestricted modifications? (In the original
or classic version of this package direct writes to R's
memory were done only for performance reasons.)
Seems like extra precautions need to be taken to
avoid the aliasing problem.
The current Rcpp facilities has the same benefits and dangers as the C
macros used in .Call. You get access to the memory of the R object
passed as an argument, saving a copy step. You shouldn't modify that
memory. If you do, bad things can happen and they will be your fault.
If you want to get a read-write copy you clone the argument (in Rcpp
terminology).
To Bill: I seem to remember the Dylan quote as To live outside the
law you must be honest.
And There are No Truths Outside the Gates of Eden.
Cool, a Dylan thread...
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] list2env() is broken
Hi, The following code produces different kinds of problems depending on which platform you run it: x - as.list(1:20) names(x) - paste(A, 1:20, sep=) e - list2env(x) Timeout on Linux, crash on Mac and Windows, with R 2.12.0 and current R devel. The multi-assign mode (i.e. when the 'envir' arg is supplied) doesn't seem to have this problem. Cheers, H. -- 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
