1. Ok it seems clear now. I was really confused by all the different
explanations. So
r.on('readable', function(){
var chunk = null
while( (chunk = r.read()) != null ) consume(chunk)
})
should work just fine in usual case, right?
2. it's ok,
3. i'm with you here. if you have more than one consumers, then you need a
custom forking stream, or go with the old way, pause+attachattach+resume.
whatever.
4. i was expecting that.
Thank you for clarifications on that topic.
Am Dienstag, 7. Mai 2013 20:55:07 UTC+2 schrieb Isaac Schlueter:
>
> As of current v0.10:
>
> 1. The first 'readable' event listener will *definitely* get called,
> whether data has been pushed into the read queue or not. It will
> trigger a read(0) if there is no data in the queue, and will emit
> immediately if there is data in the queue. The code for this is quite
> clear, actually:
>
> https://github.com/joyent/node/blob/76cbd03/lib/_stream_readable.js#L668-L680
>
> 2. Any subsequent 'readable' event listeners that are added will not
> have any magic effects.
>
> 3. The only reason to have to call read() before adding your readable
> listener is if the stream may have been partly (but not entirely)
> consumed, and a different 'readable' event listener already added.
> (In which case, are you sure it's ok for you to be consuming this
> stream? Because it sounds like it might be someone else's stream, and
> not yours. Maybe rethink your approach?)
>
> 4. Yes, you can use `r.on('data', function(chunk) { ... })`
> foreverever. It's a part of the API. The new API is a superset of
> the old API. Nothing in the stream API has been deprecated.
>
> Does that clarify things? It seems to me like everything you're
> wishing for is actually how it already works.
>
>
>
> On Tue, May 7, 2013 at 1:00 AM, greelgorke <greel...@gmail.com<javascript:>>
> wrote:
> > so the official ways to read a readable are:
> >
> > 1. Old Style:
> > r.on('data', function(data){...})
> > r.on('end', function(data){...})
> >
> > works and will be supported (foreverever?)
> >
> > 2. The new, kindofCbutnotreally, Style:
> > var existingChunk = rs.read();
> > //do something with existingChunk
> > rs.on('readable', function () {
> > var chunk = rs.read();
> > // do something with chunk
> > });
> >
> > this feels very uncomfortable to me. you can poll all the time,
> 'readable'
> > event looks to me like an invitation for calling read, but it's not in
> the
> > first place, because it's emited only when you called read at least once
> and
> > only if it returned null, right? looks like to much 'ifs' on that for
> me.
> > looks like bad api design here to me. why is this designed this way?
> more
> > intuitive would be:
> > - attach to 'readable'
> > - if there is data already, the listener is called as soon as it's
> attached
> > ('newListener' event right?).
> > - in the listener you can/should consume via .read as long as result
> isn't
> > null (better undefined, suits some edge cases in object mode better.)
> > - end event emited, when stream is done.
> >
> > 3. The new old kinky way via piping to a consumer stream:
> > r.pipe(new CustomWritable())
> >
> > this looks pretty to me and hides away the gotchas of 2. but it has
> > indirection of dataflow control, wich is only handled by calling the
> > callback in _write and tweekin waterMarks. so if you want better control
> > i.E. unshifting chunks, then you probably have to stick with 2. right?
> >
> > Trying to resolve my new confusion about readable.
> >
> > Greet
> >
> > greelgorke
> >
> >
> >
> > Am Dienstag, 7. Mai 2013 03:49:57 UTC+2 schrieb James Hartig:
> >>
> >> Just to update this thread for future readers...
> >> Talked to Isaac on Twitter and he had said that "readable" will be
> fired
> >> on first chunk after making a Readable Stream. But before you make the
> >> "readable" listener, you can call read() just to be sure there isn't
> already
> >> data.
> >>
> >> So:
> >> var existingChunk = rs.read();
> >> //do something with existingChunk
> >> rs.on('readable', function () {
> >> var chunk = rs.read();
> >> // do something with chunk
> >> });
> >>
> >> On Monday, May 6, 2013 5:45:09 PM UTC-4, James Hartig wrote:
> >>>
> >>> > The 'readable' event fires as soon as *any* data is added to the
> >>> > internal buffer, but only if a previous read() call returned null.
> If
> >>> > you never got a null read, then you haven't exhausted the buffer, so
> >>> > there's no need to emit 'readable', since presumably you already
> know
> >>> > it's readable.
> >>>
> >>> Is needReadable set to true when you create the socket or do I have to
> >>> call read() right after making the socket?
> >>> I looked through the ReadableStream code and couldn't find a path that
> >>> sets it to true. I'm using new fs.ReadStream(null, {fd: 4}).
> >>>
> >>> On Monday, May 6, 2013 4:59:39 PM UTC-4, Isaac Schlueter wrote:
> >>>>
> >>>> > Basically the loop is because the "readable" event doesn't fire
> until
> >>>> > the buffer is filled up and if you want to get data immediately,
> then you
> >>>> > can't rely on "readable"?
> >>>>
> >>>> The 'readable' event fires as soon as *any* data is added to the
> >>>> internal buffer, but only if a previous read() call returned null.
> If
> >>>> you never got a null read, then you haven't exhausted the buffer, so
> >>>> there's no need to emit 'readable', since presumably you already know
> >>>> it's readable.
> >>>>
> >>>> > It would seem (from the docs) that read() without any limit returns
> >>>> > the whole buffer, so how would there be more data the next time you
> call it?
> >>>>
> >>>> The length of the returned data from read() is
> implementation-defined.
> >>>> In objectMode streams, it'll always be one "thing", but in
> >>>> binary/string streams it can be any amount of data.
> >>>>
> >>>> If you're using the stream.Readable base class, then yes, read() will
> >>>> always return the full buffer, *unless* you're piping, in which case,
> >>>> it returns the top chunk in the list, so as to avoid an unnecessary
> >>>> copy in the case where there's more than one chunk ready.
> >>>>
> >>>>
> >>>> On Mon, May 6, 2013 at 11:10 AM, James Hartig <faste...@gmail.com>
> >>>> wrote:
> >>>> > Sorry to be late to the party...
> >>>> >
> >>>> > Basically the loop is because the "readable" event doesn't fire
> until
> >>>> > the
> >>>> > buffer is filled up and if you want to get data immediately, then
> you
> >>>> > can't
> >>>> > rely on "readable"?
> >>>> >
> >>>> > It would seem (from the docs) that read() without any limit returns
> >>>> > the
> >>>> > whole buffer, so how would there be more data the next time you
> call
> >>>> > it?
> >>>> >
> >>>> >
> >>>> > On Sunday, April 14, 2013 4:57:49 PM UTC-4, Jorge wrote:
> >>>> >>
> >>>> >> On 30/03/2013, at 00:56, Isaac Schlueter wrote:
> >>>> >>
> >>>> >> > ```javascript
> >>>> >> > var chunk;
> >>>> >> > while (null !== (chunk = rs.read())) {
> >>>> >> > doSomething(chunk);
> >>>> >> > }
> >>>> >> > ```
> >>>> >>
> >>>> >> I use to write code like that too but it might break it seems,
> look:
> >>>> >>
> >>>> >> <https://bugs.webkit.org/show_bug.cgi?id=114594>
> >>>> >>
> >>>> >> this works:
> >>>> >>
> >>>> >> function works (s) {
> >>>> >> var pos;
> >>>> >> var n= 0;
> >>>> >> var t;
> >>>> >> var r= "";
> >>>> >> var o=
> >>>> >> "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ";
> >>>> >> var p=
> >>>> >> "5678901234nopqrstuvwxyzabcdefghijklmNOPQRSTUVWXYZABCDEFGHIJKLM";
> >>>> >> while (n < s.length) {
> >>>> >> t= s[n];
> >>>> >> pos= o.indexOf(t);
> >>>> >> r+= (pos >= 0) ? p[pos] : t;
> >>>> >> n++;
> >>>> >> }
> >>>> >> return r;
> >>>> >> }
> >>>> >>
> >>>> >> this doesn't:
> >>>> >>
> >>>> >> function fails (s) {
> >>>> >> var pos, n = 0,
> >>>> >> t, r = "",
> >>>> >> o =
> >>>> >> "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ",
> >>>> >> p =
> >>>> >> "5678901234nopqrstuvwxyzabcdefghijklmNOPQRSTUVWXYZABCDEFGHIJKLM";
> >>>> >> while (n < s.length) {
> >>>> >> r += ((pos = o.indexOf(t = s[n++])) >= 0) ? p[pos] : t;
> >>>> >> }
> >>>> >> return r;
> >>>> >> }
> >>>> >>
> >>>> >> --
> >>>> >> ( Jorge )();
> >>>> >
> >>>> > --
> >>>> > --
> >>>> > Job Board: http://jobs.nodejs.org/
> >>>> > Posting guidelines:
> >>>> > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> >>>> > You received this message because you are subscribed to the Google
> >>>> > Groups "nodejs" group.
> >>>> > To post to this group, send email to nod...@googlegroups.com
> >>>> > To unsubscribe from this group, send email to
> >>>> > nodejs+un...@googlegroups.com
> >>>> > For more options, visit this group at
> >>>> > http://groups.google.com/group/nodejs?hl=en?hl=en
> >>>> >
> >>>> > ---
> >>>> > You received this message because you are subscribed to the Google
> >>>> > Groups
> >>>> > "nodejs" group.
> >>>> > To unsubscribe from this group and stop receiving emails from it,
> send
> >>>> > an
> >>>> > email to nodejs+un...@googlegroups.com.
> >>>> > For more options, visit https://groups.google.com/groups/opt_out.
> >>>> >
> >>>> >
>
--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
