lukechilds/node - node - Gitea: Git with a cup of tea

Author	SHA1	Message	Date
Julian Gruber	f91b047891	stream: make setEncoding chainable	11 years ago
isaacs	3537b57f3e	test: No need for kicking in streams2 test This was necessary when we weren't auto-starting when a 'readable' listener is added.	12 years ago
Gil Pedersen	e8f80bf479	stream: Never call decoder.end() multiple times Updated version that does what it says without assigning state.decoder.	12 years ago
isaacs	6399839c39	Revert "stream: Never call decoder.end() multiple times" This reverts commit `615d809ac6`.	12 years ago
Gil Pedersen	615d809ac6	stream: Never call decoder.end() multiple times Fixes decoder.end() being called on every push(null). As the tls module does this, corrupt stream data could potentially be added to the end.	12 years ago
isaacs	b0f6789a78	stream: Remove bufferSize option Now that highWaterMark increases when there are large reads, this greatly reduces the number of calls necessary to _read(size), assuming that _read actually respects the size argument.	12 years ago
isaacs	88644eaa2d	stream: There is no _read cb, there is only push This makes it so that `stream.push(chunk)` is the only way to signal the end of reading, removing the confusing disparity between the callback-style _read method, and the fact that most real-world streams do not have a 1:1 corollation between the "please give me data" event, and the actual arrival of a chunk of data. It is still possible, of course, to implement a `CallbackReadable` on top of this. Simply provide a method like this as the callback: function readCallback(er, chunk) { if (er) stream.emit('error', er); else stream.push(chunk); } However, only fs streams actually would behave in this way, so it makes not a lot of sense to make TCP, TLS, HTTP, and all the rest have to bend into this uncomfortable paradigm.	12 years ago
Raynos	444bbd4fa7	streams: Support objects other than Buffers We detect for non-string and non-buffer values in onread and turn the stream into an "objectMode" stream. If we are in "objectMode" mode then howMuchToRead will always return 1, state.length will always have 1 appended to it when there is a new item and fromList always takes the first value from the list. This means that for object streams, the n in read(n) is ignored and read() will always return a single value Fixed a bug with unpipe where the pipe would break because the flowing state was not reset to false. Fixed a bug with sync cb(null, null) in _read which would forget to end the readable stream	12 years ago
isaacs	9b1b85490b	streams2: Tests of new interfaces	12 years ago