From mboxrd@z Thu Jan  1 00:00:00 1970
Path: news.gmane.org!not-for-mail
From: Thien-Thi Nguyen <ttn@gnu.org>
Newsgroups: gmane.emacs.devel
Subject: Re: process.c: read_process_output: hard coded 4096 bytes read limit
Date: Wed, 26 Jun 2013 13:57:39 +0200
Message-ID: <87sj059j9o.fsf@zigzag.favinet>
References: <kq3ssm$b00$1@ger.gmane.org> <87txkpjhvd.fsf@igel.home>
	<kqbjso$6fk$1@ger.gmane.org>
NNTP-Posting-Host: plane.gmane.org
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha1; protocol="application/pgp-signature"
X-Trace: ger.gmane.org 1372247729 14612 80.91.229.3 (26 Jun 2013 11:55:29 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Wed, 26 Jun 2013 11:55:29 +0000 (UTC)
Cc: emacs-devel@gnu.org
To: Miguel Guedes <miguel.a.guedes@gmail.com>
Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 26 13:55:29 2013
Return-path: <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>
Envelope-to: ged-emacs-devel@m.gmane.org
Original-Received: from lists.gnu.org ([208.118.235.17])
	by plane.gmane.org with esmtp (Exim 4.69)
	(envelope-from <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>)
	id 1UroJs-0000YT-Dg
	for ged-emacs-devel@m.gmane.org; Wed, 26 Jun 2013 13:55:28 +0200
Original-Received: from localhost ([::1]:34928 helo=lists.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>)
	id 1UroJs-0003eZ-4x
	for ged-emacs-devel@m.gmane.org; Wed, 26 Jun 2013 07:55:28 -0400
Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56000)
	by lists.gnu.org with esmtp (Exim 4.71) (envelope-from <ttn@gnu.org>)
	id 1UroJo-0003eE-1W
	for emacs-devel@gnu.org; Wed, 26 Jun 2013 07:55:25 -0400
Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <ttn@gnu.org>) id 1UroJm-0006F6-7G
	for emacs-devel@gnu.org; Wed, 26 Jun 2013 07:55:23 -0400
Original-Received: from smtp207.alice.it ([82.57.200.103]:38600)
	by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <ttn@gnu.org>)
	id 1UroJl-0006Eo-TL
	for emacs-devel@gnu.org; Wed, 26 Jun 2013 07:55:22 -0400
Original-Received: from zigzag.favinet (79.1.74.199) by smtp207.alice.it (8.6.060.15)
	id 51B4DE8A0353E403; Wed, 26 Jun 2013 13:55:20 +0200
Original-Received: from ttn by zigzag.favinet with local (Exim 4.72)
	(envelope-from <ttn@gnu.org>)
	id 1UroMC-0003pC-Oy; Wed, 26 Jun 2013 13:57:52 +0200
In-Reply-To: <kqbjso$6fk$1@ger.gmane.org> (Miguel Guedes's message of "Tue, 25
	Jun 2013 08:20:40 +0000 (UTC)")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
X-detected-operating-system: by eggs.gnu.org: Genre and OS details not
	recognized.
X-Received-From: 82.57.200.103
X-BeenThere: emacs-devel@gnu.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: "Emacs development discussions." <emacs-devel.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-devel>,
	<mailto:emacs-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/emacs-devel>
List-Post: <mailto:emacs-devel@gnu.org>
List-Help: <mailto:emacs-devel-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-devel>,
	<mailto:emacs-devel-request@gnu.org?subject=subscribe>
Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org
Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org
Xref: news.gmane.org gmane.emacs.devel:161084
Archived-At: <http://permalink.gmane.org/gmane.emacs.devel/161084>

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

() Miguel Guedes <miguel.a.guedes@gmail.com>
() Tue, 25 Jun 2013 08:20:40 +0000 (UTC)

   How would you use accept-process-output with an asynchronous process
   channel?  E.g. when would you call it?  How do you know when there is
   data available?

Presumably the protocol specifies a format for the received data that
includes some kind of "end of message" marker.  You know there is data
available when that marker is not present (given a well-formed message).
For example:

(defun gnugo-synchronous-send/return (message)
  "Return (TIME . STRING) where TIME is that returned by `current-time' and
STRING omits the two trailing newlines.  See also `gnugo-query'."
  (when (gnugo-get :waitingp)
    (error "Sorry, still waiting for %s to play" (gnugo-get :gnugo-color)))
  (gnugo-put :sync-return "")
  (let ((proc (gnugo-get :proc)))
    (set-process-filter
     proc (lambda (proc string)
            (let* ((so-far (gnugo-get :sync-return))
                   (start  (max 0 (- (length so-far) 2))) ; backtrack a lit=
tle
                   (full   (gnugo-put :sync-return (concat so-far string))))
              (when (string-match "\n\n" full start)
                (gnugo-put :sync-return
                  (cons (current-time) (substring full 0 -2)))))))
    (gnugo-send-line message)
    (let (rv)
      ;; type change =3D> break
      (while (stringp (setq rv (gnugo-get :sync-return)))
        (accept-process-output proc))
      (gnugo-put :sync-return "")
      rv)))

Here, the "end of message" marker is two consecutive newlines, detected
by =E2=80=98string-match=E2=80=99.  The (gratuitously dynamically prepared,=
 but somewhat
convenient for copy-and-paste purposes :-D) filter func accumulates the
input and does the final (at EOM) transform, only.  The trigger for the
initial process output is from =E2=80=98gnugo-send-line=E2=80=99 after whic=
h it is
=E2=80=98gnugo-synchronous-send/return=E2=80=99 that controls the looping, =
by monitoring
the accumulated state to detect the transform.

   The only way (that I see) of knowing when there is data available is
   when the filter is first called but can accept-process- output be
   called from within the filter; wouldn't it lead to potentially
   massive recursiveness as the filter is called again and again?

Yes.  That's why the filter func and its (patiently looping) controller
must adhere to some mini protocol defining access to shared state, and
what that state "means".  [Insert VMS mailbox mumblings, here...]

=2D-=20
Thien-Thi Nguyen
GPG key: 4C807502

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAlHK1zkACgkQZwMiJEyAdQLhTwCg5MwLYS7JL6/ndQpowlTfkVru
KSMAoIMj37A0Ie14lgun5+ow604WhR/+
=ZWE0
-----END PGP SIGNATURE-----
--=-=-=--