[Rd] getGraphicsEvent on X11 and event queuing; Makefile.in
frederik at ofb.net
frederik at ofb.net
Sun Jun 12 05:49:20 CEST 2016
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
>
More information about the R-devel
mailing list