GNU bug report logs - #37888
27.0.50; Streams and errors in element generation

Previous Next

Package: emacs;

Reported by: Michael Heerdegen <michael_heerdegen <at> web.de>

Date: Wed, 23 Oct 2019 14:28:01 UTC

Severity: normal

Found in version 27.0.50

Done: Michael Heerdegen <michael_heerdegen <at> web.de>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 37888 in the body.
You can then email your comments to 37888 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#37888; Package emacs. (Wed, 23 Oct 2019 14:28:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Heerdegen <michael_heerdegen <at> web.de>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Wed, 23 Oct 2019 14:28:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: bug-gnu-emacs <at> gnu.org
Cc: Nicolas Petton <nicolas <at> petton.fr>
Subject: 27.0.50; Streams and errors in element generation
Date: Wed, 23 Oct 2019 16:27:36 +0200
Hi,

consider this case (it appeared to me in real life):

--8<---------------cut here---------------start------------->8---
(defun test-stream (n)
  (stream-cons n (if (< n 0) (error "test") (test-stream (1- n)))))

(setq my-stream (test-stream 10))

(condition-case nil (seq-length my-stream)
  (error (message "Hmm, didn't work so well")))
--8<---------------cut here---------------end--------------->8---

Now, what happened to `my-stream' after evaluating this?  If you try to
use it, you get a quite confusing error:

(seq-length my-stream)

|-- stream--force: Wrong type argument: streamp, (((n . -1) t) nil ...)

i.e. the stream is broken.  I wonder if we could improve this case.  I'm
not sure how, however.  Should referencing the element whose generation
caused the error raise the same error again, or a standardized kind of
error?  Should the whole stream be invalidated in some way?  FWIW, in my
use case I expected the stream to raise the same error again.  Would it
be reasonable to make the stream just retry to calculate the problematic
element?


TIA,

Michael.


In GNU Emacs 27.0.50 (build 27, x86_64-pc-linux-gnu, GTK+ Version 3.24.12)
 of 2019-10-23 built on drachen
Repository revision: 39ba44f18445c7759de5ac91ce25e53123c2abeb
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12004000
System Description: Debian GNU/Linux bullseye/sid





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#37888; Package emacs. (Wed, 23 Oct 2019 15:00:02 GMT) Full text and rfc822 format available.

Message #8 received at 37888 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: 37888 <at> debbugs.gnu.org
Cc: Nicolas Petton <nicolas <at> petton.fr>,
 Noam Postavsky <npostavs <at> users.sourceforge.net>
Subject: Re: bug#37888: 27.0.50; Streams and errors in element generation
Date: Wed, 23 Oct 2019 16:58:48 +0200
[Message part 1 (text/plain, inline)]
Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> (defun test-stream (n)
>   (stream-cons n (if (< n 0) (error "test") (test-stream (1- n)))))
>
> (setq my-stream (test-stream 10))
>
> (condition-case nil (seq-length my-stream)
>   (error (message "Hmm, didn't work so well")))
>
> Now, what happened to `my-stream' after evaluating this?  If you try to
> use it, you get a quite confusing error:
>
> (seq-length my-stream)
>
> |-- stream--force: Wrong type argument: streamp, (((n . -1) t) nil ...)

Would something like this make sense (Noam)?

[0001-WIP-stream-Fix-Bug-37888.patch (text/x-diff, inline)]
From 4c778f26ff8d56d0e7018305aa3d46caa2f9fb38 Mon Sep 17 00:00:00 2001
From: Michael Heerdegen <michael_heerdegen <at> web.de>
Date: Wed, 23 Oct 2019 16:55:01 +0200
Subject: [PATCH] WIP [stream] Fix Bug#37888

---
 packages/stream/stream.el | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/packages/stream/stream.el b/packages/stream/stream.el
index 9f73e8b861..d401fb7e3c 100644
--- a/packages/stream/stream.el
+++ b/packages/stream/stream.el
@@ -86,8 +86,8 @@ That value is the one passed to `stream-make'."
    ((eq (car-safe stream) stream--evald-identifier)
     (cdr stream))
    ((eq (car-safe stream) stream--fresh-identifier)
-    (setf (car stream) stream--evald-identifier)
-    (setf (cdr stream) (funcall (cdr stream))))
+    (prog1 (setf (cdr stream) (funcall (cdr stream)))
+      (setf (car stream) stream--evald-identifier)))
    (t (signal 'wrong-type-argument (list 'streamp stream)))))

 (defmacro stream-cons (first rest)
--
2.23.0

[Message part 3 (text/plain, inline)]

Michael.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#37888; Package emacs. (Thu, 24 Oct 2019 11:39:04 GMT) Full text and rfc822 format available.

Message #11 received at 37888 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: 37888 <at> debbugs.gnu.org
Cc: Nicolas Petton <nicolas <at> petton.fr>
Subject: Re: bug#37888: 27.0.50; Streams and errors in element generation
Date: Thu, 24 Oct 2019 13:38:27 +0200
Hello again,

Btw, AFAIU this problem pertains any form of nonlocal exit, not only
errors.  Using nonlocal exits in stream element generation (e.g. via
`while-no-input') is a common use case for me.  My suggested should fix
this.


Regards,

Michael.

> consider this case (it appeared to me in real life):
>
> (defun test-stream (n)
>   (stream-cons n (if (< n 0) (error "test") (test-stream (1- n)))))
>
> (setq my-stream (test-stream 10))
>
> (condition-case nil (seq-length my-stream)
>   (error (message "Hmm, didn't work so well")))
>
> Now, what happened to `my-stream' after evaluating this?  If you try to
> use it, you get a quite confusing error:
>
> (seq-length my-stream)
>
> |-- stream--force: Wrong type argument: streamp, (((n . -1) t) nil ...)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#37888; Package emacs. (Fri, 13 Dec 2019 13:11:02 GMT) Full text and rfc822 format available.

Message #14 received at 37888 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: Nicolas Petton <nicolas <at> petton.fr>, 37888 <at> debbugs.gnu.org,
 Noam Postavsky <npostavs <at> users.sourceforge.net>
Subject: Re: bug#37888: 27.0.50; Streams and errors in element generation
Date: Fri, 13 Dec 2019 08:10:13 -0500
Michael Heerdegen <michael_heerdegen <at> web.de> writes:
>
> Would something like this make sense (Noam)?

>     ((eq (car-safe stream) stream--fresh-identifier)
> -    (setf (car stream) stream--evald-identifier)
> -    (setf (cdr stream) (funcall (cdr stream))))
> +    (prog1 (setf (cdr stream) (funcall (cdr stream)))
> +      (setf (car stream) stream--evald-identifier)))

Right, only mark the stream element as evaluated after we (successfully!)
evaluate it.  Makes sense to me.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#37888; Package emacs. (Sun, 12 Jan 2020 07:21:02 GMT) Full text and rfc822 format available.

Message #17 received at 37888 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Nicolas Petton <nicolas <at> petton.fr>
Cc: 37888 <at> debbugs.gnu.org, Noam Postavsky <npostavs <at> gmail.com>
Subject: Re: bug#37888: 27.0.50; Streams and errors in element generation
Date: Sun, 12 Jan 2020 08:20:19 +0100
Noam Postavsky <npostavs <at> gmail.com> writes:

> > Would something like this make sense (Noam)?
>
> >     ((eq (car-safe stream) stream--fresh-identifier)
> > -    (setf (car stream) stream--evald-identifier)
> > -    (setf (cdr stream) (funcall (cdr stream))))
> > +    (prog1 (setf (cdr stream) (funcall (cdr stream)))
> > +      (setf (car stream) stream--evald-identifier)))
>
> Right, only mark the stream element as evaluated after we (successfully!)
> evaluate it.  Makes sense to me.

Installed.

@Nicolas: Would you mind when I also bump the version of stream to 2.2.5
and update the copyright years of the files in the stream package?

TIA,

Michael.




Reply sent to Michael Heerdegen <michael_heerdegen <at> web.de>:
You have taken responsibility. (Sat, 08 Feb 2020 17:22:02 GMT) Full text and rfc822 format available.

Notification sent to Michael Heerdegen <michael_heerdegen <at> web.de>:
bug acknowledged by developer. (Sat, 08 Feb 2020 17:22:02 GMT) Full text and rfc822 format available.

Message #22 received at 37888-done <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Nicolas Petton <nicolas <at> petton.fr>
Cc: Noam Postavsky <npostavs <at> gmail.com>, 37888-done <at> debbugs.gnu.org
Subject: Re: bug#37888: 27.0.50; Streams and errors in element generation
Date: Sat, 08 Feb 2020 18:21:43 +0100
Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> Installed.
>
> @Nicolas: Would you mind when I also bump the version of stream to
> 2.2.5 and update the copyright years of the files in the stream
> package?

I've done this now.  We are done and I'm closing this bug.


Thanks,

Michael.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sun, 08 Mar 2020 11:24:06 GMT) Full text and rfc822 format available.

This bug report was last modified 4 years and 44 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.