tramp-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: tramp (2.2.13.25.1); compilation-auto-jump-to-first-error slowness


From: Dave Abrahams
Subject: Re: tramp (2.2.13.25.1); compilation-auto-jump-to-first-error slowness
Date: Fri, 03 Mar 2017 13:44:05 -0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (darwin)

on Fri Mar 03 2017, Michael Albinus <michael.albinus-AT-gmx.de> wrote:

> Dave Abrahams <address@hidden> writes:
>
> Hi Dave,
>
>>>> Seems to work great!
>>>
>>> I've pushed this patch, slightly modified, to the Emacs and Tramp
>>> repos. Will appear with Emacs 26.1.
>>>
>>>> It's a little odd that I see the remote shell
>>>> prompt and a little other garbage appear in the *compilation* window
>>>> before it is replaced by the expected contents, but that's just
>>>> cosmetic.
>>>
>>> That's the case for all asynchronous processes run by Tramp. There's no
>>> chance to suppress it, but as you said, it is minor only.
>>
>> My question is, why do I notice it only after applying the patch,
>> whereas I never saw it before applying the patch?
>
> The patch as I did send to you was a proof of concept. Finally, there is
> an optimized version now in the repository:

That one seems to work much better, thanks, and would not be improved by
the “interesting idea” I sent you earlier.

However, I am still seeing the hangs that I reported to you.

>
>
> *** /tmp/ediff78968Md 2017-03-03 20:13:15.660825068 +0100
> --- /tmp/ediff7896JXj 2017-03-03 20:13:15.728826271 +0100
> ***************
> *** 3614,3631 ****
>
>   ;;; Utility functions:
>
> ! (defun tramp-accept-process-output (&optional proc timeout timeout-msecs)
>     "Like `accept-process-output' for Tramp processes.
>   This is needed in order to hide `last-coding-system-used', which is set
>   for process communication also."
>     (with-current-buffer (process-buffer proc)
>       (let (buffer-read-only last-coding-system-used)
>         ;; Under Windows XP, accept-process-output doesn't return
> !       ;; sometimes.  So we add an additional timeout.
> !       (with-timeout ((or timeout 1))
> !     (accept-process-output proc timeout timeout-msecs (and proc t)))
> !       (tramp-message proc 10 "%s %s\n%s"
> !                  proc (process-status proc) (buffer-string)))))
>
>   (defun tramp-check-for-regexp (proc regexp)
>     "Check, whether REGEXP is contained in process buffer of PROC.
> --- 3614,3649 ----
>
>   ;;; Utility functions:
>
> ! (defun tramp-accept-process-output (proc timeout)
>     "Like `accept-process-output' for Tramp processes.
>   This is needed in order to hide `last-coding-system-used', which is set
>   for process communication also."
> +   ;; FIXME: There are problems, when an asynchronous process runs in
> +   ;; parallel, and also timers are active.  See
> +   ;; <http://lists.gnu.org/archive/html/tramp-devel/2017-01/msg00010.html>.
> +   (when (and timer-event-last
> +          (string-prefix-p "*tramp/" (process-name proc))
> +          (let (result)
> +            (maphash
> +             (lambda (key _value)
> +               (and (processp key)
> +                    (not (string-prefix-p "*tramp/" (process-name key)))
> +                    (tramp-compat-process-live-p key)
> +                    (setq result t)))
> +             tramp-cache-data)
> +            result))
> +     (sit-for 0.01 'nodisp))
>     (with-current-buffer (process-buffer proc)
>       (let (buffer-read-only last-coding-system-used)
>         ;; Under Windows XP, accept-process-output doesn't return
> !       ;; sometimes.  So we add an additional timeout.  JUST-THIS-ONE
> !       ;; is set due to Bug#12145.
> !       (tramp-message
> !        proc 10 "%s %s %s\n%s"
> !        proc (process-status proc)
> !        (with-timeout (timeout)
> !      (accept-process-output proc timeout nil t))
> !        (buffer-string)))))
>
>   (defun tramp-check-for-regexp (proc regexp)
>     "Check, whether REGEXP is contained in process buffer of PROC.
>
> Could you, pls, check whether this behaves better for you?
>
> Best regards, Michael.
>

-- 
-Dave



reply via email to

[Prev in Thread] Current Thread [Next in Thread]