[Pharo-project] FIleSystemStreams
All in all the switch to FileSystem is very good. File/Directory manipulation is much improved. (But it does create a problem for library/framework writers, like me, that want to remain compatible with 1.3 and 1.4) However, when trying to actually use FileSystem and when looking at the current users in the image, I see a problem (coming up) with FIleSystemStreams and its subclasses. They should be binary, but they are silently used as character based, either relying on implicit conversions or explicit ones, without proper encoding. This is wrong. Why is there a FileSystemReadStream>>#nextLine ? Why is there no FileSystemReadStream>>#next:into:startingAt: the cornerstone of efficient input ? Why are there FileSystemWriteStream>>#[tab|space|cr|crlf|lf â¦] methods on a binary stream ? Because even with these methods that should not be there, the streams opened by FileSystem cannot be used for simple parsers or renderers, simply because the elementary #next and #nexPut: deal with bytes instead of characters. Some time ago, I did a quick experiment by adding ZnCharacterReadStream and ZnCharacterWriteStream to Zn (in a later version than what is in 2.0, I include a file out) that solve this problem from my perspective (but they don't allow arbitrary #position[:] hacks). Another question is how buffering works (if present at all), since it seems to be hidden in the plugin ? What do the FileSystem hackers, Cami, Sean, et al, think about this situation ? Sven
Hi Sven, On 2012-06-25, at 12:41, Sven Van Caekenberghe wrote:
All in all the switch to FileSystem is very good. File/Directory manipulation is much improved.
(But it does create a problem for library/framework writers, like me, that want to remain compatible with 1.3 and 1.4)
However, when trying to actually use FileSystem and when looking at the current users in the image, I see a problem (coming up) with FIleSystemStreams and its subclasses.
They should be binary, but they are silently used as character based, either relying on implicit conversions or explicit ones, without proper encoding. This is wrong.
Definitely wrong... Anyway for now I will completely remove FileSystemReadStreams since they do not add much value to the system. Even worse, I think with having yet another stream implementation we completely confuse the hell out of people! see: http://code.google.com/p/pharo/issues/detail?id=6132
Why is there a FileSystemReadStream>>#nextLine ? Why is there no FileSystemReadStream>>#next:into:startingAt: the cornerstone of efficient input ? Why are there FileSystemWriteStream>>#[tab|space|cr|crlf|lf â¦] methods on a binary stream ?
obsolete I would, given that the FileSystemReadStream is going to be removed
Because even with these methods that should not be there, the streams opened by FileSystem cannot be used for simple parsers or renderers, simply because the elementary #next and #nexPut: deal with bytes instead of characters.
Some time ago, I did a quick experiment by adding ZnCharacterReadStream and ZnCharacterWriteStream to Zn (in a later version than what is in 2.0, I include a file out) that solve this problem from my perspective (but they don't allow arbitrary #position[:] hacks).
Another question is how buffering works (if present at all), since it seems to be hidden in the plugin ?
What do the FileSystem hackers, Cami, Sean, et al, think about this situation ?
:) I vouch for complete removal of said stream implementations and for now rely on the given FileStream + Co classes. When time comes ( I hope very soon ), we should adapt a decent streaming library which cleans up this stupid mess of byte vs char.
I am confused, Camillo. You want to remove them, OK. But what will #writeStreamDo: and so on then get as argument ? Something new ? Or is there already another solution in the image ? On 25 Jun 2012, at 13:02, Camillo Bruni wrote:
Hi Sven,
On 2012-06-25, at 12:41, Sven Van Caekenberghe wrote:
All in all the switch to FileSystem is very good. File/Directory manipulation is much improved.
(But it does create a problem for library/framework writers, like me, that want to remain compatible with 1.3 and 1.4)
However, when trying to actually use FileSystem and when looking at the current users in the image, I see a problem (coming up) with FIleSystemStreams and its subclasses.
They should be binary, but they are silently used as character based, either relying on implicit conversions or explicit ones, without proper encoding. This is wrong.
Definitely wrong... Anyway for now I will completely remove FileSystemReadStreams since they do not add much value to the system. Even worse, I think with having yet another stream implementation we completely confuse the hell out of people!
see: http://code.google.com/p/pharo/issues/detail?id=6132
Why is there a FileSystemReadStream>>#nextLine ? Why is there no FileSystemReadStream>>#next:into:startingAt: the cornerstone of efficient input ? Why are there FileSystemWriteStream>>#[tab|space|cr|crlf|lf â¦] methods on a binary stream ?
obsolete I would, given that the FileSystemReadStream is going to be removed
Because even with these methods that should not be there, the streams opened by FileSystem cannot be used for simple parsers or renderers, simply because the elementary #next and #nexPut: deal with bytes instead of characters.
Some time ago, I did a quick experiment by adding ZnCharacterReadStream and ZnCharacterWriteStream to Zn (in a later version than what is in 2.0, I include a file out) that solve this problem from my perspective (but they don't allow arbitrary #position[:] hacks).
Another question is how buffering works (if present at all), since it seems to be hidden in the plugin ?
What do the FileSystem hackers, Cami, Sean, et al, think about this situation ?
:) I vouch for complete removal of said stream implementations and for now rely on the given FileStream + Co classes. When time comes ( I hope very soon ), we should adapt a decent streaming library which cleans up this stupid mess of byte vs char.
On 2012-06-25, at 13:56, Sven Van Caekenberghe wrote:
I am confused, Camillo. You want to remove them, OK. But what will #writeStreamDo: and so on then get as argument ?
currently (2.0.158) that returns a MultiByteFileStream
Something new ? Or is there already another solution in the image ?
basically I wanted to make sure we return the same FileDirectory / FileStream does the only problem so far is that the memory filestream still uses the FS streams, which I changed in http://code.google.com/p/pharo/issues/detail?id=6132 That will simply return a WriteStream on the internal ByteArray for now.
On 25 Jun 2012, at 13:02, Camillo Bruni wrote:
Hi Sven,
On 2012-06-25, at 12:41, Sven Van Caekenberghe wrote:
All in all the switch to FileSystem is very good. File/Directory manipulation is much improved.
(But it does create a problem for library/framework writers, like me, that want to remain compatible with 1.3 and 1.4)
However, when trying to actually use FileSystem and when looking at the current users in the image, I see a problem (coming up) with FIleSystemStreams and its subclasses.
They should be binary, but they are silently used as character based, either relying on implicit conversions or explicit ones, without proper encoding. This is wrong.
Definitely wrong... Anyway for now I will completely remove FileSystemReadStreams since they do not add much value to the system. Even worse, I think with having yet another stream implementation we completely confuse the hell out of people!
see: http://code.google.com/p/pharo/issues/detail?id=6132
Why is there a FileSystemReadStream>>#nextLine ? Why is there no FileSystemReadStream>>#next:into:startingAt: the cornerstone of efficient input ? Why are there FileSystemWriteStream>>#[tab|space|cr|crlf|lf â¦] methods on a binary stream ?
obsolete I would, given that the FileSystemReadStream is going to be removed
Because even with these methods that should not be there, the streams opened by FileSystem cannot be used for simple parsers or renderers, simply because the elementary #next and #nexPut: deal with bytes instead of characters.
Some time ago, I did a quick experiment by adding ZnCharacterReadStream and ZnCharacterWriteStream to Zn (in a later version than what is in 2.0, I include a file out) that solve this problem from my perspective (but they don't allow arbitrary #position[:] hacks).
Another question is how buffering works (if present at all), since it seems to be hidden in the plugin ?
What do the FileSystem hackers, Cami, Sean, et al, think about this situation ?
:) I vouch for complete removal of said stream implementations and for now rely on the given FileStream + Co classes. When time comes ( I hope very soon ), we should adapt a decent streaming library which cleans up this stupid mess of byte vs char.
I think I understand: in a way you go backwards to have better compatibility now. I will have to download a later 2.0 image. Thx. On 25 Jun 2012, at 14:09, Camillo Bruni wrote:
On 2012-06-25, at 13:56, Sven Van Caekenberghe wrote:
I am confused, Camillo. You want to remove them, OK. But what will #writeStreamDo: and so on then get as argument ?
currently (2.0.158) that returns a MultiByteFileStream
Something new ? Or is there already another solution in the image ?
basically I wanted to make sure we return the same FileDirectory / FileStream does
the only problem so far is that the memory filestream still uses the FS streams, which I changed in http://code.google.com/p/pharo/issues/detail?id=6132 That will simply return a WriteStream on the internal ByteArray for now.
On 25 Jun 2012, at 13:02, Camillo Bruni wrote:
Hi Sven,
On 2012-06-25, at 12:41, Sven Van Caekenberghe wrote:
All in all the switch to FileSystem is very good. File/Directory manipulation is much improved.
(But it does create a problem for library/framework writers, like me, that want to remain compatible with 1.3 and 1.4)
However, when trying to actually use FileSystem and when looking at the current users in the image, I see a problem (coming up) with FIleSystemStreams and its subclasses.
They should be binary, but they are silently used as character based, either relying on implicit conversions or explicit ones, without proper encoding. This is wrong.
Definitely wrong... Anyway for now I will completely remove FileSystemReadStreams since they do not add much value to the system. Even worse, I think with having yet another stream implementation we completely confuse the hell out of people!
see: http://code.google.com/p/pharo/issues/detail?id=6132
Why is there a FileSystemReadStream>>#nextLine ? Why is there no FileSystemReadStream>>#next:into:startingAt: the cornerstone of efficient input ? Why are there FileSystemWriteStream>>#[tab|space|cr|crlf|lf â¦] methods on a binary stream ?
obsolete I would, given that the FileSystemReadStream is going to be removed
Because even with these methods that should not be there, the streams opened by FileSystem cannot be used for simple parsers or renderers, simply because the elementary #next and #nexPut: deal with bytes instead of characters.
Some time ago, I did a quick experiment by adding ZnCharacterReadStream and ZnCharacterWriteStream to Zn (in a later version than what is in 2.0, I include a file out) that solve this problem from my perspective (but they don't allow arbitrary #position[:] hacks).
Another question is how buffering works (if present at all), since it seems to be hidden in the plugin ?
What do the FileSystem hackers, Cami, Sean, et al, think about this situation ?
:) I vouch for complete removal of said stream implementations and for now rely on the given FileStream + Co classes. When time comes ( I hope very soon ), we should adapt a decent streaming library which cleans up this stupid mess of byte vs char.
On 25.06.2012 14:21, Sven Van Caekenberghe wrote:
I think I understand: in a way you go backwards to have better compatibility now. I will have to download a later 2.0 image. Thx.
For some context, an earlier discussion: http://forum.world.st/Is-the-plan-to-replace-FileStream-by-FSStream-td439484... I'm glad Camillo is making progress! :D Cheers, Henry
On Jun 25, 2012, at 2:48 PM, Henrik Sperre Johansen wrote:
On 25.06.2012 14:21, Sven Van Caekenberghe wrote:
I think I understand: in a way you go backwards to have better compatibility now. I will have to download a later 2.0 image. Thx.
For some context, an earlier discussion: http://forum.world.st/Is-the-plan-to-replace-FileStream-by-FSStream-td439484...
I'm glad Camillo is making progress! :D
Yes but he needs help because he should work on a nativeBoost paper :) Camillo I would like to have the time to read it. Stef
Cheers, Henry
participants (4)
-
Camillo Bruni -
Henrik Sperre Johansen -
Stéphane Ducasse -
Sven Van Caekenberghe