similar to: core show channels truncates channel names?

svn trunk 31497 For the life of me, I can't get this :) I want to be able to catch the situation where the calling party hangs up *before* the call is connected to the called party. My dialplan is thus: macro DialExternal(exten) { Dial(Zap/G3/${exten},120,g,M(connected)); goto DialResult|r${HANGUPCAUSE}|1; Hangup(); }; But the goto dialresult is not executed: Executing

I am trying to connect an IAX ATA to an Asterisk 1.4.21.2 system. The Asterisk system has been stable for years, and has no trouble bridge SIP phone sets to IAX trunks. When I initiate a call from the IAX ATA, something goes wrong. One rare occasion it works fine, but usually there is no audio passed. I have a snippet of the console below. Notice no bridging message...not sure if that's

Hi I posted earlier about having issues connecting to Telewest's ISDN, only to find out later Telewest had forgotten to turn it on - hopefully I'm not having a similar silly problem. My PRI span is now up and operational, but when I try to send a call out over it, I just get congestion tones. Occasionally, I get about one second of ring tones, only for it to cut out and play congestion.

I'm still struggling to pickup calls. I now have a single context (entryocginternal) where I have "include => parkedcalls". The log below shows me calling from one internal extension to another, then picking up, then parking the call. -- SIP/239-0915d5c8 is ringing -- SIP/239-0915d5c8 answered SIP/233-0915bf40 -- Packet2Packet bridging SIP/233-0915bf40 and

I'm running dovecot 1.0.rc2 (package from ubuntu 6.10) and use the dovecot lda 'deliver' (also a package from ubuntu 6.10 with sieve filtering) to deliver messages to maildir. Everything works well, until I discovered a truncated message this week. The problematic message is a message bounced by the majordomo mailinglist software. I think the problem is related to the fact that

With C:\Users\User>R --version R version 2.14.0 RC (2011-10-23 r57410) Copyright (C) 2011 The R Foundation for Statistical Computing ISBN 3-900051-07-0 Platform: x86_64-pc-mingw32/x64 (64-bit) running download.file('http://www.ebi.ac.uk/microarray-as/ae/files/E-TABM-25/E-TABM-25.raw.1.zip', tempfile()) sometimes gets 52% (according to the dialog box) of the way through, and then

>>>>> Joris Meys <jorismeys at gmail.com> >>>>> on Fri, 4 May 2018 10:00:07 +0200 writes: > On Fri, May 4, 2018 at 8:34 AM, Tomas Kalibera > <tomas.kalibera at gmail.com> wrote: >> The current heuristic/hack is in line with the >> compatibility approach: it detects files that are >> obviously binary, so it

Martin, also from me a heartfelt thank you for taking care of this. Some thoughts on Henrik's response: On Mon, May 7, 2018 at 2:28 AM, Henrik Bengtsson <henrik.bengtsson at gmail.com > wrote: > > I still argue that the current behavior cause more harm than it helps. > I agree with your analysis of the problems this legacy behaviour causes. Deprecating the default

On Tue, May 8, 2018 at 8:15 AM, Hadley Wickham <h.wickham at gmail.com> wrote: > On Thu, May 3, 2018 at 11:34 PM, Tomas Kalibera > <tomas.kalibera at gmail.com> wrote: >> On 05/03/2018 11:14 PM, Henrik Bengtsson wrote: >>> >>> Also, as mentioned in my >>> https://stat.ethz.ch/pipermail/r-devel/2012-August/064739.html, when >>> not

On 05/08/2018 05:15 PM, Hadley Wickham wrote: > On Thu, May 3, 2018 at 11:34 PM, Tomas Kalibera > <tomas.kalibera at gmail.com> wrote: >> On 05/03/2018 11:14 PM, Henrik Bengtsson wrote: >>> Also, as mentioned in my >>> https://stat.ethz.ch/pipermail/r-devel/2012-August/064739.html, when >>> not specifying the mode argument, the default on Windows is

On 05/02/2018 03:21 PM, Joris Meys wrote: > Dear all, > > I've noticed by trying to download gz files from here : > https://www.ncbi.nlm.nih.gov/geo/query/acc.cgi?acc=GSM907811 > > At the bottom one can download GSM907811.CEL.gz . If I download this > manually and try > > oligo::read.celfiles("GSM907811.CEL.gz") > > everything works fine. (oligo

Thank you Henrik and Martin for explaining what was going on. Very insightful! On Thu, May 3, 2018 at 4:21 PM, Jeroen Ooms <jeroenooms at gmail.com> wrote: > On Thu, May 3, 2018 at 2:42 PM, Henrik Bengtsson > <henrik.bengtsson at gmail.com> wrote: > > Use mode="wb" when you download the file. See > >

There was a hint in the Twitterverse that Excel has issues with line endings in .csv. Can anyone elaborate on that? Then again, Excel goes belly-up on comma separators in central European locales anyway... -pd > On 8 May 2018, at 22:47 , Hadley Wickham <h.wickham at gmail.com> wrote: > > > Also note that MS just announced support for unix line endings in notepad > >

http://bugzilla.mindrot.org/show_bug.cgi?id=765 Summary: openssh client truncates banner at 1024 characters. Product: Portable OpenSSH Version: -current Platform: ix86 OS/Version: Linux Status: NEW Severity: minor Priority: P2 Component: ssh AssignedTo: openssh-bugs at mindrot.org

Good Day. In June, I posted a small query under the Subject of _odd smbpasswd / smbclient error from Linux to Solaris_ Briefly, a Solaris sparc server running 3.0.25a would not accept passwords from the Linux smbclient program if the password was 9 characters or greater. Instead, one would get this: session setup failed: NT_STATUS_LOGON_FAILURE but it worked fine with the Solaris sparc

Use mode="wb" when you download the file. See https://github.com/HenrikBengtsson/Wishlist-for-R/issues/30. R core, and others, is there a good argument for why we are not making this the default download mode? It seems like a such a simple fix to such a common "mistake". Henrik On Thu, May 3, 2018, 00:44 Joris Meys <jorismeys at gmail.com> wrote: > Dear all, >

Hi, I have been debugging a small perl script (see ShowBug2) that I use. In doing so, I think that I may have uncovered a problem with the dovecot IMAP server. Attached are two packet traces for connections to two different IMAP servers. On both servers I run the script: i.e. I login, select a folder, search for messages and append a message. On the fvs5 server (Courier IMAP?), everything

Appended is the file -- you need to tell your e-mail software to use one of the MIME types that R-devel does accept; text/plain is what I chose ((Yes, as R mailing list server "operator", with a bit of detective work, I was able to find the "uncleaned" e-mail and extract the attachment from it)) Martin Maechler ETH Zurich -------------- next part -------------- An

Using the correct mode absolutely solves it. Apologies for not trying the obvious. Cheers Joris On Thu, May 3, 2018 at 2:10 PM, Martin Morgan <martin.morgan at roswellpark.org > wrote: > > > On 05/02/2018 03:21 PM, Joris Meys wrote: > >> Dear all, >> >> I've noticed by trying to download gz files from here : >>

On 05/03/2018 11:14 PM, Henrik Bengtsson wrote: > Also, as mentioned in my > https://stat.ethz.ch/pipermail/r-devel/2012-August/064739.html, when > not specifying the mode argument, the default on Windows is mode = "w" > *except* for certain, case-sensitive, filename extensions: > > if(missing(mode) &&