search for: l140

...er(key = key, value = value, new_sp_m014:newrel_f65, na.rm = FALSE)) u == s # TRUE all.equal(u, s) # "target, current do not match when deparsed" identical(u, s) # FALSE | Thanks, Dan [1] https://github.com/wch/r-source/blob/e647f78cb85282263f88ea30c6337b77a30743d9/src/main/relop.c#L140-L155 ? [[alternative HTML version deleted]]

...ser interrupts. The timeout error message is thrown by the R_ProcessEvents(void) function as defined in: * src/unix/sys-unix.c (https://github.com/wch/r-source/blob/trunk/src/unix/sys-unix.c#L421-L453) * src/gnuwin32/system.c (https://github.com/wch/r-source/blob/trunk/src/gnuwin32/system.c#L110-L140) So, they're clearly different implementations on Windows and Unix. Also, for the Unix implementation, the code differ based on preprocessing directive HAVE_AQUA, which could explain why Spencer observes a different behavior than Peter and Berend (all on macOS). Whenever the R_CheckUserInter...

...; (A terminating DTMF was received). > > But I need to know **what** number that DTMF was, and I can't see a > way of grabbing it after the fact. > > I can see in the code where the right variables are.. > > https://github.com/asterisk/asterisk/blob/master/apps/app_record.c#L140 > dtmf_response > > https://github.com/asterisk/asterisk/blob/master/apps/app_record.c#L166 > * \param dtmf_integer the integer value of the DTMF key received > > So,3 questions I guess: > > 1: Am I going about this the right way? (unimrcp is not an option here) > 2: Can...

...by the R_ProcessEvents(void) >> function as defined in: >> >> * src/unix/sys-unix.c >> (https://github.com/wch/r-source/blob/trunk/src/unix/sys-unix.c#L421-L453) >> * src/gnuwin32/system.c >> (https://github.com/wch/r-source/blob/trunk/src/gnuwin32/system.c#L110-L140) >> >> So, they're clearly different implementations on Windows and Unix. >> Also, for the Unix implementation, the code differ based on >> preprocessing directive HAVE_AQUA, which could explain why Spencer >> observes a different behavior than Peter and Berend (al...

...l); if (j == 0) { goto L154; } --nll; y = y * j / (double) ((id - nll) * (ia - nll)); sumprb += y; if (sumprb >= dummy) { goto L159; } if (! lsp) { goto L140; } goto L150; y has no chance of becoming larger than zero and we are in the goto trap until the end of time. A simple fix would be checking for zero but I don't know how one would proceed in this case ... Best, Torsten

...wrel_f65, na.rm = FALSE)) u == s # > TRUE all.equal(u, s) # "target, current do not match when deparsed" > identical(u, s) # FALSE | > Thanks, > Dan > [1] https://github.com/wch/r-source/blob/e647f78cb85282263f88ea30c6337b77a30743d9/src/main/relop.c#L140-L155

...But I need to know **what** number that DTMF was, and I can't see a > >> way of grabbing it after the fact. > >> > >> I can see in the code where the right variables are.. > >> > >> https://github.com/asterisk/asterisk/blob/master/apps/app_record.c#L140 > >> dtmf_response > >> > >> https://github.com/asterisk/asterisk/blob/master/apps/app_record.c#L166 > >> * \param dtmf_integer the integer value of the DTMF key received > >> > >> So,3 questions I guess: > >> > >> 1: Am I g...

Hello everybody, I'm running R 1.8.1 on both Linux and OS X compiled with gcc 3.2.2 and 3.3, respectively. The following call seems to freeze the interpreter on both systems: > chisq.test(matrix(c(233, 580104, 3776, 5786104), 2, 2), simulate.p.value=TRUE) By freeze, I mean, the function call never returns (running > 10 hours so far), the process is unresponsive to SIGINT (but I

...error message is thrown by the R_ProcessEvents(void) > function as defined in: > > * src/unix/sys-unix.c > (https://github.com/wch/r-source/blob/trunk/src/unix/sys-unix.c#L421-L453) > * src/gnuwin32/system.c > (https://github.com/wch/r-source/blob/trunk/src/gnuwin32/system.c#L110-L140) > > So, they're clearly different implementations on Windows and Unix. > Also, for the Unix implementation, the code differ based on > preprocessing directive HAVE_AQUA, which could explain why Spencer > observes a different behavior than Peter and Berend (all on macOS). >...

...;> >>>> * src/unix/sys-unix.c >>>> >>>> (https://github.com/wch/r-source/blob/trunk/src/unix/sys-unix.c#L421-L453) >>>> * src/gnuwin32/system.c >>>> >>>> (https://github.com/wch/r-source/blob/trunk/src/gnuwin32/system.c#L110-L140) >>>> >>>> So, they're clearly different implementations on Windows and Unix. >>>> Also, for the Unix implementation, the code differ based on >>>> preprocessing directive HAVE_AQUA, which could explain why Spencer >>>> observes a diff...

On Tue, Jul 21, 2015 at 6:30 PM Justin Bogner <mail at justinbogner.com> wrote: > Paweł Bylica <chfast at gmail.com> writes: > > On Tue, Jul 21, 2015 at 5:55 PM Justin Bogner <mail at justinbogner.com> > wrote: > > > > Paweł Bylica <chfast at gmail.com> writes: > > > I can confirm that the issue has been caused by NDEBUG flag. >

...n as defined in: >>> >>> * src/unix/sys-unix.c >>> >>> (https://github.com/wch/r-source/blob/trunk/src/unix/sys-unix.c#L421-L453) >>> * src/gnuwin32/system.c >>> >>> (https://github.com/wch/r-source/blob/trunk/src/gnuwin32/system.c#L110-L140) >>> >>> So, they're clearly different implementations on Windows and Unix. >>> Also, for the Unix implementation, the code differ based on >>> preprocessing directive HAVE_AQUA, which could explain why Spencer >>> observes a different behavior than...

setTimeLimit(elapsed=1) causes a timeout error whenever a call takes more than one second. For instance, this is how it works on Windows (R 3.3.1): > setTimeLimit(elapsed=1) > Sys.sleep(10); message("done") Error in Sys.sleep(10) : reached elapsed time limit Also, the error propagates immediately and causes an interrupt after ~1 second; > system.time({ Sys.sleep(10);