Smalltalk › Pharo › Pharo Smalltalk Developers

could we discuss 19006

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

stepharo

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

monty-3

Re: could we discuss 19006

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 <[hidden email]>
> To: "Pharo Development List" <[hidden email]>
> 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

Re: could we discuss 19006

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 <[hidden email]>
>> To: "Pharo Development List" <[hidden email]>
>> 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
>>
>>
>>
>>
>>
>

Sean P. DeNigris

Re: could we discuss 19006

Administrator

In reply to this post by stepharo

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

Guillermo Polito

Re: could we discuss 19006

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.
>