[Rd] concurrent requests (Rook, but I think the question is more general)
This question involves Rook, but I think the answer will be general
enough that it pays to post here. At any rate, I don't know enough to
know whether this is a Rook only issue or a general R issue.
Here's what I'd like to do (and indeed, have code that should do this):
1. Start R, Rook
2. Start an analysis via a HTTP request to Rook. This analysis uses
.Call() to some compiled C code, if that matters. The C code calls a
callback function to update a variable with its progress.
3. While the analysis is happening, use Rook to obtain current status
with an HTTP request
The problem is that once the analysis starts, Rook does not respond to
requests. All of the status requests to Rook pile up, and then are
answered when the analysis (step 2) is done. Here is some example code
to demonstrate what the issue:
##
library(Rook)
s <- Rhttpd$new()
s$add(
name="pingpong",
app=Rook::URLMap$new(
'/ping' = function(env){
req <- Rook::Request$new(env)
res <- Rook::Response$new()
res$write('This is ping.')
Sys.sleep(20)
res$finish()
},
'/pong' = function(env){
req <- Rook::Request$new(env)
res <- Rook::Response$new()
res$write("This is pong.")
res$finish()
},
'/?' = function(env){
req <- Rook::Request$new(env)
res <- Rook::Response$new()
res$redirect(req$to_url('/pong'))
res$finish()
}
)
)
s$start(quiet=TRUE)
s$browse('pingpong')
#
If you request /ping, R runs Sys.sleep() for 20 seconds. This is where
my .Call() statement would be. While the .Call() (Sys.sleep()) function
is doing its thing, I need to get Rook to respond on /pong (which would
simply respond with the progress), but if you run this code, request
/ping, then immediately request /pong, you'll see that the /pong request
will not be answered until the Sys.sleep() is done.
Of course, for a progress report to be useful, the requests have to be
answered immediately. Is this a Rook issue, or an R issue? Or am I
asking something unreasonable?
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] concurrent requests (Rook, but I think the question is more general)
On Wed, Oct 24, 2012 at 11:13 AM, Richard D. Morey wrote:
> This question involves Rook, but I think the answer will be general enough
> that it pays to post here. At any rate, I don't know enough to know whether
> this is a Rook only issue or a general R issue.
>
> Here's what I'd like to do (and indeed, have code that should do this):
>
> 1. Start R, Rook
> 2. Start an analysis via a HTTP request to Rook. This analysis uses .Call()
> to some compiled C code, if that matters. The C code calls a callback
> function to update a variable with its progress.
> 3. While the analysis is happening, use Rook to obtain current status with
> an HTTP request
>
> The problem is that once the analysis starts, Rook does not respond to
> requests. All of the status requests to Rook pile up, and then are answered
> when the analysis (step 2) is done. Here is some example code to demonstrate
> what the issue:
>
> ##
>
> library(Rook)
> s <- Rhttpd$new()
> s$add(
> name="pingpong",
> app=Rook::URLMap$new(
> '/ping' = function(env){
> req <- Rook::Request$new(env)
> res <- Rook::Response$new()
> res$write('This is ping.')
> Sys.sleep(20)
> res$finish()
> },
> '/pong' = function(env){
> req <- Rook::Request$new(env)
> res <- Rook::Response$new()
> res$write("This is pong.")
> res$finish()
> },
> '/?' = function(env){
> req <- Rook::Request$new(env)
> res <- Rook::Response$new()
> res$redirect(req$to_url('/pong'))
> res$finish()
> }
> )
> )
>
> s$start(quiet=TRUE)
> s$browse('pingpong')
>
> #
>
> If you request /ping, R runs Sys.sleep() for 20 seconds. This is where my
> .Call() statement would be. While the .Call() (Sys.sleep()) function is
> doing its thing, I need to get Rook to respond on /pong (which would simply
> respond with the progress), but if you run this code, request /ping, then
> immediately request /pong, you'll see that the /pong request will not be
> answered until the Sys.sleep() is done.
>
> Of course, for a progress report to be useful, the requests have to be
> answered immediately. Is this a Rook issue, or an R issue? Or am I asking
> something unreasonable?
One answer would be to start an Rserve instance on your local machine.
When your web app initiates processing, it actually starts the
long-running task on the server with RS.eval(wait=FALSE). See ?RCC
with the RS.client package loaded.
Then when you check for task completion, call RS.collect () with a
short timeout, and if it has something for you it will give it to you.
That doesn't give you a numeric progress report, but perhaps if your
long-running task writes its status somewhere (to a file?) the
progress-checking task could look there as well.
Dan
>
> __
> 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] concurrent requests (Rook, but I think the question is more general)
On Oct 24, 2012, at 2:13 PM, Richard D. Morey wrote:
> This question involves Rook, but I think the answer will be general enough
> that it pays to post here. At any rate, I don't know enough to know whether
> this is a Rook only issue or a general R issue.
>
> Here's what I'd like to do (and indeed, have code that should do this):
>
> 1. Start R, Rook
> 2. Start an analysis via a HTTP request to Rook. This analysis uses .Call()
> to some compiled C code, if that matters. The C code calls a callback
> function to update a variable with its progress.
> 3. While the analysis is happening, use Rook to obtain current status with an
> HTTP request
>
You can't. R doesn't support threading so it's simply not possible to have an
asynchronous eval. The R HTTP server works by simply enqueuing an eval to run
while R is idle, it can't do that if R is busy. (Note that the HTTP server was
*only* designed for the internal help).
What you can do is have your C code start another thread that reports the
progress when asked e.g. on a socket, but that thread is not allowed to call
any R API so you want that progress to be entirely in your C code.
Note that if your C code is robust enough, it can call R_CheckUserInterrupt()
to allow external events to happen, but a) your C code must in that case be
prepared for early termination (clean up memory etc.) and b) I don't remember
if the httpd is allowed to run during interrupt check on all platforms - you
may want to check that first.
Cheers,
Simon
> The problem is that once the analysis starts, Rook does not respond to
> requests. All of the status requests to Rook pile up, and then are answered
> when the analysis (step 2) is done. Here is some example code to demonstrate
> what the issue:
>
> ##
>
> library(Rook)
> s <- Rhttpd$new()
> s$add(
> name="pingpong",
> app=Rook::URLMap$new(
>'/ping' = function(env){
> req <- Rook::Request$new(env)
> res <- Rook::Response$new()
> res$write('This is ping.')
> Sys.sleep(20)
> res$finish()
>},
>'/pong' = function(env){
> req <- Rook::Request$new(env)
> res <- Rook::Response$new()
> res$write("This is pong.")
> res$finish()
>},
>'/?' = function(env){
> req <- Rook::Request$new(env)
> res <- Rook::Response$new()
> res$redirect(req$to_url('/pong'))
> res$finish()
>}
> )
> )
>
> s$start(quiet=TRUE)
> s$browse('pingpong')
>
> #
>
> If you request /ping, R runs Sys.sleep() for 20 seconds. This is where my
> .Call() statement would be. While the .Call() (Sys.sleep()) function is doing
> its thing, I need to get Rook to respond on /pong (which would simply respond
> with the progress), but if you run this code, request /ping, then immediately
> request /pong, you'll see that the /pong request will not be answered until
> the Sys.sleep() is done.
>
> Of course, for a progress report to be useful, the requests have to be
> answered immediately. Is this a Rook issue, or an R issue? Or am I asking
> something unreasonable?
>
> __
> 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] concurrent requests (Rook, but I think the question is more general)
On 24/10/12 8:53 PM, Simon Urbanek wrote:
On Oct 24, 2012, at 2:13 PM, Richard D. Morey wrote:
This question involves Rook, but I think the answer will be general enough that
it pays to post here. At any rate, I don't know enough to know whether this is
a Rook only issue or a general R issue.
Here's what I'd like to do (and indeed, have code that should do this):
1. Start R, Rook
2. Start an analysis via a HTTP request to Rook. This analysis uses .Call() to
some compiled C code, if that matters. The C code calls a callback function to
update a variable with its progress.
3. While the analysis is happening, use Rook to obtain current status with an
HTTP request
You can't. R doesn't support threading so it's simply not possible to have an
asynchronous eval. The R HTTP server works by simply enqueuing an eval to run
while R is idle, it can't do that if R is busy. (Note that the HTTP server was
*only* designed for the internal help).
What you can do is have your C code start another thread that reports the
progress when asked e.g. on a socket, but that thread is not allowed to call
any R API so you want that progress to be entirely in your C code.
How can I start a new thread? By running R again from the command line,
or is there a better way?
Note that if your C code is robust enough, it can call R_CheckUserInterrupt()
to allow external events to happen, but a) your C code must in that case be
prepared for early termination (clean up memory etc.) and b) I don't remember
if the httpd is allowed to run during interrupt check on all platforms - you
may want to check that first.
I do use R_CheckUserInterrupt(), but if I understand what you're saying
then given that it doesn't work, httpd must not run during the interrupt
check. At least, on OSX, which is what I'm testing on.
Cheers,
Simon
The problem is that once the analysis starts, Rook does not respond to
requests. All of the status requests to Rook pile up, and then are answered
when the analysis (step 2) is done. Here is some example code to demonstrate
what the issue:
##
library(Rook)
s <- Rhttpd$new()
s$add(
name="pingpong",
app=Rook::URLMap$new(
'/ping' = function(env){
req <- Rook::Request$new(env)
res <- Rook::Response$new()
res$write('This is ping.')
Sys.sleep(20)
res$finish()
},
'/pong' = function(env){
req <- Rook::Request$new(env)
res <- Rook::Response$new()
res$write("This is pong.")
res$finish()
},
'/?' = function(env){
req <- Rook::Request$new(env)
res <- Rook::Response$new()
res$redirect(req$to_url('/pong'))
res$finish()
}
)
)
s$start(quiet=TRUE)
s$browse('pingpong')
#
If you request /ping, R runs Sys.sleep() for 20 seconds. This is where my
.Call() statement would be. While the .Call() (Sys.sleep()) function is doing
its thing, I need to get Rook to respond on /pong (which would simply respond
with the progress), but if you run this code, request /ping, then immediately
request /pong, you'll see that the /pong request will not be answered until the
Sys.sleep() is done.
Of course, for a progress report to be useful, the requests have to be answered
immediately. Is this a Rook issue, or an R issue? Or am I asking something
unreasonable?
__
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] concurrent requests (Rook, but I think the question is more general)
On Oct 24, 2012, at 3:09 PM, Richard D. Morey wrote:
> On 24/10/12 8:53 PM, Simon Urbanek wrote:
>> On Oct 24, 2012, at 2:13 PM, Richard D. Morey wrote:
>>
>>> This question involves Rook, but I think the answer will be general enough
>>> that it pays to post here. At any rate, I don't know enough to know whether
>>> this is a Rook only issue or a general R issue.
>>>
>>> Here's what I'd like to do (and indeed, have code that should do this):
>>>
>>> 1. Start R, Rook
>>> 2. Start an analysis via a HTTP request to Rook. This analysis uses .Call()
>>> to some compiled C code, if that matters. The C code calls a callback
>>> function to update a variable with its progress.
>>> 3. While the analysis is happening, use Rook to obtain current status with
>>> an HTTP request
>>>
>> You can't. R doesn't support threading so it's simply not possible to have
>> an asynchronous eval. The R HTTP server works by simply enqueuing an eval to
>> run while R is idle, it can't do that if R is busy. (Note that the HTTP
>> server was *only* designed for the internal help).
>>
>> What you can do is have your C code start another thread that reports the
>> progress when asked e.g. on a socket, but that thread is not allowed to call
>> any R API so you want that progress to be entirely in your C code.
> How can I start a new thread? By running R again from the command line, or is
> there a better way?
>
No, you have to use the system thread API like pthreads, NSThread etc. If you
have to ask about this, you probably don't want to go there ;) - threads can be
quite dangerous if you are not familiar with them.
Another poor man's solution is to simply have your C code write out a file with
the progress. Along the same lines you could use a shared object to store the
progress (e.g. via bigmemory) ...
>> Note that if your C code is robust enough, it can call
>> R_CheckUserInterrupt() to allow external events to happen, but a) your C
>> code must in that case be prepared for early termination (clean up memory
>> etc.) and b) I don't remember if the httpd is allowed to run during
>> interrupt check on all platforms - you may want to check that first.
> I do use R_CheckUserInterrupt(), but if I understand what you're saying then
> given that it doesn't work, httpd must not run during the interrupt check. At
> least, on OSX, which is what I'm testing on.
>
Yes, if your code calls R_CheckUserInterrupt() and httpd doesn't respond at
that point then it may not be allowed to run. On OS X you can try your luck
with R_ProcessEvents() as well.
Cheers,
Simon
>> Cheers,
>> Simon
>>
>>
>>
>>
>>> The problem is that once the analysis starts, Rook does not respond to
>>> requests. All of the status requests to Rook pile up, and then are answered
>>> when the analysis (step 2) is done. Here is some example code to
>>> demonstrate what the issue:
>>>
>>> ##
>>>
>>> library(Rook)
>>> s <- Rhttpd$new()
>>> s$add(
>>> name="pingpong",
>>> app=Rook::URLMap$new(
>>>'/ping' = function(env){
>>> req <- Rook::Request$new(env)
>>> res <- Rook::Response$new()
>>> res$write('This is ping.')
>>> Sys.sleep(20)
>>> res$finish()
>>>},
>>>'/pong' = function(env){
>>> req <- Rook::Request$new(env)
>>> res <- Rook::Response$new()
>>> res$write("This is pong.")
>>> res$finish()
>>>},
>>>'/?' = function(env){
>>> req <- Rook::Request$new(env)
>>> res <- Rook::Response$new()
>>> res$redirect(req$to_url('/pong'))
>>> res$finish()
>>>}
>>> )
>>> )
>>>
>>> s$start(quiet=TRUE)
>>> s$browse('pingpong')
>>>
>>> #
>>>
>>> If you request /ping, R runs Sys.sleep() for 20 seconds. This is where my
>>> .Call() statement would be. While the .Call() (Sys.sleep()) function is
>>> doing its thing, I need to get Rook to respond on /pong (which would simply
>>> respond with the progress), but if you run this code, request /ping, then
>>> immediately request /pong, you'll see that the /pong request will not be
>>> answered until the Sys.sleep() is done.
>>>
>>> Of course, for a progress report to be useful, the requests have to be
>>> answered immediately. Is this a Rook issue, or an R issue? Or am I asking
>>> something unreasonable?
>>>
>>> __
>>> 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] concurrent requests (Rook, but I think the question is more general)
Richard D. Morey
Assistant Professor
Psychometrics and Statistics
Rijksuniversiteit Groningen / University of Groningen
http://drsmorey.org/research/rdmorey
On 24/10/12 9:23 PM, Simon Urbanek wrote:
On Oct 24, 2012, at 3:09 PM, Richard D. Morey wrote:
On 24/10/12 8:53 PM, Simon Urbanek wrote:
On Oct 24, 2012, at 2:13 PM, Richard D. Morey wrote:
This question involves Rook, but I think the answer will be general enough that
it pays to post here. At any rate, I don't know enough to know whether this is
a Rook only issue or a general R issue.
Here's what I'd like to do (and indeed, have code that should do this):
1. Start R, Rook
2. Start an analysis via a HTTP request to Rook. This analysis uses .Call() to
some compiled C code, if that matters. The C code calls a callback function to
update a variable with its progress.
3. While the analysis is happening, use Rook to obtain current status with an
HTTP request
You can't. R doesn't support threading so it's simply not possible to have an
asynchronous eval. The R HTTP server works by simply enqueuing an eval to run
while R is idle, it can't do that if R is busy. (Note that the HTTP server was
*only* designed for the internal help).
What you can do is have your C code start another thread that reports the
progress when asked e.g. on a socket, but that thread is not allowed to call
any R API so you want that progress to be entirely in your C code.
How can I start a new thread? By running R again from the command line, or is
there a better way?
No, you have to use the system thread API like pthreads, NSThread etc. If you
have to ask about this, you probably don't want to go there ;) - threads can be
quite dangerous if you are not familiar with them.
Another poor man's solution is to simply have your C code write out a file with
the progress. Along the same lines you could use a shared object to store the
progress (e.g. via bigmemory) ...
I'd be fine with the poor man's solution (maybe with tempfile()?) if I
can get access to the local file via javascript. But I don't think I
can, due to the security limitations of the browser. I may have to
rethink this significantly.
Note that if your C code is robust enough, it can call R_CheckUserInterrupt()
to allow external events to happen, but a) your C code must in that case be
prepared for early termination (clean up memory etc.) and b) I don't remember
if the httpd is allowed to run during interrupt check on all platforms - you
may want to check that first.
I do use R_CheckUserInterrupt(), but if I understand what you're saying then
given that it doesn't work, httpd must not run during the interrupt check. At
least, on OSX, which is what I'm testing on.
Yes, if your code calls R_CheckUserInterrupt() and httpd doesn't respond at
that point then it may not be allowed to run. On OS X you can try your luck
with R_ProcessEvents() as well.
Cheers,
Simon
Cheers,
Simon
The problem is that once the analysis starts, Rook does not respond to
requests. All of the status requests to Rook pile up, and then are answered
when the analysis (step 2) is done. Here is some example code to demonstrate
what the issue:
##
library(Rook)
s <- Rhttpd$new()
s$add(
name="pingpong",
app=Rook::URLMap$new(
'/ping' = function(env){
req <- Rook::Request$new(env)
res <- Rook::Response$new()
res$write('This is ping.')
Sys.sleep(20)
res$finish()
},
'/pong' = function(env){
req <- Rook::Request$new(env)
res <- Rook::Response$new()
res$write("This is pong.")
res$finish()
},
'/?' = function(env){
req <- Rook::Request$new(env)
res <- Rook::Response$new()
res$redirect(req$to_url('/pong'))
res$finish()
}
)
)
s$start(quiet=TRUE)
s$browse('pingpong')
#
If you request /ping, R runs Sys.sleep() for 20 seconds. This is where my
.Call() statement would be. While the .Call() (Sys.sleep()) function is doing
its thing, I need to get Rook to respond on /pong (which would simply respond
with the progress), but if you run this code, request /ping, then immediately
request /pong, you'll see that the /pong request will not be answered until the
Sys.sleep() is done.
Of course, for a progress report to be useful, the requests have to be answered
immediately. Is this a Rook issue, or an R issue? Or am I asking something
unreasonable?
__
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] Getting ordered factor levels from C
I'm working on an R package in C and can't seem to get the same level
information about a factor that the R console displays.
If I define a factor as:
lvls <- factor(c('red','blue','blue','green','red'), c('blue','green','red'),
ordered=TRUE)
When I get the "levels" attribute in C, I get back the the first vector, not
the second. If I run attr(lvls,"levels") in R, I get back the second vector.
There are no attributes besides class and levels, so how do I get the list of
levels in the correct order?
Thanks
--
Mark Lilback
West Virginia University Department of Statistics
mlilb...@stat.wvu.edu
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] concurrent requests (Rook, but I think the question is more general)
On Oct 24, 2012, at 3:47 PM, Richard D. Morey wrote:
>
> Richard D. Morey
> Assistant Professor
> Psychometrics and Statistics
> Rijksuniversiteit Groningen / University of Groningen
> http://drsmorey.org/research/rdmorey
>
> On 24/10/12 9:23 PM, Simon Urbanek wrote:
>> On Oct 24, 2012, at 3:09 PM, Richard D. Morey wrote:
>>
>>> On 24/10/12 8:53 PM, Simon Urbanek wrote:
On Oct 24, 2012, at 2:13 PM, Richard D. Morey wrote:
> This question involves Rook, but I think the answer will be general
> enough that it pays to post here. At any rate, I don't know enough to
> know whether this is a Rook only issue or a general R issue.
>
> Here's what I'd like to do (and indeed, have code that should do this):
>
> 1. Start R, Rook
> 2. Start an analysis via a HTTP request to Rook. This analysis uses
> .Call() to some compiled C code, if that matters. The C code calls a
> callback function to update a variable with its progress.
> 3. While the analysis is happening, use Rook to obtain current status
> with an HTTP request
>
You can't. R doesn't support threading so it's simply not possible to have
an asynchronous eval. The R HTTP server works by simply enqueuing an eval
to run while R is idle, it can't do that if R is busy. (Note that the HTTP
server was *only* designed for the internal help).
What you can do is have your C code start another thread that reports the
progress when asked e.g. on a socket, but that thread is not allowed to
call any R API so you want that progress to be entirely in your C code.
>>> How can I start a new thread? By running R again from the command line, or
>>> is there a better way?
>>>
>> No, you have to use the system thread API like pthreads, NSThread etc. If
>> you have to ask about this, you probably don't want to go there ;) - threads
>> can be quite dangerous if you are not familiar with them.
>>
>> Another poor man's solution is to simply have your C code write out a file
>> with the progress. Along the same lines you could use a shared object to
>> store the progress (e.g. via bigmemory) ...
>
> I'd be fine with the poor man's solution (maybe with tempfile()?) if I can
> get access to the local file via javascript. But I don't think I can, due to
> the security limitations of the browser. I may have to rethink this
> significantly.
>
That should be no problem, you can have another R instance serving the
monitoring page (or you can use Rserve's HTTP server and have just one instance
with arbitrarily many connections as needed).
Cheers,
Simon
>>
>>
Note that if your C code is robust enough, it can call
R_CheckUserInterrupt() to allow external events to happen, but a) your C
code must in that case be prepared for early termination (clean up memory
etc.) and b) I don't remember if the httpd is allowed to run during
interrupt check on all platforms - you may want to check that first.
>>> I do use R_CheckUserInterrupt(), but if I understand what you're saying
>>> then given that it doesn't work, httpd must not run during the interrupt
>>> check. At least, on OSX, which is what I'm testing on.
>>>
>> Yes, if your code calls R_CheckUserInterrupt() and httpd doesn't respond at
>> that point then it may not be allowed to run. On OS X you can try your luck
>> with R_ProcessEvents() as well.
>>
>> Cheers,
>> Simon
>>
>>
>>
Cheers,
Simon
> The problem is that once the analysis starts, Rook does not respond to
> requests. All of the status requests to Rook pile up, and then are
> answered when the analysis (step 2) is done. Here is some example code to
> demonstrate what the issue:
>
> ##
>
> library(Rook)
> s <- Rhttpd$new()
> s$add(
> name="pingpong",
> app=Rook::URLMap$new(
>'/ping' = function(env){
> req <- Rook::Request$new(env)
> res <- Rook::Response$new()
> res$write('This is ping.')
> Sys.sleep(20)
> res$finish()
>},
>'/pong' = function(env){
> req <- Rook::Request$new(env)
> res <- Rook::Response$new()
> res$write("This is pong.")
> res$finish()
>},
>'/?' = function(env){
> req <- Rook::Request$new(env)
> res <- Rook::Response$new()
> res$redirect(req$to_url('/pong'))
> res$finish()
>}
> )
> )
>
> s$start(quiet=TRUE)
> s$browse('pingpong')
>
> #
>
> If you request /ping, R runs Sys.sleep() for 20 seconds. This is where my
> .Call() statement would be. While the .Call() (Sys.sleep()) function is
> doing its thing, I need to get Rook to respond on /pong (which would
> simply respond with the progress), but if you run this code, request
> /ping, then immediately request
[Rd] Shouldn't the \usage section tell the truth?
Hi,
The signature of mget() changed between R-2.15.1 and recent R-devel.
In R-2.15.1:
> args(mget)
function (x, envir, mode = "any", ifnotfound = list(function(x)
stop(paste0("value for '",
x, "' not found"), call. = FALSE)), inherits = FALSE)
NULL
In R-devel:
> args(mget)
function (x, envir, mode = "any", ifnotfound = list(function(x)
stop(gettextf("value for %s not found",
sQuote(x)), call. = FALSE, domain = NA)), inherits = FALSE)
NULL
What has changed exactly is the default value for the 'ifnotfound'
argument. This change generates an 'R CMD check' warning for the
BiocGenerics package where the \usage section is still using
the old default:
* checking for code/documentation mismatches ... WARNING
Codoc mismatches from documentation object 'get':
mget
Code: function(x, envir, mode = "any", ifnotfound = list(function(x)
stop(gettextf("value for %s not found", sQuote(x)),
call. = FALSE, domain = NA)), inherits = FALSE)
Docs: function(x, envir, mode = "any", ifnotfound = list(function(x)
stop(paste0("value for '", x, "' not found"), call. =
FALSE)), inherits = FALSE)
Mismatches in argument default values:
Name: 'ifnotfound'
Code: list(function(x) stop(gettextf("value for %s not found",
sQuote(x)),
call. = FALSE, domain = NA))
Docs: list(function(x) stop(paste0("value for '", x, "' not found"),
call. = FALSE))
It's good to have the warning, and the fix is easy.
Now surprisingly, in R-devel, the \usage section for mget() doesn't
show the new default value (it used to in previous versions of R):
mget(x, envir, mode = "any", ifnotfound, inherits = FALSE)
As you can see, it doesn't show a default value at all! And it
seems that 'R CMD check' is fine with that.
So my question is: is this the intended behavior for 'R CMD check'?
I hope not.
My view on argument default values is that they are fully part of the
API so they should appear in the \usage section. I can see that the
default value for 'ifnotfound' is not very exciting and showing it
in the \usage section is not that helpful (and can fairly be considered
distracting). But isn't this a situation where the default value
should rather be set to NULL or NA? Or, alternatively, no default
value is specified in the argument list and 'if (missing(ifnotfound))'
is used internally? Note that what is shown in \usage for mget() is
suggesting that this last solution was retained, which is misleading.
Then, whatever solution is used (NULL, NA, or no default value at
all), the documentation should probably explain how the argument
will be handled in case it's missing (unless this is obvious).
Anyway, what solution should be retained for mget() is not important.
My point is that the \usage section should tell the truth, and, if
not, 'R CMD check' should issue a warning.
Many times we've seen argument default values for Bioconductor functions
not reported in the \usage section. Each time it was
*not* intended (typically the maintainer would add the argument
default value in the function definition and forget to update the
\usage section). And each time, when someone brings this to the
attention of the maintainer (sometimes weeks or months later),
everybody was surprised that 'R CMD check' didn't report the problem.
Hopefully that can be fixed.
Thanks in advance,
H.
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
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] Getting ordered factor levels from C
On Oct 24, 2012, at 2:14 PM, Mark Lilback wrote:
> I'm working on an R package in C and can't seem to get the same level
> information about a factor that the R console displays.
>
> If I define a factor as:
>
> lvls <- factor(c('red','blue','blue','green','red'), c('blue','green','red'),
> ordered=TRUE)
>
> When I get the "levels" attribute in C, I get back the the first vector, not
> the second.
What are you using in C? AFAICS it works just fine:
> f=cfunction(c(foo="factor"), "return getAttrib(foo, R_LevelsSymbol);")
> f(lvls)
[1] "blue" "green" "red"
Cheers,
Simon
> If I run attr(lvls,"levels") in R, I get back the second vector. There are no
> attributes besides class and levels, so how do I get the list of levels in
> the correct order?
>
> Thanks
>
> --
> Mark Lilback
> West Virginia University Department of Statistics
> mlilb...@stat.wvu.edu
>
> __
> 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] concurrent requests (Rook, but I think the question is more general)
On 24/10/12 10:07 PM, Simon Urbanek wrote: On Oct 24, 2012, at 3:47 PM, Richard D. Morey wrote: I'd be fine with the poor man's solution (maybe with tempfile()?) if I can get access to the local file via javascript. But I don't think I can, due to the security limitations of the browser. I may have to rethink this significantly. That should be no problem, you can have another R instance serving the monitoring page (or you can use Rserve's HTTP server and have just one instance with arbitrarily many connections as needed). OK, I'm looking at Rserve. I get the impression that one needs to start a separate server, so it would be difficult to make this transparent to a user who installs my package and just wants to do an analysis with a GUI. It also appears that there is a separate binary install, at least on Windows, which would mean anyone using my package would need to install and run something separate. Is that accurate? __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] concurrent requests (Rook, but I think the question is more general)
On Oct 24, 2012, at 4:35 PM, Richard D. Morey wrote: > On 24/10/12 10:07 PM, Simon Urbanek wrote: >> On Oct 24, 2012, at 3:47 PM, Richard D. Morey wrote: >> >>> I'd be fine with the poor man's solution (maybe with tempfile()?) if I can >>> get access to the local file via javascript. But I don't think I can, due >>> to the security limitations of the browser. I may have to rethink this >>> significantly. >>> >> That should be no problem, you can have another R instance serving the >> monitoring page (or you can use Rserve's HTTP server and have just one >> instance with arbitrarily many connections as needed). > > OK, I'm looking at Rserve. I get the impression that one needs to start a > separate server, so it would be difficult to make this transparent to a user > who installs my package and just wants to do an analysis with a GUI. It also > appears that there is a separate binary install, at least on Windows, which > would mean anyone using my package would need to install and run something > separate. Is that accurate? > Not quite - it is all in the Rserve package, many years ago we used to supply Rserve.exe just because it did not require installation of any packages, but we don't do that anymore. Typically Java GUIs use Rserve to run R - it's trivial to start it (e.g., there is the StartRserve.java example) so your GUI can start it and shut it down. I don't know how you are driving your GUI so this may or may not be a good way - on unix you get the benefit of parallel HTTP server, that's really all I was pointing out. BTW: if you are talking web-GUI then Rserve is great for that because the GUI consist simply of R scripts (see FastRWeb) - but I mat be thinking bigger than what you have in mind. The point is that you need a separate monitoring process or threads. That process can be R, Rserve or any thing else. Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Getting ordered factor levels from C
I was banging my head for an hour on this. I just pasted the code into an email
and see that I was getting the contents of the SEXP for the factor, not the one
returned by getAttrib. Sorry for the waste of time.
On Oct 24, 2012, at 4:16 PM, Simon Urbanek wrote:
>
> On Oct 24, 2012, at 2:14 PM, Mark Lilback wrote:
>
>> I'm working on an R package in C and can't seem to get the same level
>> information about a factor that the R console displays.
>>
>> If I define a factor as:
>>
>> lvls <- factor(c('red','blue','blue','green','red'),
>> c('blue','green','red'), ordered=TRUE)
>>
>> When I get the "levels" attribute in C, I get back the the first vector, not
>> the second.
>
> What are you using in C? AFAICS it works just fine:
>
>> f=cfunction(c(foo="factor"), "return getAttrib(foo, R_LevelsSymbol);")
>> f(lvls)
> [1] "blue" "green" "red"
>
--
Mark Lilback
West Virginia University Department of Statistics
mlilb...@stat.wvu.edu
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
