Oct. 5, 2017
7:37 a.m.
On Wed, Oct 4, 2017 at 10:12 PM, Stephane Ducasse <stepharo.self@gmail.com>
wrote:
> Hi sven
>
> I wonder how we can make progress on this front. Because we should move on.
> I'm fed up to get all this crap of the old stream around.
> Could not we just keep positionable stream and start to get rest nice?
>
Could we point it as a sprint task?
> Stef
>
> On Tue, Oct 3, 2017 at 4:22 PM, Sven Van Caekenberghe <sven@stfx.eu>
> wrote:
> >
> >
> >> On 3 Oct 2017, at 10:53, Guillermo Polito <guillermopolito@gmail.com>
> wrote:
> >>
> >> Yes, in my todo, but changing FileReference like that will break a lot
> of backwards compatibility :)
> >
> > Yes it will.
> >
> > I have said this before: the problem is that the current stream API is
> much too wide, we need to trim it to something closer to what a stream is
> (and not assume that a stream always lives on top of a collection).
> >
> > We have compassable streams now, they work well. But they cannot
> implement the full API (since they are not streaming over collections). The
> biggest issue are the positioning message (like #skip: and #position:)
> which assume you known where you are and can move around at will, which is
> not possible for a real, indefinite stream.
> >
> >> On Mon, Oct 2, 2017 at 10:22 AM, Stephane Ducasse <
> stepharo.self@gmail.com> wrote:
> >> Yes this is why we should continue to clean and remove cruft. Now I
> >> remember that guille did that for File.
> >>
> >> Stef
> >>
> >> On Mon, Oct 2, 2017 at 3:20 PM, Sven Van Caekenberghe <sven@stfx.eu>
> wrote:
> >> > If you do
> >> >
> >> > (File named: '/tmp/lines.txt') readStream[Do:]
> >> >
> >> > you seem to get a binary stream (this is the new implementation I
> guess), when you go via FileReference you get a character stream (but that
> are old ones).
> >> >
> >> > I know, very confusing. We're always in the midst of transitions.
> >> >
> >> >> On 2 Oct 2017, at 15:17, Stephane Ducasse <stepharo.self@gmail.com>
> wrote:
> >> >>
> >> >> Sven I do not see the binary stream. Is it ZnCharacterReadStream?
> >> >>
> >> >> Stef
> >> >>
> >> >> On Mon, Oct 2, 2017 at 1:22 PM, Sven Van Caekenberghe <sven@stfx.eu>
> wrote:
> >> >>> Hi,
> >> >>>
> >> >>>> On 2 Oct 2017, at 13:07, Dirk Olmes <dirk@xanthippe.ping.de>
> wrote:
> >> >>>>
> >> >>>> Hi,
> >> >>>>
> >> >>>> I'm trying to get started with Pharo doing something really simple
> - at
> >> >>>> least that's what I thought ... I'm trying to read a text file
> line by line.
> >> >>>>
> >> >>>> If I use File named: '/tmp/linex.txt' readStream nextLine I'll
> get a
> >> >>>> debugger telling me that BinaryFileStream does not understand
> nextLine.
> >> >>>>
> >> >>>> Now I've tried my best to find a stream that may be reading plain
> text
> >> >>>> lines but to no avail ...
> >> >>>>
> >> >>>> Help!
> >> >>>>
> >> >>>> -dirk
> >> >>>
> >> >>> $ cat > /tmp/lines.txt
> >> >>> one
> >> >>> two
> >> >>> three
> >> >>>
> >> >>> (FileLocator temp / 'lines.txt') contents lines.
> >> >>>
> >> >>> '/tmp/lines.txt' asFileReference contents lines.
> >> >>>
> >> >>> '/tmp/lines.txt' asFileReference readStreamDo: [ :in |
> >> >>> Array streamContents: [ :out |
> >> >>> [ in atEnd ] whileFalse: [ out nextPut: in nextLine ] ] ].
> >> >>>
> >> >>> (File named: '/tmp/lines.txt') readStreamDo: [ :in |
> >> >>> | characterStream |
> >> >>> characterStream := ZnCharacterReadStream on: in.
> >> >>> Array streamContents: [ :out |
> >> >>> [ characterStream atEnd ] whileFalse: [ out nextPut:
> characterStream nextLine ] ] ].
> >> >>>
> >> >>> They all return #('one' 'two' 'three').
> >> >>>
> >> >>> In the last, more complex example, you first get a binary stream
> (and a 'line' is a character based concept), so wrapping the binary stream
> in a character read stream (which does know about lines) solves the problem.
> >> >>>
> >> >>> HTH,
> >> >>>
> >> >>> Sven
> >> >>
> >> >
> >> >
> >>
> >>
> >>
> >>
> >> --
> >>
> >> Guille Polito
> >> Research Engineer
> >>
> >> Centre de Recherche en Informatique, Signal et Automatique de Lille
> >> CRIStAL - UMR 9189
> >> French National Center for Scientific Research - http://www.cnrs.fr
> >>
> >> Web: http://guillep.github.io
> >> Phone: +33 06 52 70 66 13
> >
> >
>
>
--
Guille Polito
Research Engineer
Centre de Recherche en Informatique, Signal et Automatique de Lille
CRIStAL - UMR 9189
French National Center for Scientific Research - *http://www.cnrs.fr
<http://www.cnrs.fr>*
*Web:* *http://guillep.github.io* <http://guillep.github.io>
*Phone: *+33 06 52 70 66 13