From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?Q?Cl=c3=a9ment_Pit--Claudel?= Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Elpa: Pinpoint semantics of `seq-subseq' for streams Date: Wed, 14 Sep 2016 23:47:47 -0400 Message-ID: <63ebf6ee-d623-e863-42a8-bc802d3df54d@gmail.com> 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="82CVeAQc8Vk30K08hOthKG4Lw8GRqGWmW" X-Trace: blaine.gmane.org 1473911330 27212 195.159.176.226 (15 Sep 2016 03:48:50 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 15 Sep 2016 03:48:50 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 Cc: emacs-devel@gnu.org To: Michael Heerdegen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 15 05:48:47 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 1bkNfD-0005qm-PM for ged-emacs-devel@m.gmane.org; Thu, 15 Sep 2016 05:48:40 +0200 Original-Received: from localhost ([::1]:59678 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bkNfB-00026R-Kr for ged-emacs-devel@m.gmane.org; Wed, 14 Sep 2016 23:48:37 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48111) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bkNep-0001wv-5m for emacs-devel@gnu.org; Wed, 14 Sep 2016 23:48:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bkNeZ-000145-Qw for emacs-devel@gnu.org; Wed, 14 Sep 2016 23:48:14 -0400 Original-Received: from mout.kundenserver.de ([217.72.192.73]:59038) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bkNeZ-00013N-DQ for emacs-devel@gnu.org; Wed, 14 Sep 2016 23:47:59 -0400 Original-Received: from [18.189.118.169] ([18.189.118.169]) by mrelayeu.kundenserver.de (mreue101) with ESMTPSA (Nemesis) id 0LcPtW-1bKi4G1FA6-00juRE; Thu, 15 Sep 2016 05:47:58 +0200 In-Reply-To: <87zina568j.fsf@web.de> X-Provags-ID: V03:K0:rD9X0pbH6w6XcbTjz5EoCp3Lnw/fvGOXmY4SBTPQ6IfAGX0reea L6RzrTUyyqZjoghiZxU46JA/+igQWqc/dGzt4MxwLpwwjMEZ063Qltiir6Xiv9SNCWmIj+j WxXjB3E+4IA/kr3UcQP87TmGtDmwQE7PMklWoQSGdM7ZLJlirz2sUSsXfRzhzKXR0mEePGX mpNllmimP4GSqEVn732ug== X-UI-Out-Filterresults: notjunk:1;V01:K0:g+/b3Py56pE=:dTTI5dr82HnLfCYBR/hNPa 3gyGK1D09+YkDV9eHnqDFBnvT99lyhwefb82L6H9vsnkIpsFPVB3z21UVpzBZF5Iqo36B/OVB RTtOz2M964XSHMVWmnDPPWLP1kfi5eqIZHrA0eygIBAcYcaaP3dvtlAkFu1BXcmOAv7CamGNS n61dfc6iy5CzSJynYf+X6HIR/zh4XybloiH8/F6sDVHcJf4LoHolU9jxPsSZeCVVpjTxHJ6Ba Yyx8cFTZjVsSoDdUjL9K2P3d7jfxss6NtSh4mfcIvO//gvkzJDWCNttRloAgxANS1IXTCoevW w+Ke8965kN+3ICngMma7hdY1NilEGkHf1WjnkCApVOSHiddv+HYCDqw+k4L7F4kVdu6M4S5tL rs8YoZJZYEd2n158WWAETJtdjvhu506NyZ5Jsr9IFIBhmv8ZCeF7o93A/mR3OPWxdVxPwLzDy +olxAjsqMg1XClZCt5WOa3LkaKOW7Nda2b8wK9je/HCgx5MWOSCq0v1bFfByKoeA1SfJp1tRs vcRwYuLaJ0WTvYKNXSz9D+hMJaP3BqDLAgKbDd7VkIXM3qsC3xODtxrIn07Ar64Y4KsnKFyy0 iCrLYOVv4lOQU8dn8zqoWpOH9AXrB4oFGOA8JQyMBFVXUj+2ruZhvT5Z1PrWe8QaN8tSmttv6 uUH/rUVp/LaD1/Hzxx+b2R/Mn22mGOQ/rb7Tgu5UM2FGrPoYF/HrF2g67s0tOxn1lIDw= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 217.72.192.73 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:207439 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --82CVeAQc8Vk30K08hOthKG4Lw8GRqGWmW Content-Type: multipart/mixed; boundary="v1FIPuMibHer8Lqhxlsa6OsvLBKKlLA3D"; protected-headers="v1" From: =?UTF-8?Q?Cl=c3=a9ment_Pit--Claudel?= To: Michael Heerdegen Cc: emacs-devel@gnu.org Message-ID: <63ebf6ee-d623-e863-42a8-bc802d3df54d@gmail.com> Subject: Re: [PATCH] Elpa: Pinpoint semantics of `seq-subseq' for streams 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> In-Reply-To: <87zina568j.fsf@web.de> --v1FIPuMibHer8Lqhxlsa6OsvLBKKlLA3D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2016-09-14 20:58, Michael Heerdegen wrote: > Cl=C3=A9ment Pit--Claudel writes: >=20 >> Ok, so we agree on this part :) Note that it may be nonsense to load >> the file into a buffer, too; holding the full file in a list is more >> or less as bad as holding the full file in a buffer. If the file is >> large, that's very inefficient. >=20 > 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 s= ubprocess maybe? >>> Do you have an example where this would be useful for streams in >>> Emacs, different from the "last n lines" one (see my comment about >>> that below). >> >> Sure: if I have a stream of numbers, I may want to calculate the >> average of the last n numbers. >=20 >> Or if I have a stream of non-overlapping buffer spans, I may want to >> remove just the last one. >=20 > Sure, but with what I mean, the error (inefficiency) would already be i= n > the "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 enu= merate 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= =2E Using a stream for that was quite convenient. >> To continue on the `last n lines' example, I may be interested in only= >> the last n lines of output of a running process (think dmesg | tail). >=20 > As a string, right? Or in which way do you refer to the process output= > via streams? Can you please explain in short how you are using streams= > in your use case? (Sorry, I'm more a mathematician than a programmer, > so it's not your fault if I miss the point). I don't have a concrete use case :) This thread was born just from my loo= king at the original patch. I use streams a lot more in other languages = than I do in Emacs Lisp, at least for now. And I agree that there's no h= urry in implementing this feature, either (we could add it later). > 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. The comment at the top of stream.el mention= s it: ;; streams could be created from any sequential input data: ;; - sequences, making operation on them lazy ;; - a set of 2 forms (first and rest), making it easy to represent infin= ite sequences ;; - buffers (by character) ;; - buffers (by line) ;; - buffers (by page) ;; - IO streams ;; - orgmode table cells ;; - ... > 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 complet= e > 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. But more generally= streams are good at producing their contents lazily, so an implementatio= n that requires forcing the entire stream and then searching from the end= of the resulting list is non-optimal. Of course in some cases you can ju= st skip the production of a stream entirely; but not in all cases. In any case, I don't think this should hold the previous patch; we can al= ways extend the functionality of seq-subseq later. Cl=C3=A9ment. --v1FIPuMibHer8Lqhxlsa6OsvLBKKlLA3D-- --82CVeAQc8Vk30K08hOthKG4Lw8GRqGWmW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJX2hnjAAoJEPqg+cTm90wjChEP/itRq+S1MWd/fQg9NEqzjG8j uSpicqREo4gNiVqPyi1okbwj0yk54IRRDDuo0vYX+rZxRm/MW66iqijpQ3XSZJSc 1QJL+cYmD9+QyhORIMWdEFJQ/wiIYwHuCiD085kxoWrvKh5tJznYPbTlyZxlhenz OA6OgTojas9Id7sNI9raYDMJHdwIWgPkguQ7rzKgRXciQEG86UzGq16AgFgjwIOU 05U61aMShIrv3Of+rb1bbsDh3U26YhOC8NNsIOnRJYcDVkKhKYxMq45JdeL2obG1 RKZsnA9AeXmuhuxSM9iwTN8W+uQHJNte7MRczBAFAFUCQmIHeRjLJR2Wa+pj5DuU K44kYPS8nHiPXnmMapB6bwXDopFHkDZYqehFNHy3mcOXiiNlLITHi3NS4JLHMgwm V55LHHFps2ZTvRyKkKbEi0YEAd3K/psUQF0KeUdPUYVsIOWAjdJIeAJ7Dr1UIHBI Lebk1h7cmuSsjGyx4QXarYTYLQ551ZbTzQmB8PIyJODrlw6kdhsWbi+35iG63hY5 SqgBSpAP0xgyF/7otgp9c7anRep7wddRiO+qX8OsmH9UaULkTuOy2+iqaOZzTka6 3e25ZL40piokel5u+lZFMuX7+web76FNzA9QMF2e2OkroiwaaeFC8O6VwwcaFZMZ nYC76aOgMD4n2fwVmXjc =4y+g -----END PGP SIGNATURE----- --82CVeAQc8Vk30K08hOthKG4Lw8GRqGWmW--