On Tuesday 31 May 2011, Simon Urbanek wrote: > The history entries are somewhat in a grey area, because most GUIs use > their own implementation of history (and thus they are irrelevant) and the > *history() commands are documented to only use readline-backend. That > said, they could be easily used by all GUIs if the Windows code is > amended.
Actually, I would suggest to use a different solution, though: This is not
really a problem that needs to be addressed on a low level of pointers to C
functions. Perhaps it would make more sense to allow to set some R function(s)
to handle these via options() (or perhaps via a dedicated gui.options()).
> > - utils::select.list() and utils::menu(): I want to show my own UI if
> > graphics==TRUE. Currently, select.list() has special code for windows,
> > "aqua" and tcltk; menu() essentially assumes the same code. Give me a
> > way to run register my own UI.
>
> ptr_do_selectlist provides the customization and could be extended to other
> platforms.
See above. But yes, if at least it was cross-platform, that would be nice.
> > - base::system(), base::system2(): As you will be aware, capturing the
> > output of system commands in a GUI is tricky on Unix. I do have a
> > solution for that, but I need to run synchronization code at the start
> > and end of system() and system2(), in order to get interleaving right.
> > Give me a hook, each, at the start and end of these functions.
>
> I'm not sure I understand your concern here. What exactly is your worry?
> Capturing output is trivial since it simply involves creating a pipe when
> you initialize R which you can read while R is running and the
> synchronization is provided by the OS, no magic involved.
Is that pipe buffered? In my setup it is. And so consider code like this:
for (i in 1:10) {
print (i)
system (paste ("echo", i))
}
How do you ensure that this results in
1
1
2
2
...
rather than e.g.
1
2
3
1
2
4
3
5
6
...
I could not get it to work for RKWard without adding code to make sure the
"other" output is flushed. (Note: I'm capturing regular R output via
R_WriteConsoleEx, since I am interested in the differentiation between output
types that this provides. So I cannot simply push that down the same pipe.).
> > - graphics::plot.new(): I need a hook *before* the new plot is started,
> > in order to properly implement device-independent plot history. I would
> > appreciate not having to implement my own graphics device just to be
> > able to run some code at this point.
> >
> > - grDevices::dev.off(): I need a hook before the device is closed. Also
> > for plot history.
> >
> > - grDevices::dev.set(): I need a hook after the new device has been set.
> > Also for plot history.
> >
> > - grid::newpage(): See graphics::plot.new(). Of course, even better, I
> > would like to have a hook that is called every time before a new page /
> > frame is started on a device.
>
> For all of the above: all of them are already available a device callbacks
> (newPage, close, activate and newPage again).
Quoting myself: I would appreciate not having to implement my own graphics
device just to be able to run some code at [these] point[s].
Regards
Thomas
signature.asc
Description: This is a digitally signed message part.
______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
