[ESS] R-Markdown Locks up in Polymode/ESS

Tue Jan 26 21:19:58 CET 2016

I can reproduce the bug with melpa code but not with the identical code from
master. I tracked it down to the presence/absence of autoloads, which is strange
at the least. It's surely a very low level fontlock and re-display
synchronisation issue. Let's hope that new system will be void of such problems.

  Vitalie

>> On Tue, Jan 26 2016 16:46, Laurent Gatto wrote:

> On 26 January 2016 16:39, Vitalie Spinu wrote:

>> I am sorry for taking so long to reply to this (too much travelling recently).
>>
>> The current version of polymode (master) will be replaced by an extensive
>> rewrite of the core engine. I have done quite some work on it already and don't
>> have time to work on the old version. My hope is that the new version will fix
>> all the issues at ones.
>>
>> With emacs 25 I cannot reproduce your problem in old version of the polymode nor
>> with the new one (jit-lock-rewrite git branch). You can try that branch and see
>> if you have luck with it.

> I confirm that, using the test environement described in my previous
> email and the jit-lock-rewrite branch [1], it all works as expected.

> The bug was actually fixed before it even got reported...

> Thank you, Vitalie.

> Best wishes,

> Laurent

> [1] https://github.com/vspinu/polymode/commits/jit-lock-rewrite

>>   Vitalie
>>
>>
>>>> On Sun, Jan 24 2016 23:25, Bill Denney wrote:
>>
>>> I now have a reproducible example.  When I start typing in the last code
>>> chunk of this file, it crashes.  What I want to be there is
>>
>>> ```{r}
>>
>>> intervals <-
>>
>>>   data.frame(start=c(0, 0), end=c(24, Inf),
>>
>>>              cmax=c(FALSE, TRUE),
>>
>>>              tmax=c(FALSE, TRUE),
>>
>>>              auclast=TRUE,
>>
>>>              aucinf=c(FALSE, TRUE))
>>
>>> ```
>>
>>> I start by typing "intervals" right before "data.frame", and emacs takes
>>> 100% of the CPU.
>>
>>> Thanks,
>>
>>> Bill 
>>
>>> -----Original Message-----
>>> From: Laurent Gatto [mailto:lg390 at cam.ac.uk] 
>>> Sent: Monday, January 18, 2016 4:28 PM
>>> To: ess-help at r-project.org
>>> Cc: Bill Denney <bill at denney.ws>
>>> Subject: Re: [ESS] R-Markdown Locks up in Polymode/ESS
>>
>>> Dear Bill,
>>
>>> I think I am experiencing the same problem here; I have this recurring issue
>>> with emacs, that has become serious since I updated all my package. When I
>>> edit an Rmarkdown file emacs randomly freezes and the emacs process takes up
>>> 100% of the CPU.
>>
>>> As far as I can remember, this happens when I'm editing code chunks. I am
>>> not really sure what happens or what package is the problem. I just observed
>>> that this still happens when I don't load markdown-mode.
>>
>>> I strace'd the emacs process after a freeze - here is a short representative
>>> extract.
>>
>>> poll([{fd=5, events=POLLIN}, {fd=4, events=POLLIN}], 2, 0) = 0 (Timeout)
>>
>>> recvmsg(4, 0x7fffe86bc3a0, 0)           = -1 EAGAIN (Resource temporarily
>>> unavailable)
>>
>>> poll([{fd=5, events=POLLIN}, {fd=4, events=POLLIN}], 2, 0) = 0 (Timeout)
>>
>>> --- SIGIO {si_signo=SIGIO, si_code=SI_KERNEL} ---
>>
>>> rt_sigreturn()                          = 195
>>
>>> recvmsg(4, {msg_name(0)=NULL,
>>> msg_iov(1)=[{"\6\0\236\306\316H\340\0\235\0\0\0\302\0@\1\0\0\0\0\306\4o\3
>>> \3\26\3\0\0\1\0", 4096}], msg_controllen=0, msg_flags=0}, 0) = 32
>>
>>> recvmsg(4, 0x7fffe86bc6f0, 0)           = -1 EAGAIN (Resource temporarily
>>> unavailable)
>>
>>> poll([{fd=5, events=POLLIN}, {fd=4, events=POLLIN}], 2, 0) = 0 (Timeout)
>>> poll([{fd=5, events=POLLIN}, {fd=4, events=POLLIN}], 2, 0) = 0 (Timeout)
>>
>>> recvmsg(4, 0x7fffe86bc6f0, 0)           = -1 EAGAIN (Resource temporarily
>>> unavailable)
>>
>>> poll([{fd=5, events=POLLIN}, {fd=4, events=POLLIN}], 2, 0) = 0 (Timeout)
>>
>>> --- SIGIO {si_signo=SIGIO, si_code=SI_KERNEL} ---
>>
>>> rt_sigreturn()                          = 10986603
>>
>>> I have observed this recvmsg and timeouts/Resources temporarily unavailable
>>> several times in such situations, but I can't make any sense of this.
>>
>>> Here are the respective versions
>>
>>>   markdown-mode 20160113.816
>>
>>>   polymode 20151216.533
>>
>>>   ess-version: 15.09-2 patched [elpa: 20160110.2313]
>>
>>>   GNU Emacs 24.5.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.23) of
>>> 2015-07-27
>>
>>> Not of much help, but hopefully someone else will be able provide some.
>>
>>> Best wishes,
>>
>>> Laurent
>>
>>> On 18 January 2016 16:43, Bill Denney wrote:
>>
>>>> Hi,
>>
>>>> 
>>
>>>>  
>>
>>>> 
>>
>>>> I've just started taking advantage of the benefits of polymode and ESS 
>>
>>>> combined for r-markdown documents having previously manually coded them.
>>
>>>> I'm using them to make a vignette for the PKNCA package, and when I 
>>
>>>> scroll through the .Rmd file, emacs locks up when leaving the first 
>>
>>>> code block after I make an edit in the block.  It fully locks up, and 
>>
>>>> I can't switch to the messages buffer in emacs to see the reason for the
>>> hang.
>>
>>>> 
>>
>>>>  
>>
>>>> 
>>
>>>> Here are the steps to reproduce the error as I'm using it.
>>
>>>> 
>>
>>>>  
>>
>>>> 
>>
>>>> Windows 10 (up to date)
>>
>>>> 
>>
>>>> Emacs version: GNU Emacs 24.5.1 (i686-pc-mingw32) of 2015-04-11
>>
>>>> 
>>
>>>> ESS version: ess-version: 15.09-2 [Released git: 01328e83039f]
>>
>>>> 
>>
>>>> Polymode installed via MELPA yesterday: version 20151216.533 as 
>>
>>>> described by MELPA
>>
>>>> 
>>
>>>> Markdown-mode installed via MELPA yesterday: version 20160115.2318 as 
>>
>>>> described by MELPA
>>
>>>> 
>>
>>>>  
>>
>>>> 
>>
>>>> 1.      Load the file in emacs
>>
>>>> 
>>
>>>> 2.      Scroll down to the first code block (see below my signature for
>>> the
>>
>>>> snippet)
>>
>>>> 
>>
>>>> 3.      Change "addlastrow" to "setpredose" (I have no R buffers open)
>>
>>>> 
>>
>>>> 4.      Scroll out of the code block
>>
>>>> 
>>
>>>>  
>>
>>>> 
>>
>>>> As I do step 4, it locks up.  This is unfortunately not fully 
>>
>>>> reproducible, and I can't figure out the specific trigger that changes 
>>
>>>> it from working normally to hanging.  With previous experience, it 
>>
>>>> looks similar to an attempted function argument lookup hang, but that is
>>> mostly a guess.
>>
>>>> 
>>
>>>>  
>>
>>>> 
>>
>>>> Any thoughts to what this could be or ways that I could improve the 
>>
>>>> bug report with better tracking of how it hangs?
>>
>>>> 
>>
>>>>  
>>
>>>> 
>>
>>>> Thanks,
>>
>>>> 
>>
>>>>  
>>
>>>> 
>>
>>>> Bill
>>
>>>> 
>>
>>>>  
>>
>>>> 
>>
>>>> File snippet:
>>
>>>> 
>>
>>>>  
>>
>>>> 
>>
>>>> Two examples are given below.
>>
>>>> 
>>
>>>>  
>>
>>>> 
>>
>>>> ```{r eval=FALSE}
>>
>>>> 
>>
>>>> list(operation="add",
>>
>>>> 
>>
>>>>      FUN=addlastrow)
>>
>>>> 
>>
>>>> ```
>>
>>>> 
>>
>>>> 
>>
>>>>             [[alternative HTML version deleted]]
>>
>>>> 
>>
>>>> ______________________________________________
>>
>>>>  <mailto:ESS-help at r-project.org> ESS-help at r-project.org mailing list
>>
>>>>  <https://stat.ethz.ch/mailman/listinfo/ess-help>https://stat.ethz.ch/mailman/listinfo/ess-help>
>>> ______________________________________________
>>> ESS-help at r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/ess-help