From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: run-with-timer vs run-with-idle-timer Date: Thu, 10 May 2018 13:28:20 +0100 Message-ID: References: <87tvrgd972.fsf@gmail.com> <87a7t74tsf.fsf@gnuvola.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000de7a7e056bd9288d" X-Trace: blaine.gmane.org 1525955207 9444 195.159.176.226 (10 May 2018 12:26:47 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 10 May 2018 12:26:47 +0000 (UTC) Cc: emacs-devel To: Thien-Thi Nguyen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 10 14:26:43 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fGkeg-0002Gl-Dc for ged-emacs-devel@m.gmane.org; Thu, 10 May 2018 14:26:42 +0200 Original-Received: from localhost ([::1]:33657 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fGkgl-00005T-OP for ged-emacs-devel@m.gmane.org; Thu, 10 May 2018 08:28:51 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33304) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fGkge-00005G-W5 for emacs-devel@gnu.org; Thu, 10 May 2018 08:28:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fGkgd-0000jp-SR for emacs-devel@gnu.org; Thu, 10 May 2018 08:28:45 -0400 Original-Received: from mail-qt0-x22c.google.com ([2607:f8b0:400d:c0d::22c]:35394) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fGkgc-0000gH-3Z; Thu, 10 May 2018 08:28:42 -0400 Original-Received: by mail-qt0-x22c.google.com with SMTP id f5-v6so2253737qth.2; Thu, 10 May 2018 05:28:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MZah5BE88MskQ2jKy9jyuxkTBK+tvULn/a4q5/3zhgc=; b=Ks1LT2MP0dyWm+cHXq1FlLc7NP8JoyBtTYmrltKrwpCIt1cDzY4luYJKFzSmx5IK1+ lzZsgEVg6a/XI6QGwLQUI4DsBLhUejXmLT0zzcWTTFmCbf3aIFjsQc02toBM8JOXIrwe ZA/pq2sXqAlb5onI/oZDph2Yq7LJs9uijsggD0+sMa4PgJNhT9FI6wMllOhXBskZOc1J ZAZDve9eJSy11DxtY7PVXdIM03ecW4s0wANlzVCzW9TJukfO/yKUD+0By5BbwAWTRiBr IwoecHQnkfSY1vLMNlhNCZ/9+7UkbKpQi3OesUeLY+TpHCP8Lz5eb3ArjYPB3CpfAY8k U1BQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MZah5BE88MskQ2jKy9jyuxkTBK+tvULn/a4q5/3zhgc=; b=g639iNvR4EbJJ9sIQcVvEbzbrh9PWJgBmouByxfoBSWqCsKRuGDSgFW1E5kl9zOo9/ 8EmdzOr34lZzD/2PyJFIgCcvJ36JPlPACEEbEAOHx3kLAyhhjKubgjCMRu0yQOjdvQJ1 qnByWTKZT6Xm1/j0cAN+McPTmliVUjP9iO7WoKSItoxutTc8sIQ8DN5bvELwnHlZE9hJ dWdEC7gA6MGPm9Vn+LxukBQwkIrngbpYKSKW7EPYdDVfPKE2/Zf920QYu6FNAx9OAuZK AynN1kww+V2L5DEUWmz3ZrMCtA2LhhNO2U/duOHOlgZ3PeQOdFWtuCujP7rmo0KGxuON 3h6w== X-Gm-Message-State: ALKqPwdWHxNH3U1sR62FAFRUZOCD95kkM2W41VroL2I5lORh0c7f65Ca wM+V17/ZYXPrBFOUD5WlTGCzetzyu5DFD4tuIrmgmo9d X-Google-Smtp-Source: AB8JxZrTSMJggPqB7kmIhxka6j/JqBsGvFG5BB25n7VJpUFy1fr7TcO+qbgWCQUX1eZnmRepCG3uubFEqAlDPAQOJW8= X-Received: by 2002:aed:3b37:: with SMTP id p52-v6mr1116712qte.106.1525955321296; Thu, 10 May 2018 05:28:41 -0700 (PDT) Original-Received: by 10.12.148.200 with HTTP; Thu, 10 May 2018 05:28:20 -0700 (PDT) In-Reply-To: <87a7t74tsf.fsf@gnuvola.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:400d:c0d::22c X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:225197 Archived-At: --000000000000de7a7e056bd9288d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Thien, I probably should have mentioned I'm setting up an RPC protocol. I'm using throw/catch because there are lambdas setup inside that block (but outside the while t). Inside the lambda is the throw. I then store these lambdas in a global CONTINUATIONS var that the process filter looks up and calls if appropriate. The infloop breaks then. It's much harder (and much less efficient at first sight) to do it by polling CONDITION, but I may be missing something. Let me know if you want to look at a concrete example of the lambda strategy. BTW I learned this strategy reading SLIME, I just simplified it when lexical binding came along. It's been working there and in other projects for a long time. Jo=C3=A3o On Thu, May 10, 2018 at 12:46 PM, Thien-Thi Nguyen wrote: > > () Jo=C3=A3o T=C3=A1vora > () Wed, 09 May 2018 18:34:41 +0100 > > (while t..) spin is a common way to wait for async conditions > > Why not check the condition directly, i.e., s/t/CONDITION/ like: > > (while CONDITION > (accept-process-output ...)) > > That is more precise, no? Another idea, if there is some > expected traffic, is to use =E2=80=98(accept-process-output ...)=E2=80=99 > directly as (or as part of) CONDITION, using its return value. > > -- > Thien-Thi Nguyen ----------------------------------------------- > (defun responsep (query) > (pcase (context query) > (`(technical ,ml) (correctp ml)) > ...)) 748E A0E8 1CB8 A748 9BFA > --------------------------------------- 6CE4 6703 2224 4C80 7502 > > --=20 Jo=C3=A3o T=C3=A1vora --000000000000de7a7e056bd9288d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Thien,

I probably should have mentioned I'm setting up an RPC proto= col.

I'm using throw/catch because there= are lambdas setup inside that
block (but outside the while t). I= nside the lambda is the throw.=C2=A0
I then store these lambdas i= n a global CONTINUATIONS var that the=C2=A0
process filter looks = up and calls if appropriate. The infloop breaks then.=C2=A0

<= /div>
It's much harder (and much less efficient at first sight) to = do it by polling
CONDITION, but I may be missing something. Let m= e know=C2=A0
if you want to look at a concrete example of the lam= bda strategy.

BTW I learned this strategy reading = SLIME, I just simplified it when lexical=C2=A0
binding came along= . It's been working there and in other projects for=C2=A0
a l= ong time.

Jo=C3=A3o


On Thu, May 10, 2018 = at 12:46 PM, Thien-Thi Nguyen <ttn@gnu.org> wrote:

() Jo=C3=A3o T=C3=A1vora <joaota= vora@gmail.com>
() Wed, 09 May 2018 18:34:41 +0100

=C2=A0 =C2=A0(while t..) spin is a common way to wait for async conditions<= br>
Why not check the condition directly, i.e., s/t/CONDITION/ like:

=C2=A0(while CONDITION
=C2=A0 =C2=A0(accept-process-output ...))

That is more precise, no?=C2=A0 Another idea, if there is some
expected traffic, is to use =E2=80=98(accept-process-output ...)=E2=80=99 directly as (or as part of) CONDITION, using its return value.

--
Thien-Thi Nguyen -----------------------------------------------
=C2=A0(defun responsep (query)
=C2=A0 =C2=A0(pcase (context query)
=C2=A0 =C2=A0 =C2=A0(`(technical ,ml) (correctp ml))
=C2=A0 =C2=A0 =C2=A0...))=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 748E A0E8 1CB8 A748= 9BFA
--------------------------------------- 6CE4 6703 2224 4C80 7502




--
Jo=C3= =A3o T=C3=A1vora
--000000000000de7a7e056bd9288d--