Re: [Rd] getGraphicsEvent() alternative for cairo graphics device?
Hi Paul, OK I tried not to make the examples too fancy. Please let me know what you think. They should probably be amended to support the Windows platform, but I think that task would be much easier for someone with access to Windows... By the way I'm Cc'ing Mark O'Connell who shared with me some great getGraphicsEvent examples - well, I found them useful, perhaps if these are going to the R distro somewhere, then his examples should be included as well. Thank you, Frederick On Mon, Nov 14, 2016 at 01:51:08PM +1300, Paul Murrell wrote: > > Great. Thanks! > > Paul > > On 14/11/16 13:41, frede...@ofb.net wrote: > > Hi Paul, > > > > Thank you, for some reason I didn't seem to get an email notification > > for your bugzilla comment! > > > > I will try to send you something shortly. > > > > Frederick > > > > On Mon, Nov 14, 2016 at 08:55:20AM +1300, Paul Murrell wrote: > > > Hi > > > > > > The current status is that I am keen for people to contribute some testing > > > code (see https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16951) > > > > > > There were also some getGraphicsEvent() changes/fixes suggested by Richard > > > Bodewits (cc'ed), for which I am also seeking test code. > > > > > > Paul > > > > > > On 13/11/16 09:00, frede...@ofb.net wrote: > > > > Hi Paul, > > > > > > > > Just checking in to see what the status is. > > > > > > > > From my perspective it seems logical to split off X11 into a separate > > > > package, so development can proceed at a reasonable rate, but I > > > > haven't yet tried to see if that's even possible. > > > > > > > > Thanks, > > > > > > > > Frederick > > > > > > > > On Tue, Jul 26, 2016 at 09:23:35AM +1200, Paul Murrell wrote: > > > > > Hi > > > > > > > > > > Taking a look at those patches is now on my todo list, so I may be in > > > > > touch > > > > > with both of you at some point to request some testing. > > > > > > > > > > Paul > > > > > > > > > > On 26/07/16 07:17, frede...@ofb.net wrote: > > > > > > Dear Daniel Greenidge, > > > > > > > > > > > > To enable getGraphicsEvent on Cairo, you have two patches to choose > > > > > > from: > > > > > > > > > > > > https://bugs.r-project.org/bugzilla/show_bug.cgi?id=14364 > > > > > > https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16951 > > > > > > > > > > > > The second one is by me, and the first one is from five years ago by > > > > > > Hugo Mildenberger. > > > > > > > > > > > > Both patches are very simple, they move some lines enabling > > > > > > getGrahpicsEvent outside of a if(!cairo) statement. My patch also > > > > > > adds > > > > > > the ability to execute code (e.g. for animation) while the interface > > > > > > is idle. > > > > > > > > > > > > Top guy Duncan Murdoch has expressed that he doesn't have time to > > > > > > work > > > > > > on applying these patches, and I haven't had any responses from the > > > > > > rest of the R Core Team. I was thinking that perhaps your best bet > > > > > > is > > > > > > to try to create a package called e.g. "X11-fixes" which people can > > > > > > use to get a better X11 library (there is also a bug waiting to be > > > > > > fixed from 2001: > > > > > > https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16702). > > > > > > > > > > > > I don't know if CRAN would accept such a package, or if you'd have > > > > > > to > > > > > > distribute it via GitHub, but R has excellent tools to facilitate > > > > > > the > > > > > > distribution of code via packages. Whether the R kernel exports > > > > > > enough > > > > > > functions to allow a package to take over event handling, I'm not > > > > > > sure. I was intending to look more into the details of this > > > > > > possibility but haven't had time. > > > > > > > > > > > > Best wishes, > > > > > > > > > > > > Frederick > > > > > > > > > > > > On Mon, Jul 25, 2016 at 02:15:59PM -0400, Daniel Greenidge wrote: > > > > > > > Hi all, > > > > > > > > > > > > > > I'm writing an interactive plotting function for viewing fMRI > > > > > > > datasets. Currently, I get keypresses using > > > > > > > grDevices::getGraphicsEvent(). > > > > > > > > > > > > > > Unfortunately getGraphicsEvent() only supports the > > > > > > > X11(type="Xlib") > > > > > > > graphics device on Unix systems. The Xlib device doesn't support > > > > > > > buffering (i.e. dev.hold() and dev.flush()), so redrawing the > > > > > > > plots > > > > > > > causes lots of flickering. > > > > > > > > > > > > > > Is there a way to get keypresses while using the cairo graphics > > > > > > > device? Alternatively, is there a way to prevent flickering with > > > > > > > the > > > > > > > Xlib graphics device? > > > > > > > > > > > > > > Best, > > > > > > > Daniel Greenidge > > > > > > > > > > > > > > __ > > > > > > > R-devel@r-project.org mailing list > > > > > > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > > > > > > > > > > > > > > > > ___
Re: [Rd] getGraphicsEvent() alternative for cairo graphics device?
Great. Thanks! Paul On 14/11/16 13:41, frede...@ofb.net wrote: Hi Paul, Thank you, for some reason I didn't seem to get an email notification for your bugzilla comment! I will try to send you something shortly. Frederick On Mon, Nov 14, 2016 at 08:55:20AM +1300, Paul Murrell wrote: Hi The current status is that I am keen for people to contribute some testing code (see https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16951) There were also some getGraphicsEvent() changes/fixes suggested by Richard Bodewits (cc'ed), for which I am also seeking test code. Paul On 13/11/16 09:00, frede...@ofb.net wrote: Hi Paul, Just checking in to see what the status is. From my perspective it seems logical to split off X11 into a separate package, so development can proceed at a reasonable rate, but I haven't yet tried to see if that's even possible. Thanks, Frederick On Tue, Jul 26, 2016 at 09:23:35AM +1200, Paul Murrell wrote: Hi Taking a look at those patches is now on my todo list, so I may be in touch with both of you at some point to request some testing. Paul On 26/07/16 07:17, frede...@ofb.net wrote: Dear Daniel Greenidge, To enable getGraphicsEvent on Cairo, you have two patches to choose from: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=14364 https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16951 The second one is by me, and the first one is from five years ago by Hugo Mildenberger. Both patches are very simple, they move some lines enabling getGrahpicsEvent outside of a if(!cairo) statement. My patch also adds the ability to execute code (e.g. for animation) while the interface is idle. Top guy Duncan Murdoch has expressed that he doesn't have time to work on applying these patches, and I haven't had any responses from the rest of the R Core Team. I was thinking that perhaps your best bet is to try to create a package called e.g. "X11-fixes" which people can use to get a better X11 library (there is also a bug waiting to be fixed from 2001: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16702). I don't know if CRAN would accept such a package, or if you'd have to distribute it via GitHub, but R has excellent tools to facilitate the distribution of code via packages. Whether the R kernel exports enough functions to allow a package to take over event handling, I'm not sure. I was intending to look more into the details of this possibility but haven't had time. Best wishes, Frederick On Mon, Jul 25, 2016 at 02:15:59PM -0400, Daniel Greenidge wrote: Hi all, I'm writing an interactive plotting function for viewing fMRI datasets. Currently, I get keypresses using grDevices::getGraphicsEvent(). Unfortunately getGraphicsEvent() only supports the X11(type="Xlib") graphics device on Unix systems. The Xlib device doesn't support buffering (i.e. dev.hold() and dev.flush()), so redrawing the plots causes lots of flickering. Is there a way to get keypresses while using the cairo graphics device? Alternatively, is there a way to prevent flickering with the Xlib graphics device? Best, Daniel Greenidge __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] getGraphicsEvent() alternative for cairo graphics device?
Hi Paul, Thank you, for some reason I didn't seem to get an email notification for your bugzilla comment! I will try to send you something shortly. Frederick On Mon, Nov 14, 2016 at 08:55:20AM +1300, Paul Murrell wrote: > Hi > > The current status is that I am keen for people to contribute some testing > code (see https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16951) > > There were also some getGraphicsEvent() changes/fixes suggested by Richard > Bodewits (cc'ed), for which I am also seeking test code. > > Paul > > On 13/11/16 09:00, frede...@ofb.net wrote: > > Hi Paul, > > > > Just checking in to see what the status is. > > > > From my perspective it seems logical to split off X11 into a separate > > package, so development can proceed at a reasonable rate, but I > > haven't yet tried to see if that's even possible. > > > > Thanks, > > > > Frederick > > > > On Tue, Jul 26, 2016 at 09:23:35AM +1200, Paul Murrell wrote: > > > Hi > > > > > > Taking a look at those patches is now on my todo list, so I may be in > > > touch > > > with both of you at some point to request some testing. > > > > > > Paul > > > > > > On 26/07/16 07:17, frede...@ofb.net wrote: > > > > Dear Daniel Greenidge, > > > > > > > > To enable getGraphicsEvent on Cairo, you have two patches to choose > > > > from: > > > > > > > > https://bugs.r-project.org/bugzilla/show_bug.cgi?id=14364 > > > > https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16951 > > > > > > > > The second one is by me, and the first one is from five years ago by > > > > Hugo Mildenberger. > > > > > > > > Both patches are very simple, they move some lines enabling > > > > getGrahpicsEvent outside of a if(!cairo) statement. My patch also adds > > > > the ability to execute code (e.g. for animation) while the interface > > > > is idle. > > > > > > > > Top guy Duncan Murdoch has expressed that he doesn't have time to work > > > > on applying these patches, and I haven't had any responses from the > > > > rest of the R Core Team. I was thinking that perhaps your best bet is > > > > to try to create a package called e.g. "X11-fixes" which people can > > > > use to get a better X11 library (there is also a bug waiting to be > > > > fixed from 2001: > > > > https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16702). > > > > > > > > I don't know if CRAN would accept such a package, or if you'd have to > > > > distribute it via GitHub, but R has excellent tools to facilitate the > > > > distribution of code via packages. Whether the R kernel exports enough > > > > functions to allow a package to take over event handling, I'm not > > > > sure. I was intending to look more into the details of this > > > > possibility but haven't had time. > > > > > > > > Best wishes, > > > > > > > > Frederick > > > > > > > > On Mon, Jul 25, 2016 at 02:15:59PM -0400, Daniel Greenidge wrote: > > > > > Hi all, > > > > > > > > > > I'm writing an interactive plotting function for viewing fMRI > > > > > datasets. Currently, I get keypresses using > > > > > grDevices::getGraphicsEvent(). > > > > > > > > > > Unfortunately getGraphicsEvent() only supports the X11(type="Xlib") > > > > > graphics device on Unix systems. The Xlib device doesn't support > > > > > buffering (i.e. dev.hold() and dev.flush()), so redrawing the plots > > > > > causes lots of flickering. > > > > > > > > > > Is there a way to get keypresses while using the cairo graphics > > > > > device? Alternatively, is there a way to prevent flickering with the > > > > > Xlib graphics device? > > > > > > > > > > Best, > > > > > Daniel Greenidge > > > > > > > > > > __ > > > > > R-devel@r-project.org mailing list > > > > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > > > > > > > > > > __ > > > > R-devel@r-project.org mailing list > > > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > > > > > > > -- > > > Dr Paul Murrell > > > Department of Statistics > > > The University of Auckland > > > Private Bag 92019 > > > Auckland > > > New Zealand > > > 64 9 3737599 x85392 > > > p...@stat.auckland.ac.nz > > > http://www.stat.auckland.ac.nz/~paul/ > > > > > -- > Dr Paul Murrell > Department of Statistics > The University of Auckland > Private Bag 92019 > Auckland > New Zealand > 64 9 3737599 x85392 > p...@stat.auckland.ac.nz > http://www.stat.auckland.ac.nz/~paul/ > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Memory leak with tons of closed connections
Using dup() before fdopen() (and calling fclose() on the connection
when it is closed) indeed fixes the memory leak.
FYI,
Gabor
Index: src/main/connections.c
===
--- src/main/connections.c (revision 71653)
+++ src/main/connections.c (working copy)
@@ -576,7 +576,7 @@
fp = R_fopen(name, con->mode);
} else { /* use file("stdin") to refer to the file and not the console */
#ifdef HAVE_FDOPEN
- fp = fdopen(0, con->mode);
+fp = fdopen(dup(0), con->mode);
#else
warning(_("cannot open file '%s': %s"), name,
"fdopen is not supported on this platform");
@@ -633,8 +633,7 @@
static void file_close(Rconnection con)
{
Rfileconn this = con->private;
-if(con->isopen && strcmp(con->description, "stdin"))
- con->status = fclose(this->fp);
+con->status = fclose(this->fp);
con->isopen = FALSE;
#ifdef Win32
if(this->anon_file) unlink(this->name);
On Fri, Nov 11, 2016 at 1:12 PM, Gábor Csárdi wrote:
> On Fri, Nov 11, 2016 at 12:46 PM, Gergely Daróczi
> wrote:
> [...]
>>> I've changed the above to *print* the gc() result every 1000th
>>> iteration, and after 100'000 iterations, there is still no
>>> memory increase from the point of view of R itself.
>
> Yes, R does not know about it, it does not manage this memory (any
> more), but the R process requested this memory from the OS, and never
> gave it back, which is basically the definition of a memory leak. No?
>
> I think the leak is because 'stdin' is special and R opens it with fdopen():
> https://github.com/wch/r-source/blob/f8cdadb769561970cc42776f563043ea5e12fe05/src/main/connections.c#L561-L579
>
> and then it does not close it:
> https://github.com/wch/r-source/blob/f8cdadb769561970cc42776f563043ea5e12fe05/src/main/connections.c#L636
>
> I understand that R cannot fclose the FILE*, because that would also
> close the file descriptor, but anyway, this causes a memory leak. I
> think.
>
> It seems that you cannot close the FILE* without closing the
> descriptor, so maybe a workaround would be to keep one FILE* open,
> instead of calling fdopen() to create new ones every time. Another
> possible workaround is to use dup(), but I don't know enough about the
> details to be sure.
>
> Gabor
>
> [...]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] getGraphicsEvent() alternative for cairo graphics device?
Hi The current status is that I am keen for people to contribute some testing code (see https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16951) There were also some getGraphicsEvent() changes/fixes suggested by Richard Bodewits (cc'ed), for which I am also seeking test code. Paul On 13/11/16 09:00, frede...@ofb.net wrote: Hi Paul, Just checking in to see what the status is. From my perspective it seems logical to split off X11 into a separate package, so development can proceed at a reasonable rate, but I haven't yet tried to see if that's even possible. Thanks, Frederick On Tue, Jul 26, 2016 at 09:23:35AM +1200, Paul Murrell wrote: Hi Taking a look at those patches is now on my todo list, so I may be in touch with both of you at some point to request some testing. Paul On 26/07/16 07:17, frede...@ofb.net wrote: Dear Daniel Greenidge, To enable getGraphicsEvent on Cairo, you have two patches to choose from: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=14364 https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16951 The second one is by me, and the first one is from five years ago by Hugo Mildenberger. Both patches are very simple, they move some lines enabling getGrahpicsEvent outside of a if(!cairo) statement. My patch also adds the ability to execute code (e.g. for animation) while the interface is idle. Top guy Duncan Murdoch has expressed that he doesn't have time to work on applying these patches, and I haven't had any responses from the rest of the R Core Team. I was thinking that perhaps your best bet is to try to create a package called e.g. "X11-fixes" which people can use to get a better X11 library (there is also a bug waiting to be fixed from 2001: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16702). I don't know if CRAN would accept such a package, or if you'd have to distribute it via GitHub, but R has excellent tools to facilitate the distribution of code via packages. Whether the R kernel exports enough functions to allow a package to take over event handling, I'm not sure. I was intending to look more into the details of this possibility but haven't had time. Best wishes, Frederick On Mon, Jul 25, 2016 at 02:15:59PM -0400, Daniel Greenidge wrote: Hi all, I'm writing an interactive plotting function for viewing fMRI datasets. Currently, I get keypresses using grDevices::getGraphicsEvent(). Unfortunately getGraphicsEvent() only supports the X11(type="Xlib") graphics device on Unix systems. The Xlib device doesn't support buffering (i.e. dev.hold() and dev.flush()), so redrawing the plots causes lots of flickering. Is there a way to get keypresses while using the cairo graphics device? Alternatively, is there a way to prevent flickering with the Xlib graphics device? Best, Daniel Greenidge __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dgamma density values in extreme point
On 13/11/2016 1:43 PM, Alexey Burnakov wrote: Dear R-Devel group, My name is Alexey, a data scientist from Moscow, currently working for Align Technology Inc. We have recently had a discussion of the results that the dgamma function (stats) returns for an extreme point (x == 0). inf. It's the limit as x --> 0. Although several other "big" statistics engines like Wolfram and Matlab return 0 (zero) for gamma density with the same function parameters where x == 0. Which looks like a convention rather than exact answer, in our opinion. Is this a correct assumption? When studies scrupulously, it appears that the density is undefined when we get x^0 where x == 0, for example. As I could not have reached the author of the code for dgamma, could you comment on this behavior of the dgamma function in zero? Is it safe to use the function given such behaviour. Is it prudent to report density = inf in zero? Is there a preferable way to estimate the gamma density in zero otherwise? Using the limit is the most sensible method. Having a discontinuity in the density will cause more problems, e.g. if the density is used in quadrature. As to the "correctness", we all know that the value of a density at any particular point is irrelevant. Only the integrals of densities have any meaning. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] dgamma density values in extreme point
Dear R-Devel group, My name is Alexey, a data scientist from Moscow, currently working for Align Technology Inc. We have recently had a discussion of the results that the dgamma function (stats) returns for an extreme point (x == 0). Density appears to be defined in point zero for the distribution with the said parameters. It looks like the returned value is a limit of f(x) where x --> inf. Although several other "big" statistics engines like Wolfram and Matlab return 0 (zero) for gamma density with the same function parameters where x == 0. Which looks like a convention rather than exact answer, in our opinion. Is this a correct assumption? When studies scrupulously, it appears that the density is undefined when we get x^0 where x == 0, for example. As I could not have reached the author of the code for dgamma, could you comment on this behavior of the dgamma function in zero? Is it safe to use the function given such behaviour. Is it prudent to report density = inf in zero? Is there a preferable way to estimate the gamma density in zero otherwise? Regards, Alexey Burnakov __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Missing objects using dump.frames for post-mortem debugging of crashed batch jobs. Bug or gap in documentation?
Dear R friends,
to allow post-mortem debugging In my Rscript based batch jobs I use
tryCatch( ,
error = function(e)
{
dump.frames(to.file = TRUE)
})
to write the called frames into a dump file.
This is similar to the method recommended in the "Writing R extensions"
manual in section 4.2 Debugging R code (page 96):
https://cran.r-project.org/doc/manuals/R-exts.pdf
> options(error = quote({dump.frames(to.file=TRUE); q()}))
When I load the dump later in a new R session to examine the error I use
load(file = "last.dump.rda")
debugger(last.dump)
My problem is that the global objects in the workspace are NOT contained
in the dump since "dump.frames" does not save the workspace.
This makes debugging difficult.
For more details see the stackoverflow question + answer in:
https://stackoverflow.com/questions/40421552/r-how-make-dump-frames-include-all-variables-for-later-post-mortem-debugging/40431711#40431711
I think the reason of the problem is:
If you use dump.files(to.file = FALSE) in an interactive session
debugging works as expected because it creates a global variable called
"last.dump" and the workspace is still loaded.
In the batch job scenario however the workspace is NOT saved in the dump
and therefore lost if you debug the dump in a new session.
Options to solve the issue:
--
1. Improve the documentation of the R help for "dump.frames" and the
R_exts manual to propose another code snippet for batch
job scenarios:
dump.frames()
save.image(file = "last.dump.rda")
2. Change the semantics of "dump.frames(to.file = TRUE)" to include
the workspace in the dump.
This would change the semantics implied by the function name
but makes the semantics consistent for both "to.file" param values.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
