Re: [Rd] Bug in qr.R ? (PR#9655)
And the purported bug is what: you failed to say! This looks most like a misreading on your part of the documentation. The help page says: complete: logical expression of length 1. Indicates whether an arbitrary orthogonal completion of the *Q* or *X* matrices is to be made, or whether the *R* matrix is to be completed by binding zero-value rows beneath the square upper triangle. You only need to complete R for n < p, as in: > A <- matrix(1:12, 4) > > qr.R(qr(A),complete=TRUE) [,1] [,2] [,3] [1,] -5.477226 -12.780193 -2.008316e+01 [2,] 0.00 -3.265986 -6.531973e+00 [3,] 0.00 0.00 2.641083e-15 [4,] 0.00 0.00 0.00e+00 > qr.R(qr(A),complete=FALSE) [,1] [,2] [,3] [1,] -5.477226 -12.780193 -2.008316e+01 [2,] 0.00 -3.265986 -6.531973e+00 [3,] 0.00 0.00 2.641083e-15 On Fri, 4 May 2007, [EMAIL PROTECTED] wrote: > Ladies and Gentlemen, > > using > > > A <- structure(c(1, 0, 0, 3, 2, 1, 4, 5, -3, -2, 1, 0), .Dim = > as.integer(c(3,4))) > > I get > > > dim(A) > [1] 3 4 > > > qr.R(qr(A),complete=TRUE) > [,1] [,2] [,3] [,4] > [1,] -1 -3.00 -4.00 2.000 > [2,]0 -2.236068 -3.130495 -0.8944272 > [3,]0 0.00 -4.919350 -0.4472136 > > qr.R(qr(A),complete=FALSE) > [,1] [,2] [,3] [,4] > [1,] -1 -3.00 -4.00 2.000 > [2,]0 -2.236068 -3.130495 -0.8944272 > [3,]0 0.00 -4.919350 -0.4472136 > > In ?qr.R I find > > /qr.R returns R. The number of rows of R is nrow(X) or ncol(X), > depending on whether complete is TRUE or FALSE./ > > As you can see, the number of rows stays the same... But it says it is one of the two values, and that which depends on 'complete' (but not that different values of 'complete' necessarily give different answers, just that they might). You may have read this as if it said 'respectively', but it does not. [...] -- 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 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) worked via the R-Unix eventloop, in which case it gets some CPU time from time to time. 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.) 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. > while since I looked at that. I don't believe the unix version of > R_CheckUserInterrupt() does not provide hooks for installing such > checking (we have talked about this off an on but I don't believe > anything happened -- could be wrong there though). > > If Qt allows this one option may be to have events on your nterrupt > widget managed by a small thread that does nothing other than send a > signal to the main thread if the widget is clicked. > > Best, > > luke > > -- 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
[Rd] rbind fails with zero row data.frame and non-data.frame (PR#9657)
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
Re: [Rd] Qt device update
> "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]>
> on Fri, 4 May 2007 22:09:58 +0100 (BST) writes:
BDR> On Fri, 4 May 2007, Simon Urbanek wrote:
>> On May 3, 2007, at 8:52 PM, Deepayan Sarkar wrote:
>>
>>> [...] I have a couple of related questions. First,
>>> dev.interactive (), used in example() and many demo()-s
>>> to decide if the current device is interactive, is
>>> currently implemented as:
>>>
dev.interactive
>>> function (orNone = FALSE) { iDevs <- c("X11", "GTK",
>>> "gnome", "quartz", "windows", "JavaGD") interactive() &&
>>> (.Device %in% iDevs || (orNone && .Device == "null
>>> device" && getOption("device") %in% iDevs)) }
>>>
>>> This makes it impossible for new devices to be treated
>>> as interactive.
>>
>>
>> I think we should finally pass this question to the
>> device itself. For some devices like Cairo the answer
>> depends on the parameters with which the device was
>> created (e.g. type='x11' is interactive whereas
>> type='png' is not), so each instance of the device will
>> answer differently. We could simply add an another
>> capability flag - that is IMHO the only reliable
>> solution. Any other ideas?
BDR> Do we need a reliable solution? The worst that happens
BDR> that if R thinks a device is interactive and it is not,
BDR> you get asked to go on to the next page a few times.
BDR> I've altered R-devel to look at the displaylist. All
BDR> the devices I knew had that enabled by default iff they
BDR> are screen devices, but I've just looked at Cairo and
BDR> it seems that could be a bit less dumb about its
BDR> setting.
BDR> You can't in general ask the device, as there might be
BDR> no device open and you need to know what the device
BDR> that would automatically opened will do. And you don't
BDR> want to open it, as it might not be needed. Allowing
BDR> devices to say by name that they will be interactive is
BDR> the only way anyone has come up with on this so far.
I agree (particularly about the very logical reason above).
But I tend to agree with Deepayan, that
we should give the useR / programmeR a way to just add a name to
that list (well "readably", i.e. with a selfexplainable function
call).
Even for Cairo, the useR can add "cairo" to that
list when she knows that cairo will be called in X11-mode; or
maybe the cairo "initialization/setup" code code do that
automatically when it's loaded..
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Qt device update
On Sat, 5 May 2007, Martin Maechler wrote:
>> "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]>
>> on Fri, 4 May 2007 22:09:58 +0100 (BST) writes:
>
>BDR> On Fri, 4 May 2007, Simon Urbanek wrote:
>>> On May 3, 2007, at 8:52 PM, Deepayan Sarkar wrote:
>>>
>>>> [...] I have a couple of related questions. First,
>>>> dev.interactive (), used in example() and many demo()-s
>>>> to decide if the current device is interactive, is
>>>> currently implemented as:
>>>>
> dev.interactive
>>>> function (orNone = FALSE) { iDevs <- c("X11", "GTK",
>>>> "gnome", "quartz", "windows", "JavaGD") interactive() &&
>>>> (.Device %in% iDevs || (orNone && .Device == "null
>>>> device" && getOption("device") %in% iDevs)) }
>>>>
>>>> This makes it impossible for new devices to be treated
>>>> as interactive.
>>>
>>>
>>> I think we should finally pass this question to the
>>> device itself. For some devices like Cairo the answer
>>> depends on the parameters with which the device was
>>> created (e.g. type='x11' is interactive whereas
>>> type='png' is not), so each instance of the device will
>>> answer differently. We could simply add an another
>>> capability flag - that is IMHO the only reliable
>>> solution. Any other ideas?
>
>BDR> Do we need a reliable solution? The worst that happens
>BDR> that if R thinks a device is interactive and it is not,
>BDR> you get asked to go on to the next page a few times.
>
>BDR> I've altered R-devel to look at the displaylist. All
>BDR> the devices I knew had that enabled by default iff they
>BDR> are screen devices, but I've just looked at Cairo and
>BDR> it seems that could be a bit less dumb about its
>BDR> setting.
>
>BDR> You can't in general ask the device, as there might be
>BDR> no device open and you need to know what the device
>BDR> that would automatically opened will do. And you don't
>BDR> want to open it, as it might not be needed. Allowing
>BDR> devices to say by name that they will be interactive is
>BDR> the only way anyone has come up with on this so far.
>
> I agree (particularly about the very logical reason above).
> But I tend to agree with Deepayan, that
> we should give the useR / programmeR a way to just add a name to
> that list (well "readably", i.e. with a selfexplainable function
> call).
You meam as in
o dev.interactive() regards devices with the displaylist enabled
as interactive, and packages can register the names of their
devices as interactive via deviceIsInteractive().
?
> Even for Cairo, the useR can add "cairo" to that
> list when she knows that cairo will be called in X11-mode; or
> maybe the cairo "initialization/setup" code code do that
> automatically when it's loaded..
>
> Martin
>
--
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] Qt device update
> "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]>
> on Sat, 5 May 2007 15:22:30 +0100 (BST) writes:
BDR> On Sat, 5 May 2007, Martin Maechler wrote:
>>> "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]>
>>> on Fri, 4 May 2007 22:09:58 +0100 (BST) writes:
>>
BDR> On Fri, 4 May 2007, Simon Urbanek wrote:
>> >> On May 3, 2007, at 8:52 PM, Deepayan Sarkar wrote:
>> >>
>> >>> [...] I have a couple of related questions. First,
>> >>> dev.interactive (), used in example() and many
>> demo()-s >>> to decide if the current device is
>> interactive, is >>> currently implemented as:
>> >>>
>> dev.interactive >>> function (orNone = FALSE) {
>> iDevs <- c("X11", "GTK", >>> "gnome", "quartz",
>> "windows", "JavaGD") interactive() && >>> (.Device %in%
>> iDevs || (orNone && .Device == "null >>> device" &&
>> getOption("device") %in% iDevs)) }
>> >>>
>> >>> This makes it impossible for new devices to be
>> treated >>> as interactive.
>> >>
>> >>
>> >> I think we should finally pass this question to the >>
>> device itself. For some devices like Cairo the answer >>
>> depends on the parameters with which the device was >>
>> created (e.g. type='x11' is interactive whereas >>
>> type='png' is not), so each instance of the device will
>> >> answer differently. We could simply add an another >>
>> capability flag - that is IMHO the only reliable >>
>> solution. Any other ideas?
>>
BDR> Do we need a reliable solution? The worst that happens
BDR> that if R thinks a device is interactive and it is not,
BDR> you get asked to go on to the next page a few times.
>>
BDR> I've altered R-devel to look at the displaylist. All
BDR> the devices I knew had that enabled by default iff they
BDR> are screen devices, but I've just looked at Cairo and
BDR> it seems that could be a bit less dumb about its
BDR> setting.
>>
BDR> You can't in general ask the device, as there might be
BDR> no device open and you need to know what the device
BDR> that would automatically opened will do. And you don't
BDR> want to open it, as it might not be needed. Allowing
BDR> devices to say by name that they will be interactive is
BDR> the only way anyone has come up with on this so far.
>> I agree (particularly about the very logical reason
>> above). But I tend to agree with Deepayan, that we
>> should give the useR / programmeR a way to just add a
>> name to that list (well "readably", i.e. with a
>> selfexplainable function call).
BDR> You meam as in
BDR> o dev.interactive() regards devices with the
BDR> displaylist enabled as interactive, and packages can
BDR> register the names of their devices as interactive via
BDR> deviceIsInteractive().
BDR> ?
Yes, indeed... you are moving faster than I do thinking ;-)
Martin
>> Even for Cairo, the useR can add "cairo" to that list
>> when she knows that cairo will be called in X11-mode; or
>> maybe the cairo "initialization/setup" code code do that
>> automatically when it's loaded..
>>
>> Martin
>>
BDR> -- Brian D. Ripley, [EMAIL PROTECTED] Professor of
BDR> Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
BDR> University of Oxford, Tel: +44 1865 272861 (self) 1
BDR> South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG,
BDR> UK Fax: +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 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) 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). > > 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. The UI provided by a shell running in a separate process may not have a 'G' but it does have its advantages :-) Best, luke >> while since I looked at that. I don't believe the unix version of >> R_CheckUserInterrupt() does not provide hooks for installing such >> checking (we have talked about this off an on but I don't believe >> anything happened -- could be wrong there though). >> >> If Qt allows this one option may be to have events on your nterrupt >> widget managed by a small thread that does nothing other than send a >> signal to the main thread if the widget is clicked. >> >> Best, >> >> luke >> >> > > -- Luke Tierney Chair, Statistics and Actuarial Science Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics andFax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: [EMAIL PROTECTED] Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] sending signals to embedded R
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) 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. So my assumption 'worked via the R-Unix eventloop' was that a handler (probably a polling handler) had been wedged in the eventloop. That was in contrast to running under a separate thread. > The UI provided by a shell running in a separate process may not have > a 'G' but it does have its advantages :-) Or a separate thread, as Rterm.exe does. Really RGui should also run in a separate thread, but when Guido did so, it did not work under Windows 95: if we ever give up support for pre-NT Windows I will take a look again at this. I guess my underlying point is that rather than run the GUI from R_ProcessEvents (as RGui is), on Unix you can run it from an eventloop handler. Brian > > Best, > > luke > >>> while since I looked at that. I don't believe the unix version of >>> R_CheckUserInterrupt() does not provide hooks for installing such >>> checking (we have talked about this off an on but I don't believe >>> anything happened -- could be wrong there though). >>> >>> If Qt allows this one option may be to have events on your nterrupt >>> widget managed by a small thread that does nothing other than send a >>> signal to the main thread if the widget is clicked. >>> >>> Best, >>> >>> luke >>> >>> >> >> > > -- Brian D
Re: [Rd] sending signals to embedded R
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) 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 systems need to do enough event
processing to determine whether there is a user interrupt event
pending. Need to be careful not to do too much event
processing though: if event handlers written in R are allowed
to run at this point then we end up with concurrent R
evaluations and that can cause problems until we have proper
concurrency support. LT */
#if ( defined(HAVE_AQUA) || defined(Win32) )
R_ProcessEvents();
#else
if (R_interrupts_pending)
onintr();
#endif /* Win32 */
}
So only
[Rd] Building R on Solaris
This comes up on R-help from time to time, so I am putting this message in the archives that may be helpful to refer back to. We have just got a brand-new Sun Solaris 10 box: this is a Sparc server to be the first of a clustered pair (our file/mail server), and we will also be buying an Opteron server. The good news is that things worked very smoothly with Solaris 10. The bad news is that libsunperf is just as broken as in 2002 and the consequences are worse. So just avoid it! We don't know what Solaris 10 boxes normally ship with, but our supplier (an academic specialist reseller) had loaded ours with Sun Studio 11 compilers (which are now a free download). A set of Open Source tools from www.sunfreeware.com in /usr/sfw. A large set of Open Source tools in /opt/csw. The latter was new to me, and uses a repository at www.blastwave.org and a nifty tool called 'pkg-get'. My sysadmin (who has an HP-UX and Debian bias) thought this was the best he had seen, ahead of apt-get and yum, for example. This box already had everything I needed to build R, including gcc3, gcc4, libreadline and libiconv. pkg-get is at http://www.bolthole.com/solaris/pkg-get.html if it was not already installed. As far as I can tell, OpenSolaris aka Solaris Express Community Edition aka 'Solaris 11' can be built to have the same set of tools. (We will probably do so on an older box in due course.) I've written up what we needed to do in the 'R Installation and Administration Manual' for R-patched and R-devel. Some trickery with paths was needed for some of the builds (but not to run: these tools are set up using ld -R to get the correct run-time library paths and run a mixed 64-and 32-bit OS with three different compiler sets very smoothly). -- 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] Building R on Solaris
> Sun Studio 11 compilers (which are now a free download). > A set of Open Source tools from www.sunfreeware.com in /usr/sfw. > A large set of Open Source tools in /opt/csw. > > The latter was new to me, and uses a repository at www.blastwave.org and > a nifty tool called 'pkg-get'. My sysadmin (who has an HP-UX and Debian > bias) thought this was the best he had seen, ahead of apt-get and yum, > for example. This box already had everything I needed to build R, > including Your sysadmin will change his mind the first time that blastwave packages totally f*ck one of his machines. They're usually a bit stale. Building your own kit is much more reliable... --elijah __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
