GNU bug report logs -
#30626
26.0.91; Crash when traversing a `stream-of-directory-files'
Previous Next
Reported by: Michael Heerdegen <michael_heerdegen <at> web.de>
Date: Tue, 27 Feb 2018 09:23:01 UTC
Severity: normal
Tags: fixed, patch
Found in version 26.0.91
Done: Noam Postavsky <npostavs <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
Noam Postavsky <npostavs <at> gmail.com> writes:
> Coming back to this again. I think I got lost in the weeds of the
> byte-code function objects before. The core problem is that streams
> are not exactly encoded like the above, because even after forcing it
> you don't have just a plain SECOND-VALUE stored in the stream. The
> original FUNCTION-TO-PRODUCE-MORE-REST-OF-LIST stays around and keeps
> referencing all the code and all the following elements. So a
> possible solution is change the stream to get rid of the lambda part
> and just leave the computed value after it's forced. With the
> following patch (stream-flush (stream-range 1 1000000)) succeeds:
>
> [Patch...]
Works for me, and it makes sense. As a test case I recompiled
el-search.el (it uses streams for several things) with your patch
applied to stream.el, and it worked well.
> Some additional things that I thought of changing, but I didn't yet:
> - stream--identifier vs just using '--stream-- directly, I don't see
> what's the benefit of indirection here.
A matter of taste I guess.
> - stream-make should use cons instead of list (or maybe a struct?).
I think cons would be ok. Would a struct make things slower?
> - stream-empty should just be a constant.
Dunno if there are cases where this would be problematic, but I guess we
could do this as well.
Anyway, thanks for looking into this again, I like your solution. Maybe
Nicolas can also chime in.
Michael.
This bug report was last modified 6 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.