From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id C550240DDC2 for ; Sun, 21 Nov 2010 09:36:00 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0RRnDW28ebY for ; Sun, 21 Nov 2010 09:35:50 -0800 (PST) Received: from mail-qw0-f53.google.com (mail-qw0-f53.google.com [209.85.216.53]) by olra.theworths.org (Postfix) with ESMTP id 03AC240DF1F for ; Sun, 21 Nov 2010 09:35:49 -0800 (PST) Received: by qwd7 with SMTP id 7so1644291qwd.26 for ; Sun, 21 Nov 2010 09:35:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=Q4p+52QEleAGZwy7r8Li8yGJigiaLZMZbFneszAIThE=; b=LMSJaalOD2UgsZsqlNjTsuI0F4H11xdLQBDpqS8vvC6692zr4mdmDUncw/q7XdVX6Q XvEhujmKsdHowvk47aSr6GbcM9TmADjXQ5/+2fpOwZAbaXu1FJVcAh4iAopO9pRbpC7T W9HTUZ+DUYuxD7DuLY1zzeF4gAa0gp3/rx2nU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=pG6dg5Q3AbKQ8jdSoMB0tOuHhaoXfPp0fo7wKRT+50mVTIC+BbLVNpXDl+Uf70LxVH PeSGCqkAqIVuuNZEXFJ1MaK5HedROiA3RdN6oWV6T3zqU6nougAExfuhyRUYNB0Giip/ PTl8gO3biJq/GvI+8caj8+cSDRPS1B+Dm9V0s= MIME-Version: 1.0 Received: by 10.229.189.20 with SMTP id dc20mr4282247qcb.125.1290360947378; Sun, 21 Nov 2010 09:35:47 -0800 (PST) Received: by 10.229.224.202 with HTTP; Sun, 21 Nov 2010 09:35:47 -0800 (PST) In-Reply-To: References: <87sjyvk875.fsf@wsheee.2x.cz> Date: Sun, 21 Nov 2010 12:35:47 -0500 Message-ID: Subject: Re: [PATCH] Implement a simple read-eval-print loop. From: Austin Clements To: servilio Content-Type: multipart/alternative; boundary=0016362842dee68c950495939126 Cc: notmuch X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Nov 2010 17:36:00 -0000 --0016362842dee68c950495939126 Content-Type: text/plain; charset=ISO-8859-1 Out of curiosity, why not simply use SSH control mastering? You could even make that part of the "standard" remote notmuch script, without requiring the user to change anything in their ssh configuration. This should be just as fast as a remote notmuch shell, but retains the ability to run multiple simultaneous operations and leverages all of the fancy session machinery already built in to ssh. It seems to me that ssh already does what you want, and I'm curious what the advantage is to reinventing the wheel. On Sat, Nov 20, 2010 at 6:38 PM, servilio wrote: > Hi Michal, > > On 20 November 2010 16:15, Michal Sojka wrote: > > On Sat, 20 Nov 2010, servilio wrote: > >> This implementation uses GNU readline for the prompt and command > >> history, with the default file completion enabled. GLib is used to > >> split the read line into an arguments list. > > > > Hi, > > > > I haven't tested it yet, but it seems to be exactly the piece of code I > > wanted to have to speed up notmuch-hello when notmuch is used remotely > > over ssh. Spawning new ssh for every saved search to get the count of > > matched messages has a way too big overhead. Is this the use case you > > had in mind when implementing this? > > Great to see that you find it useful. Yes, the remote usage was in my > mind, but it should enhance the local usage as well. We could also > create a quicker test run using the shell. > > The disadvantage of using an interactive shell is that you can have > only one operation running in the UI, and I see no way of > interrumpting an operation unless you kill the process, but as > starting a new shell shouldn't be a biggie, this might not be as > limiting as might seem. > > The ideal would be for libnotmuch to be able to connect to a > xapian-tcpsrv, but haven't had time to look at than, and an > interactive shell seemed to be less time demanding to implement (and > had the subjective promise of providing a lot of fun). > > > Currently, I have only one comment to the patch. For me, "repl" is a bit > > unintuitive. I was thinking about "shell" as the name of subcommand for > > this. > > I agree, maybe "shell" or "interactive" would be more intuitive, but > when I started "repl" was the only one I could think of. > > Servilio > _______________________________________________ > notmuch mailing list > notmuch@notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch > --0016362842dee68c950495939126 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Out of curiosity, why not simply use SSH control mastering? =A0You could ev= en make that part of the "standard" remote notmuch script, withou= t requiring the user to change anything in their ssh configuration. =A0This= should be just as fast as a remote notmuch shell, but retains the ability = to run multiple simultaneous operations and leverages all of the fancy sess= ion machinery already built in to ssh. =A0It seems to me that ssh already d= oes what you want, and I'm curious what the advantage is to reinventing= the wheel.

On Sat, Nov 20, 2010 at 6:38 PM, servilio <servilio@gmail.co= m> wrote:
Hi Michal,

On 20 November 2010 16:15, Michal Sojka <sojkam1@fel.cvut.cz> wrote:
> On Sat, 20 Nov 2010, servilio wrote:
>> This implementation uses GNU readline for the prompt and command >> history, with the default file completion enabled. GLib is used to=
>> split the read line into an arguments list.
>
> Hi,
>
> I haven't tested it yet, but it seems to be exactly the piece of c= ode I
> wanted to have to speed up notmuch-hello when notmuch is used remotely=
> over ssh. Spawning new ssh for every saved search to get the count of<= br> > matched messages has a way too big overhead. Is this the use case you<= br> > had in mind when implementing this?

Great to see that you find it useful. Yes, the remote usage was in my=
mind, but it should enhance the local usage as well. We could also
create a quicker test run using the shell.

The disadvantage of using an interactive shell is that you can have
only one operation running in the UI, and I see no way of
interrumpting an operation unless you kill the process, but as
starting a new shell shouldn't be a biggie, this might not be as
limiting as might seem.

The ideal would be for libnotmuch to be able to connect to a
xapian-tcpsrv, but haven't had time to look at than, and an
interactive shell seemed to be less time demanding to implement (and
had the subjective promise of providing a lot of fun).

> Currently, I have only one comment to the patch. For me, "repl&qu= ot; is a bit
> unintuitive. I was thinking about "shell" as the name of sub= command for
> this.

I agree, maybe "shell" or "interactive" would be = more intuitive, but
when I started "repl" was the only one I could think of.

Servilio
__________________________________= _____________
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

--0016362842dee68c950495939126--