similar to: src/modules/X11/devX11.c, can we remove "#if BUG" yet

I don't recall exactly what I did 18 years ago eiher and I likely don't have the time to dig into the archives and reconstruct. I can imagine that the issue had to do with the protocol around creating and mapping windows. Presumably the segfault comes from looking for events on a window that hasn't been created yet, or has already been destroyed, leading to a NULL reference somewhere.

Thanks Professor Dalgard. If you have a different way to fix the bug then I'd be happy to test it. Or whatever. I understand that maybe some data was being referenced before it had been initialized. I could also support moving the R_ProcessEvents call in another place, but it seems one would also like to generate some kind of warning message, at the location of the bad reference, rather than

Hi Peter Yes, that looks roughly right to me. I would be in favour of your option (b), partly because it is probably easiest and partly because that retains the basic graphics device startup logic pattern that is replicated across all(?) graphics devices. Paul On 28/04/19 11:39 AM, peter dalgaard wrote: > I had a look at the current code, and AFAICT it has essentially the same structure

I tested it. It fixes the bug and didn't seem to produce any errors. Thank you Professor Dalgaard! I'm so glad this has finally been addressed. I will update the bug report. (https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16702) On Thu, May 02, 2019 at 04:48:51PM +0200, peter dalgaard wrote: >OK, this is now in R-devel, but only superficially tested (b/c this is a Mac). Please

Hi Sorry, I can't offer an explanation for the commented-out line. However, regarding your final question of avoiding the R-core bottleneck, you do have the option of creating a third-party graphics device package. See, for example, the 'tikzDevice' and 'svglite' packages on CRAN. Does that provide you with a way forward ? Paul On 20/04/2019 5:27 p.m., frederik at

I had a look at the current code, and AFAICT it has essentially the same structure as it did back then. I think it may have finally dawned upon me what the issue really is: The logic is that in Rf_addX11Device, we have if (!X11DeviceDriver(dev, display, width, height, ps, gamma, colormodel, maxcubesize, bgcolor, canvascolor,

OK, this is now in R-devel, but only superficially tested (b/c this is a Mac). Please check it out. -pd > On 30 Apr 2019, at 23:09 , Paul Murrell <paul at stat.auckland.ac.nz> wrote: > > Hi Peter > > Yes, that looks roughly right to me. I would be in favour of your option (b), partly because it is probably easiest and partly because that retains the basic graphics device

OK, so I did the archaeology anyway.... This was the story, R-core November 29, 2001. Part of thread "X11 still segfaults". ------------>> ..... Gah. I've been too tired today. Why did that take me so long? The culprit seems to be R_ProcessEvents((void*) NULL) in newX11DeviceDriver This gets called *before* this stuff at the end of Rf_addX11Device dd =

--=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I think I have found a very little bug in the new version of the X11() device in R 2.7.0, more precisely in the devX11.c file. The problem is that when you open a new window with X11(), the title of the window (the WM_NAME property) is not immediately set. It seems that the window is created, then it

Hi, I'm not sure this is a bug in the code, the comment or my thinking. So first try goes to r-devel... I find the following comment in X11_Open () (src/unix/X11/devX11.c): /* if we have to bail out with "error", then must free(dd) and free(xd) */ A couple lines down, there is: if (!strncmp(dsp, "png::", 5)) { FILE *fp; #ifndef HAVE_PNG error("No png support

Is it possible to start a X11() device in a minimized state? I have many windows, each with useful data, which clutter the screen. Having each window minimize upon creation would help. Mark -- Mark O. Kimball Gasparinilab, University of Buffalo | Low temp physics mok2 at physics.buffalo.edu | URL: enthalpy.physics.buffalo.edu lab phone: 716-645-2017x122 Fax: 716-645-2507

doKeybd() gets called in CHelpKeyIn() and NHelpKeyIn() in library/grDevices/src/devWindows.c, where the call is encapsulated in an 'if (dd->gettingEvent)' block. So the only times this code ever calls doKeybd() is when gettingEvent is in fact set. Further, it's called in two locations in X11_eventHelper(), in modules/X11/devX11.c, where the state of gettingEvent seems to be moot

Hello. I'm looking for documentation about the graphic device model in R. I would understand it in the details, but it seems a bit complex :) Thanks for any documents which will help me. Laurent

Dear R Development Team, I compile R-1.9.1 on AIX 5.2 under 2.9-aix51-020209, and xlf 7.1. In order to let R compile successfully under gcc 2.9, I have to change one C statement of file(RHOME//src/modules/X11/devX11.c) line 1768 from "retrun FALSE" to "retrun NULL", following is C code snapshot: newX11Desc * Rf_allocNewX11DeviceDesc(double ps) { newX11Desc *xd;

Hey all. As in general it's a bad idea to allow an event handler to generate an event, and as comments in the code seem to suggest this isn't the intention either, I was wondering about recursion in getGraphicsEvent(). In main/gevents.c, both doMouseEvent() and doKeybd() have the following line; dd->gettingEvent = FALSE; /* avoid recursive calls */ And they reset it to TRUE

Hi, I read the 2000 thread on a MetaPost device in R. If I understand correctly, the main problem with the concept is that R wants the device driver to give back information on the size of strings/labels. To the bet of my knowledge, MetaPost _does_ make it possible to measure the bounding box of text (see section 7.3: Measuring text in the MetaPost manual). For example, one could get the size of

Hi, sorry for lumping this together... Both these issues are rather small, and I'm not sure either qualifies as a bug... 1) After a window id created in X11_Open and mapped, you "gobble the expose events". Not true, you gobble any event that comes along! The code below fixes this by using *XCheckTypedEvent*. Hmm, I'm not sure this right already, but better... ***

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, frederik at ofb.net wrote: > Hi Paul, > > Just checking in to see what the

Dear R-devel - I have investigated the report I made at https://stat.ethz.ch/pipermail/r-devel/2008-May/049683.html some more, and believe I have enough information to warrant an update. My sessionInfo() immediately after starting R is at the bottom of this message. I decided to first concentrate on finding out why I sometimes receive a segfault while closing a graphics window while the

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, frederik at 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 >