String>>withNormalizedLineDelimiters

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

String>>withNormalizedLineDelimiters

Keith Alcock-3
Object Arts,

I looked through both DSDN and the release notes to Dolphin 5.0 and
didn't see anything about this problem, although #453 might be related.
 String>>withNormalizedLineDelimiters does not work properly IMO.  I
believe that the problem was that CR/LF gets converted to just LF when
the string already has normalized line delimiters.  The old version is
this one:

withNormalizedLineDelimiters
        "Answer a copy of the receiver with any line terminator
convention converted to the windows (CR/LF) convention."

        | target cr lf eol stm |
        target := self class writeStream: self size.
        stm := self readStream.
        cr := Character cr.
        lf := Character lf.
        eol := String lineDelimiter.
        stm do: [:c |
                c == lf
                        ifTrue: [target nextPut: cr; nextPut: c]
                        ifFalse: [
                                c == cr
                                        ifTrue: [
                                                stm peekFor: lf.
                                                target nextPut: lf]
                                        ifFalse: [target nextPut: c]]].
        ^target contents

and the correction in my image is:

myWithNormalizedLineDelimiters
        "Answer a copy of the receiver with any line terminator
convention converted to the windows (CR/LF) convention."

        | target cr lf eol stm |
        target := self class writeStream: self size.
        stm := self readStream.
        cr := Character cr.
        lf := Character lf.
        eol := String lineDelimiter.
        stm do: [:c |
                c == lf ifTrue: [
                        "lf -> cr/lf"
                        target nextPut: cr;
                                nextPut: lf.
                ] ifFalse: [
                        c == cr ifTrue: [
                                "cr or cr/lf -> cr/lf"
                                stm peekFor: lf.
                                target nextPut: cr;
                                        nextPut: lf.
                        ] ifFalse: [
                                target nextPut: c.
                        ].
                ].
        ].
        ^target contents

It might be good to get it in with version 5.0.

Thanks.


Reply | Threaded
Open this post in threaded view
|

Re: String>>withNormalizedLineDelimiters

Blair McGlashan
"Keith Alcock" <[hidden email]> wrote in message
news:[hidden email]...
> ...
> I looked through both DSDN and the release notes to Dolphin 5.0 and
> didn't see anything about this problem, although #453 might be related.
>  String>>withNormalizedLineDelimiters does not work properly IMO.  I
> believe that the problem was that CR/LF gets converted to just LF when
> the string already has normalized line delimiters. ...

This does seem to been fixed in RC1, I think probably under a re-opened old
defect (#249) which has prevented it appearing in the release notes.

Regards

Blair


Reply | Threaded
Open this post in threaded view
|

Re: String>>withNormalizedLineDelimiters

Keith Alcock-3
Blair,

Sorry, this was my mistake.  It looks to have been corrected in D4 PL3
already.  I had rebuilt the image and forgot to include the patches.  I
really appreciate your bug tracking system there.

Keith Alcock


Blair McGlashan wrote:

>
> "Keith Alcock" <[hidden email]> wrote in message
> news:[hidden email]..
> > ...
> > I looked through both DSDN and the release notes to Dolphin 5.0 and
> > didn't see anything about this problem, although #453 might be related.
> >  String>>withNormalizedLineDelimiters does not work properly IMO.  I
> > believe that the problem was that CR/LF gets converted to just LF when
> > the string already has normalized line delimiters. ...
>
> This does seem to been fixed in RC1, I think probably under a re-opened old
> defect (#249) which has prevented it appearing in the release notes.
>
> Regards
>
> Blair