From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Michael Heerdegen Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Elpa: Pinpoint semantics of `seq-subseq' for streams Date: Thu, 15 Sep 2016 23:29:39 +0200 Message-ID: <87oa3oam2k.fsf@web.de> References: <87bmzrahvg.fsf@web.de> <79c6ccd6-9808-f4fd-071a-58559f72ecdc@gmail.com> <8737l3a4ab.fsf@web.de> <27962aa1-ae40-99f8-64ad-ae21012fb36e@gmail.com> <87vaxywmh9.fsf@web.de> <87zina568j.fsf@web.de> <63ebf6ee-d623-e863-42a8-bc802d3df54d@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1473975039 28305 195.159.176.226 (15 Sep 2016 21:30:39 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 15 Sep 2016 21:30:39 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) Cc: emacs-devel@gnu.org To: =?utf-8?Q?Cl=C3=A9ment?= Pit--Claudel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 15 23:30:35 2016 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 1bkeEj-0005is-UY for ged-emacs-devel@m.gmane.org; Thu, 15 Sep 2016 23:30:26 +0200 Original-Received: from localhost ([::1]:37457 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bkeEi-0006c0-1g for ged-emacs-devel@m.gmane.org; Thu, 15 Sep 2016 17:30:24 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34899) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bkeE9-0006bh-L9 for emacs-devel@gnu.org; Thu, 15 Sep 2016 17:29:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bkeE5-00070j-H7 for emacs-devel@gnu.org; Thu, 15 Sep 2016 17:29:48 -0400 Original-Received: from mout.web.de ([212.227.15.4]:52756) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bkeE5-000708-6r for emacs-devel@gnu.org; Thu, 15 Sep 2016 17:29:45 -0400 Original-Received: from drachen.dragon ([90.186.1.83]) by smtp.web.de (mrweb003) with ESMTPSA (Nemesis) id 0Lvjoa-1axO2N0tjw-017Yu4; Thu, 15 Sep 2016 23:29:43 +0200 In-Reply-To: <63ebf6ee-d623-e863-42a8-bc802d3df54d@gmail.com> (=?utf-8?Q?=22Cl=C3=A9ment?= Pit--Claudel"'s message of "Wed, 14 Sep 2016 23:47:47 -0400") X-Provags-ID: V03:K0:rDRAeQFhSRWCbZlbc5Woq3pS5VUXahLgQG1yMwYhIckFWqpAeZW fXaT9SXkstACs66UpBuuVra8WYHdZGNYci+o8Q6BEzGHLXGvXymiGXHFPoFULxx/XNV2XOt uK/aSVxqan4/gFtMiEtzEw4RdCVcZILHKrUjOU9ijlDTXSdHJcZ+34U4q3LpQDQJTQANPxg C43Ofsln9FqFGyueMzgdA== X-UI-Out-Filterresults: notjunk:1;V01:K0:Sk2roCtwKr8=:iAbj2sUN60DkYROEpFs0Yp u8I4zmEvvQVlBsy8P4Ox5+1rn8KzCtdQc7t3uPY0aQFm5Y9Qz9O2R5P0XVr+zn9lxc9DjI7sV 9RVAp6rxinMBhnsI95KQRQYC9AYUfnGHYwCjdMV3tsZ4nEBW/E33svGc9LV9E79rcxV6c+7uR v7awkw7n0t+W/EEKp91nioaYmmp9RYBU8JtjBYhrvwPKYZUsWwsfTUQYnbNzMH+i9o3rzkBIl dsLjurTIv8bMDUDaNWRtFXezoq/nTQT8enx1uANCNfpAZtxkuVrYc0Kzaf4IkSYlHdUXmD3MD yD/a5lDY4yVcfpbnlBBeXf5X33WpS/gk1yoKqgYHs4pzNtcKHkQHz2+prAF0YDgmMupLWXLz3 aur56tffqQbkRC9iC0wJQ24CP8q8zuZFT4St9o7rmUJunfGBcszOrxUc0+7dvWvLnzo7P4hhO FlPyBNNgHmDBYn1WtSLCqHfKigwKXf90zCgoPEZxj1lwk2LcMeC9ABRNS4rlcLq3VNF4zpM72 qxyDUzVQxZ8aF/EfS73KPZL9AP4ymMa/0nV6NuQ8qlZ7KKYQiDB62dHz6fiJ/+VRcSbPFBu9k 4+wZsyJgoBcArkN5mN5YViyHVCXDQKpRko+HW9ijX7/LbWdpZyCFs+Fs1WREtXWvoEL2/zail 8d8jrVKb5X4IL/yzMABtm0NXP6WhbqKdiTI2A9qWVXJbbh4Fn+85i7qyHvGz4l6m2CAnEviNo n/GIHsqTEyOoxdIERuLdtd0uCkv8qxW/j8HV+j26Ixo7D8RGHzcSw3qqgCTa54UEaGYb7H5P X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.15.4 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:207450 Archived-At: Cl=C3=A9ment Pit--Claudel writes: > Ok. But how do you refer to the file's contents from elisp, then? > As a string? I didn't have a string in mind. More something like running `cat` in a subprocess maybe? I have a question: AFAIK there is no mean to delay Emacs from accepting output from a process (or is there? sorry if i missed it then). But when we must collect the complete process output when it arrives...and we don't have asynchronity in Emacs etc...of what use is the usage of a delayed structure (stream) in this case at all, and how would it be different from the string case? >> Sure, but with what I mean, the error (inefficiency) would already >> be inthe "I have..." part. > I don't think so :) These sound like reasonable streams to me ^^The > second one in particular is one that I used recently: I wanted to > enumerate all spans with constant text properties, and I didn't need > to keep the whole list of spans in memory. On the other hand, I > didn't want to put the buffer segmentation in each function that > iterated over the spans. Using a stream for that was quite convenient. Here I again would chime in: it's convenient, but not efficient. Search backwards from the end of the buffer, don't enumerate from the beginning if you are only interested in the last n, and start building a stream if you have found the right place to start. > > And should we add `stream'method implementations for building > > streams from files and/or processes to stream.el if such stuff is > > useful? > > I think this would be great. Maybe you want to give it a try? Then we will at least know how useful that would be ;-) > > But I guess I'm beginning to understand: if you have a string (or > > something "similar") consisting of multiple lines (or records or > > whatever), and you are interested in the last n lines, in contrast to a > > buffer, the "go to the end and then n times backwards" approach might > > not even be possible, so there is no alternative to dissect the complete > > string into entities from the start until you hit the end (and throw > > away most of the stuff without accumulation) -- i.e. to the sliding > > window approach implemented by seq-subseq with negative indexes. > > Yes, essentially. In the string case, though, you could copy the > string into a buffer and apply the trick that you mentioned. Well, I learned some time ago that because a buffer is more complicated than a string, most operations are slower for a buffer than for an equivalent string. > But more generally streams are good at producing their contents > lazily, so an implementation that requires forcing the entire stream > and then searching from the end of the resulting list is non-optimal. Yes, but that's was not my argument: I wanted to avoid this stream entirely in such cases. For your use case (of the negative indexes), forcing the entire stream is unavoidable. That's the point I criticize. > In any case, I don't think this should hold the previous patch; we can > always extend the functionality of seq-subseq later. Ok, so I think I'll just install the patch for now. Michael.