Hi Frederik,>>>>> <frederik at ofb.net> >>>>> on Tue, 7 Jun 2016 15:20:05 -0700 writes:> ... I just realized that setGraphicsEventHandlers or > getGraphicsEvent could have an 'onIdle' callback, to be > called somewhere in the polling loop of gevents.c:163 - I > think this would solve my problem #2 in a minimally > disruptive way. I hope you will get some feedback about this by one of the graphics/devices experts from within R core. I'm not among them at all, but they may be busy or travelling currently. Also, as you are studying the C code and the issues anyway, it may be worthwhile to consider (as small as possible!) patches to the source you could also post to the bugzilla site if you prefer; attaching as text/plain to R-devel does work fine, too. Best regards, Martin > On Mon, Jun 06, 2016 at 06:38:45PM -0700, frederik at ofb.net > wrote: >> Hi R-Devel, >> >> I've been working on an oscilloscope project using an >> Arduino microcontroller board. I found that it's quite >> easy to get realtime updates, e.g. 30+ frames per second, >> if I read data from the board in a little Rcpp library. I >> have to use dev.hold() and dev.flush() to keep the plot >> from flickering, which restricts me to the "cairo" X11 >> device. >> >> I'd like to be able to add interactivity to the >> oscilloscope display, for instance to bind a key to save >> the current plot to a file, or to bind keys for adjusting >> the time scale etc. >> >> However, I ran into two problems: >> >> (1) setGraphicsEventHandlers only works on the "Xlib" X11 >> device, which doesn't support buffering via dev.hold() - >> it flickers. >> >> (2) getGraphicsEvent and friends lack some interface >> features which are needed to use the functions in an >> asynchronous fashion. Typically, event listener library >> functions have a "timeout" parameter, and the ability to >> return already-queued events. But getGraphicsEvent() has >> neither - it waits indefinitely (you can't set a >> timeout), and it seems to ignore events which occurred >> before it was called (I can't figure out why, from the >> code, I guess the normal R event processing grabs events >> which occur between calls to getGraphicsEvent?). >> >> It seems like it should be possible to set a handler for >> keyboard events and have it execute in between plot >> updates when the user presses a key - yet without >> blocking further updates if no key has been pressed. >> >> Is anyone interested in fixing (1) and (2)? Or is there >> some other library or workaround to solve my problems? >> >> Here is some code I used to play around with these >> functions: >> >> X11(type="Xlib"); >> >> keydown = function(key) { cat("Got key: ",key); lastkey <<- key } >> >> setGraphicsEventHandlers(onKeybd = keydown); >> >> plot(c(0,0)); getGraphicsEvent(); >> >> Well, I think it's great that getGraphicsEvent exists at >> all, and want to salute Duncan Murdoch who is listed as >> the author. I hope I may have helped by describing some >> new possible uses for these functions. >> >> Thank you, >> >> Frederick >> >> ______________________________________________ >> R-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel
frederik at ofb.net
2016-Jun-12 03:49 UTC
[Rd] getGraphicsEvent on X11 and event queuing; Makefile.in
Hi Martin,
Thanks for getting back about getGraphicsEvent.
I got an off-list reply from someone who echoed the annoyance with
lack of Cairo support, and also provided some interesting examples of
his own use of getGraphicsEvent. Thank you for the invitation to
contribute patches; I don't know what my upcoming priorities will be
like but it's good to know that you would consider using my code.
Speaking of which, I just did an 'svn update' and noticed that
Makefile.in has the same line that I asked about earlier:
@if test ! -f "$(srcdir)/doc/FAQ" || test -f non-tarball ;
then \
But, my earlier suggestion to change this to $(srcdir)/non-tarball was
wrong because it doesn't seem to fix anything. In fact the
"non-tarball" exists in the build directory so it was OK to test for
it there. Sorry about that!
Apparently building in a separate directory, when a build has already
been started in the source directory, is still broken. I just checked
this with a clean "svn checkout". Even if I start a successful build
in a separate build directory, cancel it with SIGINT, start a build in
the source directory, cancel that, and then try to continue the
build-directory build, I get an error:
make[1]: Entering directory
'/home/frederik/pkg-tmp/R-svn-build/doc/manual'
make[1]: Nothing to be done for 'front-matter'.
make[1]: Nothing to be done for 'html-non-svn'.
make[1]: Leaving directory
'/home/frederik/pkg-tmp/R-svn-build/doc/manual'
SVN-REVISION is unchanged
make[1]: Entering directory '/home/frederik/pkg-tmp/R-svn-build/m4'
make[1]: Nothing to be done for 'R'.
make[1]: Leaving directory '/home/frederik/pkg-tmp/R-svn-build/m4'
make[1]: Entering directory
'/home/frederik/pkg-tmp/R-svn-build/tools'
make[1]: Nothing to be done for 'R'.
make[1]: Leaving directory
'/home/frederik/pkg-tmp/R-svn-build/tools'
make[1]: Entering directory '/home/frederik/pkg-tmp/R-svn-build/doc'
/usr/bin/install: cannot stat '../../R-svn/doc/NEWS': No such file
or directory
/usr/bin/install: cannot stat '../../R-svn/doc/NEWS.pdf': No such
file or directory
Makefile:164: recipe for target 'svnonly' failed
make[1]: *** [svnonly] Error 1
make[1]: Leaving directory '/home/frederik/pkg-tmp/R-svn-build/doc'
Makefile:60: recipe for target 'R' failed
make: *** [R] Error 1
I'm somewhat stumped... I had thought that removing doc/FAQ would fix
it, but it doesn't. I don't know what else could have been done by
'make' in the source directory which is confusing the build-directory
build.
Thanks,
Frederick
On Thu, Jun 09, 2016 at 04:52:26PM +0200, Martin Maechler
wrote:> Hi Frederik,
>
> >>>>> <frederik at ofb.net>
> >>>>> on Tue, 7 Jun 2016 15:20:05 -0700 writes:
>
> > ... I just realized that setGraphicsEventHandlers or
> > getGraphicsEvent could have an 'onIdle' callback, to be
> > called somewhere in the polling loop of gevents.c:163 - I
> > think this would solve my problem #2 in a minimally
> > disruptive way.
>
> I hope you will get some feedback about this by one of the
> graphics/devices experts from within R core.
> I'm not among them at all, but they may be busy or travelling
> currently.
>
> Also, as you are studying the C code and the issues anyway, it
> may be worthwhile to consider (as small as possible!) patches to
> the source you could also post to the bugzilla site if you
> prefer; attaching as text/plain to R-devel does work fine, too.
>
> Best regards,
> Martin
>
> > On Mon, Jun 06, 2016 at 06:38:45PM -0700, frederik at ofb.net
> > wrote:
> >> Hi R-Devel,
> >>
> >> I've been working on an oscilloscope project using an
> >> Arduino microcontroller board. I found that it's quite
> >> easy to get realtime updates, e.g. 30+ frames per second,
> >> if I read data from the board in a little Rcpp library. I
> >> have to use dev.hold() and dev.flush() to keep the plot
> >> from flickering, which restricts me to the "cairo"
X11
> >> device.
> >>
> >> I'd like to be able to add interactivity to the
> >> oscilloscope display, for instance to bind a key to save
> >> the current plot to a file, or to bind keys for adjusting
> >> the time scale etc.
> >>
> >> However, I ran into two problems:
> >>
> >> (1) setGraphicsEventHandlers only works on the
"Xlib" X11
> >> device, which doesn't support buffering via dev.hold() -
> >> it flickers.
> >>
> >> (2) getGraphicsEvent and friends lack some interface
> >> features which are needed to use the functions in an
> >> asynchronous fashion. Typically, event listener library
> >> functions have a "timeout" parameter, and the
ability to
> >> return already-queued events. But getGraphicsEvent() has
> >> neither - it waits indefinitely (you can't set a
> >> timeout), and it seems to ignore events which occurred
> >> before it was called (I can't figure out why, from the
> >> code, I guess the normal R event processing grabs events
> >> which occur between calls to getGraphicsEvent?).
> >>
> >> It seems like it should be possible to set a handler for
> >> keyboard events and have it execute in between plot
> >> updates when the user presses a key - yet without
> >> blocking further updates if no key has been pressed.
> >>
> >> Is anyone interested in fixing (1) and (2)? Or is there
> >> some other library or workaround to solve my problems?
> >>
> >> Here is some code I used to play around with these
> >> functions:
> >>
> >> X11(type="Xlib");
> >>
> >> keydown = function(key) { cat("Got key: ",key);
lastkey <<- key }
> >>
> >> setGraphicsEventHandlers(onKeybd = keydown);
> >>
> >> plot(c(0,0)); getGraphicsEvent();
> >>
> >> Well, I think it's great that getGraphicsEvent exists at
> >> all, and want to salute Duncan Murdoch who is listed as
> >> the author. I hope I may have helped by describing some
> >> new possible uses for these functions.
> >>
> >> Thank you,
> >>
> >> Frederick
> >>
> >> ______________________________________________
> >> R-devel at r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>
>
> > ______________________________________________
> > R-devel at r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
Hi Martin,> Also, as you are studying the C code and the issues anyway, it > may be worthwhile to consider (as small as possible!) patches to > the source you could also post to the bugzilla site if you > prefer; attaching as text/plain to R-devel does work fine, too.Well, after your kind solicitation I went through all the touble of locally fixing getGraphicsEvent Cairo support and implementing an onIdle handler. However, I noticed that the first part actually already has a patch on the R bug tracker, which is exactly the same as the fix I implemented! (minus documentation) https://bugs.r-project.org/bugzilla/show_bug.cgi?id=14364 Problem: somebody ignored the patch and closed the bug. Who closed it? YOU! So, I guess since that patch (fixing Cairo support) was sent in 2010, and my patch (fixing both problems) is about 8 times longer, I can expect you to ignore my patch until at least 2063 (a tight lower bound if you apply Hugo's patch this year). :) I posted my patch here: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16951 Frederick
Hi R-Devel and Duncan,
Any ideas about my patch? I'm including Duncan Murdoch since he was
actually the one who made the "fix" to Hugo's bug in September
2010.
Duncan chose to "fix" Cairo support by formally disabling it, rather
than by enabling it as Hugo had proposed. I don't see a reply to
Hugo's January 2011 question, asking why this was done. Hugo's patch
was pretty simple:
if(!using cairo) {
xlib stuff
- set up for getGraphicsEvent
}
+ set up for getGraphicsEvent
Sorry to be annoying, but I'm not sure how long I should wait for an
acknowledgment. Perhaps Duncan is waiting for someone else to take the
lead in this? I think it would be great if R maintainers could
delegate commit powers to more people so that time isn't wasted by
eager contributors duplicating each other's no-brainer patches which
were ignored many years ago. I guess there is a lot more interest in
Windows than Linux, but maybe that means that someone should be
assigned to handle Linux-specific changes who cares about them. (I see
a lot of Word-document, Windows-character-set, and RStudio stuff on
this list, so I sympathize with any disinterest there may be in Linux
Xlib problems)
Let me know if you'd like to divorce the "onIdle" part of my patch
from the Cairo-enabling part and discuss those separately, perhaps
that would make sense if time is short.
Thanks for handling my recent Readline patches.
Frederick
On Tue, Jun 14, 2016 at 08:34:13AM -0700, frederik at ofb.net
wrote:> Hi Martin,
>
> > Also, as you are studying the C code and the issues anyway, it
> > may be worthwhile to consider (as small as possible!) patches to
> > the source you could also post to the bugzilla site if you
> > prefer; attaching as text/plain to R-devel does work fine, too.
>
> Well, after your kind solicitation I went through all the touble of
> locally fixing getGraphicsEvent Cairo support and implementing an
> onIdle handler.
>
> However, I noticed that the first part actually already has a patch on
> the R bug tracker, which is exactly the same as the fix I implemented!
> (minus documentation)
>
> https://bugs.r-project.org/bugzilla/show_bug.cgi?id=14364
>
> Problem: somebody ignored the patch and closed the bug. Who closed it?
> YOU!
>
> So, I guess since that patch (fixing Cairo support) was sent in 2010,
> and my patch (fixing both problems) is about 8 times longer, I can
> expect you to ignore my patch until at least 2063 (a tight lower bound
> if you apply Hugo's patch this year). :)
>
> I posted my patch here:
>
> https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16951
>
> Frederick
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>