Re: [Rd] (PR#9657) rbind fails with zero row data.frame and non-data.frame
Thank you, fixed in 2.5.0 patched: > A <- data.frame(foo=character(0), bar=character(0)) > rbind(A, c(foo="a", bar="b")) X.a. X.b. 1ab Note though that rbind-ing a character vector to a data frame does not in general work well: > A <- data.frame(foo=character(2), bar=character(2)) > rbind(A, c(foo="a", bar="b")) foo bar 1 2 3 Warning messages: 1: invalid factor level, NAs generated in: `[<-.factor`(`*tmp*`, ri, value = "a") 2: invalid factor level, NAs generated in: `[<-.factor`(`*tmp*`, ri, value = "b") and I am not sure that one should expect it to do so. On Sat, 5 May 2007, [EMAIL PROTECTED] wrote: > Full_Name: Michael Lawrence > Version: 2.5.0 > OS: Linux > Submission from: (NULL) (69.5.145.41) > > > With R 2.5.0, when trying to rbind a zero row data.frame to a > non-data.frame (eg character vector), the following error is output: > Error in all.levs[[j]] : subscript out of bounds > > Here is the code to reproduce the error: > rbind(data.frame(foo=character(0), bar=character(0)), c(foo="foo", bar="bar")) > > It seems that the code assumes that it has at least one data.frame but > the data.frame was filtered out at the beginning, because it had zero > rows. > > --please do not edit the information below-- > Version: > platform = i686-pc-linux-gnu > arch = i686 > os = linux-gnu > system = i686, linux-gnu > status = > major = 2 > minor = 5.0 > year = 2007 > month = 04 > day = 23 > svn rev = 41293 > language = R > version.string = R version 2.5.0 (2007-04-23) > > Locale: > C > > Search Path: > .GlobalEnv, package:stats, package:graphics, package:grDevices, package:utils, > package:datasets, package:methods, Autoloads, package:base > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, [EMAIL PROTECTED] 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] sending signals to embedded R
On 5/5/07, Luke Tierney <[EMAIL PROTECTED]> wrote:
> On Sat, 5 May 2007, Prof Brian Ripley wrote:
>
> > On Sat, 5 May 2007, Luke Tierney wrote:
> >
> >> On Sat, 5 May 2007, Prof Brian Ripley wrote:
> >>
> >>> On Fri, 4 May 2007, Luke Tierney wrote:
> >>>
> On Fri, 4 May 2007, Deepayan Sarkar wrote:
>
> > On 5/4/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
> >> On Fri, 4 May 2007, Deepayan Sarkar wrote:
> >>
> >>> one thing I haven't been able to figure out from R-exts is how to
> >>> interrupt a calculation running inside an embedded R. C code inside
> R
> >>> calls R_CheckUserInterrupt() intermittently to check for interrupts,
> >>> but how does my GUI tell R that the user wants it interrupted?
> >>
> >> Well, the intention is that you send an interrupt, which hardly needs
> >> to
> >> be in the manual.
> >
> > I didn't mean to imply that it does. I'm just new to signals and
> > things that should be obvious aren't.
> >
> > Basically kill(2) seems to be the right thing to use, but I wasn't
> > sure what the PID needs to be. Turns out sending SIGINT to my GUI from
> > a shell interrupts R, so raise(SIGINT) should be enough.
>
> The tricky bit here is figuring out who does the sending. It you have
> a separate thread/process for the GUI and R then that is fine (though
> may raise other issues). If it is a single thread then you need your
> event processing to get an occasional look in to recognise the user
> action that triggers an interrupt. The Windows version handles this by
> having R_CheckUserInterrupt() do a limited amount of event processing
> (you need to be careful in GUI events have R actions associated with
> them). I believe the Mac version is similar though it has been a
> >>>
> >>> I was assuming that Deepayan's GUI (which seems to need Qt4, BTW, so I
> was
> >>> unable to compile it)
Why is that a problem? As far as I can tell, Qt4 can peacefully
coexist with Qt3, and while compiling you just need to use the right
qmake (this is currently hardcoded in the configure script
unfortunately).
Qt4 has been around for a while now, and it's GPL on Windows/Mac as
well as X11, so it seemed like the natural choice.
> >>> worked via the R-Unix eventloop, in which case it
> >>> gets some CPU time from time to time.
> >>
> >> I was assuming that as well. But my recollection is that on unix the
> >> event loop is only run from within the console reader. On Windows
> >> (and Mac OS X I believe) some event processing also happens in
> >> R_CheckUserInterrupt(); on Windows there is also some more in some
> >> blocking library calls, like socket reads as I recall. But unless
> >> things have changed since I last looked none of that happens on unix.
> >>
> >>>
> >>> gnomeGUI has an interrupt menu item with action 'onintr', which may well
> >>> be what Deepayan is looking for: the only reason that package still
> exists
> >>> is to provide example code. (Not that it was ever properly integrated
> >>> with the R event loop.)
> >>
> >> It does have some sort of interrupt device (I can't recall if it is a
> >> menu item or a butto and I can't seem to build a working gnomeGUI to
> >> check). And I believe if you try to use that item (or button?) during
> >> a long-running computation you can't because the events won't be
> >> looked at until R gets back to a console read, at which point the
> >> events will be processed and you jump to the top level (where you
> >> already are).
> >
> > That belief is correct (it has a menu item and a button), but my final
> > parenthetical remark was that gnomeGUI was not wedged into the event loop.
> >
> >>> If the issue is what happens when the user Ctrl-C's in the GUI console,
> >>> that depends on what the GUI toolkit does with keyboard input: if it
> >>> generates a SIGINT this should just work, but otherwise the keyboard
> >>> handler needs to be told to call onintr() one way or another.
> >>
> >> Again only if the GUI gets a chance to look at the keyboard input,
> >> which I don't think we currently give it.
> >
> > We builtin the ability for a front-end to register handlers with the R
> event
> > loop, including a polling handler (and that is how we can have a Tcl/Tk
> front
> > end). That postdates gnomeGUI, which runs the Gtk event-loop, not R's.
> >
>
> I had forgotten about that -- thanks for the reminder.
>
> However, R_PolledEvents is only called from a limited set of places
> now (including the socket reading code to keep things responsive
> during blocking reads). But it is not called from the interupt
> checking code, which means if a user does something equivalent to
>
> while (TRUE) {}
>
> there is not point where events get looked at to see a user interrupt
> action. The current definition of R_CheckUserInterrupt is
>
> void R_CheckUserInterrupt(void)
> {
> R_CheckStack();
> /* This is the point where GUI sys
Re: [Rd] sending signals to embedded R
On Sun, 6 May 2007 [EMAIL PROTECTED] wrote:
> On 5/5/07, Luke Tierney <[EMAIL PROTECTED]> wrote:
>> On Sat, 5 May 2007, Prof Brian Ripley wrote:
>>
>> > On Sat, 5 May 2007, Luke Tierney wrote:
>> >
>> >> On Sat, 5 May 2007, Prof Brian Ripley wrote:
>> >>
>> >>> On Fri, 4 May 2007, Luke Tierney wrote:
>> >>>
>> On Fri, 4 May 2007, Deepayan Sarkar wrote:
>>
>> > On 5/4/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
>> >> On Fri, 4 May 2007, Deepayan Sarkar wrote:
>> >>
>> >>> one thing I haven't been able to figure out from R-exts is how to
>> >>> interrupt a calculation running inside an embedded R. C code inside
>> R
>> >>> calls R_CheckUserInterrupt() intermittently to check for
>> interrupts,
>> >>> but how does my GUI tell R that the user wants it interrupted?
>> >>
>> >> Well, the intention is that you send an interrupt, which hardly
>> needs
>> >> to
>> >> be in the manual.
>> >
>> > I didn't mean to imply that it does. I'm just new to signals and
>> > things that should be obvious aren't.
>> >
>> > Basically kill(2) seems to be the right thing to use, but I wasn't
>> > sure what the PID needs to be. Turns out sending SIGINT to my GUI
>> from
>> > a shell interrupts R, so raise(SIGINT) should be enough.
>>
>> The tricky bit here is figuring out who does the sending. It you have
>> a separate thread/process for the GUI and R then that is fine (though
>> may raise other issues). If it is a single thread then you need your
>> event processing to get an occasional look in to recognise the user
>> action that triggers an interrupt. The Windows version handles this by
>> having R_CheckUserInterrupt() do a limited amount of event processing
>> (you need to be careful in GUI events have R actions associated with
>> them). I believe the Mac version is similar though it has been a
>> >>>
>> >>> I was assuming that Deepayan's GUI (which seems to need Qt4, BTW, so I
>> was
>> >>> unable to compile it)
>
> Why is that a problem? As far as I can tell, Qt4 can peacefully
> coexist with Qt3, and while compiling you just need to use the right
> qmake (this is currently hardcoded in the configure script
> unfortunately).
>
> Qt4 has been around for a while now, and it's GPL on Windows/Mac as
> well as X11, so it seemed like the natural choice.
>
>> >>> worked via the R-Unix eventloop, in which case it
>> >>> gets some CPU time from time to time.
>> >>
>> >> I was assuming that as well. But my recollection is that on unix the
>> >> event loop is only run from within the console reader. On Windows
>> >> (and Mac OS X I believe) some event processing also happens in
>> >> R_CheckUserInterrupt(); on Windows there is also some more in some
>> >> blocking library calls, like socket reads as I recall. But unless
>> >> things have changed since I last looked none of that happens on unix.
>> >>
>> >>>
>> >>> gnomeGUI has an interrupt menu item with action 'onintr', which may
>> well
>> >>> be what Deepayan is looking for: the only reason that package still
>> exists
>> >>> is to provide example code. (Not that it was ever properly integrated
>> >>> with the R event loop.)
>> >>
>> >> It does have some sort of interrupt device (I can't recall if it is a
>> >> menu item or a butto and I can't seem to build a working gnomeGUI to
>> >> check). And I believe if you try to use that item (or button?) during
>> >> a long-running computation you can't because the events won't be
>> >> looked at until R gets back to a console read, at which point the
>> >> events will be processed and you jump to the top level (where you
>> >> already are).
>> >
>> > That belief is correct (it has a menu item and a button), but my final
>> > parenthetical remark was that gnomeGUI was not wedged into the event
>> loop.
>> >
>> >>> If the issue is what happens when the user Ctrl-C's in the GUI console,
>> >>> that depends on what the GUI toolkit does with keyboard input: if it
>> >>> generates a SIGINT this should just work, but otherwise the keyboard
>> >>> handler needs to be told to call onintr() one way or another.
>> >>
>> >> Again only if the GUI gets a chance to look at the keyboard input,
>> >> which I don't think we currently give it.
>> >
>> > We builtin the ability for a front-end to register handlers with the R
>> event
>> > loop, including a polling handler (and that is how we can have a Tcl/Tk
>> front
>> > end). That postdates gnomeGUI, which runs the Gtk event-loop, not R's.
>> >
>>
>> I had forgotten about that -- thanks for the reminder.
>>
>> However, R_PolledEvents is only called from a limited set of places
>> now (including the socket reading code to keep things responsive
>> during blocking reads). But it is not called from the interupt
>> checking code, which means if a user does something equivalent to
>>
>> while (TRUE) {}
>>
>> there is not point where events get looked at to see
Re: [Rd] sending signals to embedded R
Luke Tierney wrote:
> On Sun, 6 May 2007 [EMAIL PROTECTED] wrote:
>
>> On 5/5/07, Luke Tierney <[EMAIL PROTECTED]> wrote:
>>> On Sat, 5 May 2007, Prof Brian Ripley wrote:
>>>
On Sat, 5 May 2007, Luke Tierney wrote:
> On Sat, 5 May 2007, Prof Brian Ripley wrote:
>
>> On Fri, 4 May 2007, Luke Tierney wrote:
>>
>>> On Fri, 4 May 2007, Deepayan Sarkar wrote:
>>>
On 5/4/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
> On Fri, 4 May 2007, Deepayan Sarkar wrote:
>
>> one thing I haven't been able to figure out from R-exts is how to
>> interrupt a calculation running inside an embedded R. C code inside
>>> R
>> calls R_CheckUserInterrupt() intermittently to check for
>>> interrupts,
>> but how does my GUI tell R that the user wants it interrupted?
> Well, the intention is that you send an interrupt, which hardly
>>> needs
> to
> be in the manual.
I didn't mean to imply that it does. I'm just new to signals and
things that should be obvious aren't.
Basically kill(2) seems to be the right thing to use, but I wasn't
sure what the PID needs to be. Turns out sending SIGINT to my GUI
>>> from
a shell interrupts R, so raise(SIGINT) should be enough.
>>> The tricky bit here is figuring out who does the sending. It you have
>>> a separate thread/process for the GUI and R then that is fine (though
>>> may raise other issues). If it is a single thread then you need your
>>> event processing to get an occasional look in to recognise the user
>>> action that triggers an interrupt. The Windows version handles this by
>>> having R_CheckUserInterrupt() do a limited amount of event processing
>>> (you need to be careful in GUI events have R actions associated with
>>> them). I believe the Mac version is similar though it has been a
>> I was assuming that Deepayan's GUI (which seems to need Qt4, BTW, so I
>>> was
>> unable to compile it)
>> Why is that a problem? As far as I can tell, Qt4 can peacefully
>> coexist with Qt3, and while compiling you just need to use the right
>> qmake (this is currently hardcoded in the configure script
>> unfortunately).
>>
>> Qt4 has been around for a while now, and it's GPL on Windows/Mac as
>> well as X11, so it seemed like the natural choice.
>>
>> worked via the R-Unix eventloop, in which case it
>> gets some CPU time from time to time.
> I was assuming that as well. But my recollection is that on unix the
> event loop is only run from within the console reader. On Windows
> (and Mac OS X I believe) some event processing also happens in
> R_CheckUserInterrupt(); on Windows there is also some more in some
> blocking library calls, like socket reads as I recall. But unless
> things have changed since I last looked none of that happens on unix.
>
>> gnomeGUI has an interrupt menu item with action 'onintr', which may
>>> well
>> be what Deepayan is looking for: the only reason that package still
>>> exists
>> is to provide example code. (Not that it was ever properly integrated
>> with the R event loop.)
> It does have some sort of interrupt device (I can't recall if it is a
> menu item or a butto and I can't seem to build a working gnomeGUI to
> check). And I believe if you try to use that item (or button?) during
> a long-running computation you can't because the events won't be
> looked at until R gets back to a console read, at which point the
> events will be processed and you jump to the top level (where you
> already are).
That belief is correct (it has a menu item and a button), but my final
parenthetical remark was that gnomeGUI was not wedged into the event
>>> loop.
>> If the issue is what happens when the user Ctrl-C's in the GUI console,
>> that depends on what the GUI toolkit does with keyboard input: if it
>> generates a SIGINT this should just work, but otherwise the keyboard
>> handler needs to be told to call onintr() one way or another.
> Again only if the GUI gets a chance to look at the keyboard input,
> which I don't think we currently give it.
We builtin the ability for a front-end to register handlers with the R
>>> event
loop, including a polling handler (and that is how we can have a Tcl/Tk
>>> front
end). That postdates gnomeGUI, which runs the Gtk event-loop, not R's.
>>> I had forgotten about that -- thanks for the reminder.
>>>
>>> However, R_PolledEvents is only called from a limited set of places
>>> now (including the socket reading code to keep things responsive
>>> during blocking reads). But it is not called from the interupt
>>> checking code, which means if a user does something equivalent to
>>>
>>> while (TRUE) {}
>>>
>>> there is not point where events get looked at to see a user interrupt
>>> action.
Re: [Rd] sending signals to embedded R
On 5/6/07, Jeffrey Horner <[EMAIL PROTECTED]> wrote:
> Luke Tierney wrote:
[...]
> >> Is there a reason R_ProcessEvents cannot be set on Unix but can on
> >> Mac? It doesn't seem user-settable on Windows, but whatever the built
> >> in default is seems to handle the Qt event loop. And for that matter,
> >> why is it possible to set the file.edit callback on Mac but not Linux?
> >> This seems arbitrary, and no explanation is given (that I could find).
> >
> > The R_PRocessEvents callback may be settable on MacOS but I'm not sure
> > it's used -- at least a quick grep didn't reveal its use anywhere
> > outside the gnuwin32 code.
I meant the callback ptr_R_ProcessEvents (in Rinterface.h). The Mac
GUI source has (this is probably not the latest version):
[EMAIL PROTECTED]:~/Mac-GUI-1.17$ grep -i ptr_r_process */*
REngine/Rinit.c:extern void (*ptr_R_ProcessEvents)();
REngine/Rinit.c:ptr_R_ProcessEvents = Re_ProcessEvents;
and R/trunk/src/unix/aqua.c has:
void R_ProcessEvents(void)
{
if(!useaqua){
if (R_interrupts_pending)
onintr();
return;
} else
ptr_R_ProcessEvents();
}
> > It would be good to unify the Mac and *nix mechanisms here since the
> > OS underpinings are now so similar, but it will have to get high
> > enough on someone's priority list to happen.
[...]
> >> The problem I'm having with this solution is that whenever I interrupt
> >> a graphics command, R crashes. This is true for commands being
> >> evaluated by R_tryEval, but not those run from the REPL (for example,
> >> if I make the call inside a debug() environment, interrupting it
> >> causes no problems). As far as I can tell, this is only a problem with
> >> graphics; other commands can be interrupted even when run using
> >> R_tryEval().
> >
> > That sounds like a longjmp being done to a place that doesn't exist --
> > maybe a threading issue in Qt. See what gdb tells you about where the
> > crash is occurring. It might be different for onintr and kill. You
> > might also try just setting the R_interrupts_pending flag from the
> > interrupt event handler rather than calling onintr (which probably
> > longjmp's) or kill (which may be doing something you don't want if
> > other threads with other signal handlers are involved).
I will have to start learning about gdb sometime soon, but in this case, the
problem seems to be due to the interaction of R_tryEval() and
graphics, and has nothing to do with interruptions. Here's a variant
of the trEval test case that triggers a legitimate error caused by
grid.text('foo', gp = gpar(font=1, fontface=1))
[EMAIL PROTECTED]:~$ cat tryEvalGraphics.c ## beware of line wrapping
/*
Compile this as:
RPROG=R-devel
export LD_LIBRARY_PATH=`${RPROG} RHOME`/lib:\${LD_LIBRARY_PATH}
gcc `${RPROG} CMD config --cppflags` \
`${RPROG} CMD config --ldflags` \
-o tryEvalGraphics tryEvalGraphics.c
*/
#include
#include
#include
int
main(int argc, char *argv[])
{
SEXP e, val;
int i, errorOccurred;
ParseStatus status;
char *cmds[] = {
"library(lattice)",
"library(grid)",
"grid.text('foo', gp = gpar(font=1, fontface=1))",
"xyplot(1 ~ 1, panel = function() grid.text('foo', gp =
gpar(font=1, fontface=1)))"
};
argv[0] = "R";
Rf_initEmbeddedR(argc, argv);
for (i = 0; i < 4; i++) {
printf("** I **: Executing command: %s\n", cmds[i]);
fflush(stdout); sleep(1);
PROTECT(e = R_ParseVector(mkString(cmds[i]), -1, &status, R_NilValue));
val = R_tryEval(VECTOR_ELT(e, 0), NULL, &errorOccurred);
if (errorOccurred) { Rprintf("Error executing: %s\n", cmds[i]); }
else Rf_PrintValue(val);
UNPROTECT(1);
printf("** I **: Succeeded\n");
fflush(stdout); sleep(1);
}
Rf_endEmbeddedR(0);
return(0);
}
Running this, I get:
[EMAIL PROTECTED]:~$ R-devel CMD ./tryEvalGraphics
R version 2.6.0 Under development (unstable) (2007-05-04 r41439)
[...]
[Previously saved workspace restored]
** I **: Executing command: library(lattice)
[1] "stats" "graphics" "grDevices" "utils" "datasets" "lattice"
[7] "rcompgen" "methods" "base"
** I **: Succeeded
** I **: Executing command: library(grid)
[1] "grid" "stats" "graphics" "grDevices" "utils" "datasets"
[7] "lattice" "rcompgen" "methods" "base"
** I **: Succeeded
** I **: Executing command: grid.text('foo', gp = gpar(font=1, fontface=1))
Error in validGP(list(...)) : Must specify only one of 'font' and 'fontface'
Error executing: grid.text('foo', gp = gpar(font=1, fontface=1))
** I **: Succeeded
** I **: Executing command: xyplot(1 ~ 1, panel = function()
grid.text('foo', gp = gpar(font=1, fontface=1)))
Error in validGP(list(...)) : Must specify only one of 'font' and 'fontface'
*** caught segfault ***
address 0x22000440, cause 'memory not mapped'
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without sav
