could we discuss 19006
Hi guys The change 19006 is adding a lot of streams AbstractBinaryStream and I do not really get the vision. Note that I'm not against. I just want to understand. Do we add these and remove some old ones? What is sync? Ideally I would like to throw away all the streams and use xtreams instead. So thanks for your time explaining us the idea. Stef
It doesn't add any new streams or other classes besides a test case. AbstractBinaryStream was already there. It just adds #sync to the FileSysteam API and legacy file streams, recategorizes many stream methods to make them more consistent, fixes #flush to fail when the primitive does (the correct behavior-read the comment!), and adds tests for WriteStream and LimitedWriteStream. The #sync addition on Unix uses ffsync(), while #flush uses fflush(). Why is #sync needed if we have #flush? From `man fflush`:
Note that fflush() flushes only the user-space buffers provided by the C library. To ensure that the data is physically stored on disk the kernel buffers must be flushed too, for example, with sync(2) or fsync(2).
(but on Windows they're implemented identically)
Sent: Saturday, September 03, 2016 at 3:34 PM From: stepharo <stepharo@free.fr> To: "Pharo Development List" <pharo-dev@lists.pharo.org> Subject: [Pharo-dev] could we discuss 19006
Hi guys
The change 19006 is adding a lot of streams AbstractBinaryStream and I do not really get the vision.
Note that I'm not against. I just want to understand.
Do we add these and remove some old ones?
What is sync?
Ideally I would like to throw away all the streams and use xtreams instead.
So thanks for your time explaining us the idea.
Stef
thanks. I had problems to see the code when merging. I will integrate it today if the system lets me doing it :). Le 4/9/16 à 02:19, monty a écrit :
It doesn't add any new streams or other classes besides a test case. AbstractBinaryStream was already there.
It just adds #sync to the FileSysteam API and legacy file streams, recategorizes many stream methods to make them more consistent, fixes #flush to fail when the primitive does (the correct behavior-read the comment!), and adds tests for WriteStream and LimitedWriteStream.
The #sync addition on Unix uses ffsync(), while #flush uses fflush(). Why is #sync needed if we have #flush? From `man fflush`:
Note that fflush() flushes only the user-space buffers provided by the C library. To ensure that the data is physically stored on disk the kernel buffers must be flushed too, for example, with sync(2) or fsync(2).
(but on Windows they're implemented identically)
Sent: Saturday, September 03, 2016 at 3:34 PM From: stepharo <stepharo@free.fr> To: "Pharo Development List" <pharo-dev@lists.pharo.org> Subject: [Pharo-dev] could we discuss 19006
Hi guys
The change 19006 is adding a lot of streams AbstractBinaryStream and I do not really get the vision.
Note that I'm not against. I just want to understand.
Do we add these and remove some old ones?
What is sync?
Ideally I would like to throw away all the streams and use xtreams instead.
So thanks for your time explaining us the idea.
Stef
stepharo wrote
Note that I'm not against. I just want to understand.
Me too. I looked over the issue, and it seemed one would already have to understand the issue very well. I wished there was more explanation about the problem and why the solution was a good one. In the end, I shrugged my shoulders and just had to trust the author. ----- Cheers, Sean -- View this message in context: http://forum.world.st/could-we-discuss-19006-tp4913965p4914079.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Some aside-answers on the issue: The AbstractFileStream and its two childs are not "a stream library implementation" but low level streams that implement the primitives to talk to files. And their purpose is to provide a clean implementation of binary file streams that implement no buffering, no encoding, no text conversion. And so clean the usage of MultiByteCharacterMaybeTextMaybeBufferedMaybeBinaryMaybeReadMaybeWrite streams. Buffering, encoding, convertion to text and other facilities can be obtained by using the already provided Zn* facilities: - ZnBufferedRead/WriteStream - ZnEncodedStream and so on. Nice thing: the Zn* thingys are well tested, documented, and already used for socket streams. We can reuse them for files for free :) Guille -------- Original Message --------
stepharo wrote
Note that I'm not against. I just want to understand. Me too. I looked over the issue, and it seemed one would already have to understand the issue very well. I wished there was more explanation about the problem and why the solution was a good one. In the end, I shrugged my shoulders and just had to trust the author.
----- Cheers, Sean -- View this message in context: http://forum.world.st/could-we-discuss-19006-tp4913965p4914079.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
participants (4)
-
Guille Polito -
monty -
Sean P. DeNigris -
stepharo