[Rd] [FORGED] src/modules/X11/devX11.c, can we remove "#if BUG" yet

[irederik m@iii@g oii oib@@et]

Thanks Paul for answering the additional question.

I admit that I've only had experience with R's X11 code through work
on a couple of bugs, but for some reason I thought it might be
nontrivial to move it all into a self-contained module due to
interactions with various event loops. The two modules you listed
appear to be used for producing output in image and document formats,
so they don't really cast light on whether this is a problem.

I am not very serious about contributing my time to an effort like
this, but maybe it is good to have some discussion here anyway. I had
thought that maybe authors of alternative plotting interfaces would
have something to say about whether the current graphics design
provides sufficient modularity. Obviously it is modular enough for
RStudio to exist.

Other improvements aside, I think it would just be better to comment
out the old "#if BUG" line, and wait for someone to complain if it
breaks something. A lot has been changed since that line was added, as
I explained in the bug report. I would expect that the bug it was
attempting to fix no longer exists.

Otherwise, what is the next milestone on this bug?

Frederick

On Wed, Apr 24, 2019 at 12:30:44PM +1200, Paul Murrell wrote:
>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 using ofb.net wrote:
>>Dear R Devel,
>>
>>I know that someone put this line in src/modules/X11/devX11.c:2824 for
>>a reason, because commenting it out causes R to miss an important
>>ConfigureNotify event in my window manager. The result is that plots
>>are initially drawn off the window borders, unreadable.
>>
>>    R_ProcessX11Events((void*) NULL);
>>
>>Unfortunately for me, this line is commented in the standard release
>>of R, it has "#if BUG ... #endif" around it.
>>
>>I guess it is also unfortunate for anyone who uses the same window
>>manager as I do, namely i3, which I think is pretty popular among Unix
>>power users these days; not to mention other full-screen window
>>managers which probably exhibit the same bug in R.
>>
>>Maybe everyone on the Core team uses twm as their window manager? Or
>>RStudio on Windows? Which would be sad because then we're not
>>representing an important user demographic, namely those who prefer
>>software which is modern and powerful, yet simple to understand and
>>modify; fully configurable and interoperable and so on.
>>
>>I first reported this bug 3 years ago. In doing research for my bug
>>report, I found that the line was commented out by Peter Dalgaard in
>>2001 with the explanation "X11 segfault fix - I hope".
>>
>>I don't know what the way forward is. Obviously the Core Team has
>>reason to say, "look, this isn't very important, it's been broken
>>since 2001, maybe fixing it will cause the undocumented segfault bug
>>to reappear, clearly no one here uses your window manager". Do I have
>>to submit a correctness proof for the proposed change? What do I do?
>>
>>https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16702
>>
>>As mentioned in my bug report, I checked using gdb that
>>ConfigureNotify is indeed being received by the call to
>>R_ProcessX11Events() when it is uncommented. I haven't experienced any
>>segfaults.
>>
>>It's good that Peter left evidence that "R_ProcessX11Events" was being
>>called 18 years ago from X11DeviceDriver(). If he had deleted the
>>line, rather than commenting it, then discovering the reason for the
>>window rendering bug would have been much harder for me.
>>
>>However, the downside is that now it is not just a matter of inserting
>>the line where it belongs; I also feel a bit like I have to explain
>>why it was initially removed. But although I've given it some thought,
>>I still have no idea.
>>
>>Somewhat tangentially, I am wondering if there is some way that we
>>could make the development of R's graphics code proceed at a faster
>>rate, for example by pulling it out into a separate module, so that
>>people could offer alternative implementations via CRAN etc., rather
>>than having R Core be the bottleneck. Would this make sense? Has it
>>already been done?
>>
>>Thank you,
>>
>>Frederick
>>
>>______________________________________________
>>R-devel using 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
>paul using stat.auckland.ac.nz
>http://www.stat.auckland.ac.nz/~paul/
>