CrLfStream bug.

> Speaking of end of line conventions, here's issue 1472 :)
>
> CrLfStream fails horribly currently, since the UTF8-converters latin1map never gets initialized.
> detectLineEndConvention gets called before converter is installed, and later on,
> in MultiByteFileStream>>open: forWrite: , converter lineendings never gets set (and latin1map initialized) if lineEndConvention isn't nil.
>
> Alternatives:
>
> 1. ensure lineEndConvention installation:
>
> MultiByteFileStream>>open: fileName forWrite: writeMode
>        | result |
>        result := super open: fileName forWrite: writeMode.
>        result ifNotNil: [
>                        converter ifNil: [converter := UTF8TextConverter new].
>                        lineEndConvention ifNil: [ self detectLineEndConvention ]
>                                                        ifNotNil: [self installLineEndConventionInConverter]
>        ].
>        ^result
>
> 2. Use converter: instead, since that installs the lineEndConvention:
> MultiByteFileStream>>open: fileName forWrite: writeMode
>        | result |
>        result := super open: fileName forWrite: writeMode.
>        result ifNotNil: [
>                        converter ifNil: [self converter: UTF8TextConverter new].
>                        lineEndConvention ifNil: [ self detectLineEndConvention ]
>
>        ].
>        ^result
>
> Ironically, if no lineEndConvention is defined, it will default to the same line-ending as you would get with a CrLfStream anyways :P
>
> I'm  submitting a slice with approach 2 to inbox.
>
> Cheers,
> Henry
>
>

> 2009/11/20 Henrik Johansen <[hidden email]>:
>> Speaking of end of line conventions, here's issue 1472 :)
>>
>> CrLfStream fails horribly currently, since the UTF8-converters latin1map never gets initialized.
>> detectLineEndConvention gets called before converter is installed, and later on,
>> in MultiByteFileStream>>open: forWrite: , converter lineendings never gets set (and latin1map initialized) if lineEndConvention isn't nil.
>>
>> Alternatives:
>>
>> 1. ensure lineEndConvention installation:
>>
>> MultiByteFileStream>>open: fileName forWrite: writeMode
>>        | result |
>>        result := super open: fileName forWrite: writeMode.
>>        result ifNotNil: [
>>                        converter ifNil: [converter := UTF8TextConverter new].
>>                        lineEndConvention ifNil: [ self detectLineEndConvention ]
>>                                                        ifNotNil: [self installLineEndConventionInConverter]
>>        ].
>>        ^result
>>
>> 2. Use converter: instead, since that installs the lineEndConvention:
>> MultiByteFileStream>>open: fileName forWrite: writeMode
>>        | result |
>>        result := super open: fileName forWrite: writeMode.
>>        result ifNotNil: [
>>                        converter ifNil: [self converter: UTF8TextConverter new].
>>                        lineEndConvention ifNil: [ self detectLineEndConvention ]
>>
>>        ].
>>        ^result
>>
>> Ironically, if no lineEndConvention is defined, it will default to the same line-ending as you would get with a CrLfStream anyways :P
>>
>> I'm  submitting a slice with approach 2 to inbox.
>>
>> Cheers,
>> Henry
>>
>>
>
> Oh, I see now why I missed this one.
> trunk does not have Keith change:
>                        lineEndConvention ifNil: [ self
> detectLineEndConvention ]
> but a direct call to:
>                        self detectLineEndConvention
> So trunk always set the line end convention in the converter and I
> decided it was not necessary to use self converter: here...
> Integrating Keith change has broken this fragile constuction, don't
> know when it came in.

> I approve solution 2)
>
> Cheers
>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>

> 2009/11/20 Nicolas Cellier <[hidden email]>:
>> 2009/11/20 Henrik Johansen <[hidden email]>:
>>> Speaking of end of line conventions, here's issue 1472 :)
>>>
>>> CrLfStream fails horribly currently, since the UTF8-converters latin1map never gets initialized.
>>> detectLineEndConvention gets called before converter is installed, and later on,
>>> in MultiByteFileStream>>open: forWrite: , converter lineendings never gets set (and latin1map initialized) if lineEndConvention isn't nil.
>>>
>>> Alternatives:
>>>
>>> 1. ensure lineEndConvention installation:
>>>
>>> MultiByteFileStream>>open: fileName forWrite: writeMode
>>>        | result |
>>>        result := super open: fileName forWrite: writeMode.
>>>        result ifNotNil: [
>>>                        converter ifNil: [converter := UTF8TextConverter new].
>>>                        lineEndConvention ifNil: [ self detectLineEndConvention ]
>>>                                                        ifNotNil: [self installLineEndConventionInConverter]
>>>        ].
>>>        ^result
>>>
>>> 2. Use converter: instead, since that installs the lineEndConvention:
>>> MultiByteFileStream>>open: fileName forWrite: writeMode
>>>        | result |
>>>        result := super open: fileName forWrite: writeMode.
>>>        result ifNotNil: [
>>>                        converter ifNil: [self converter: UTF8TextConverter new].
>>>                        lineEndConvention ifNil: [ self detectLineEndConvention ]
>>>
>>>        ].
>>>        ^result
>>>
>>> Ironically, if no lineEndConvention is defined, it will default to the same line-ending as you would get with a CrLfStream anyways :P
>>>
>>> I'm  submitting a slice with approach 2 to inbox.
>>>
>>> Cheers,
>>> Henry
>>>
>>>
>>
>> Oh, I see now why I missed this one.
>> trunk does not have Keith change:
>>                        lineEndConvention ifNil: [ self
>> detectLineEndConvention ]
>> but a direct call to:
>>                        self detectLineEndConvention
>> So trunk always set the line end convention in the converter and I
>> decided it was not necessary to use self converter: here...
>> Integrating Keith change has broken this fragile constuction, don't
>> know when it came in.
>
> http://code.google.com/p/pharo/issues/detail?id=1013 in 10400
> http://bugs.squeak.org/view.php?id=6086
>
> Now I know
>
>> I approve solution 2)
>>
>> Cheers
>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> Stef
>
> On Nov 20, 2009, at 8:50 PM, Nicolas Cellier wrote:
>
>> 2009/11/20 Nicolas Cellier <[hidden email]>:
>>> 2009/11/20 Henrik Johansen <[hidden email]>:
>>>> Speaking of end of line conventions, here's issue 1472 :)
>>>>
>>>> CrLfStream fails horribly currently, since the UTF8-converters latin1map never gets initialized.
>>>> detectLineEndConvention gets called before converter is installed, and later on,
>>>> in MultiByteFileStream>>open: forWrite: , converter lineendings never gets set (and latin1map initialized) if lineEndConvention isn't nil.
>>>>
>>>> Alternatives:
>>>>
>>>> 1. ensure lineEndConvention installation:
>>>>
>>>> MultiByteFileStream>>open: fileName forWrite: writeMode
>>>>        | result |
>>>>        result := super open: fileName forWrite: writeMode.
>>>>        result ifNotNil: [
>>>>                        converter ifNil: [converter := UTF8TextConverter new].
>>>>                        lineEndConvention ifNil: [ self detectLineEndConvention ]
>>>>                                                        ifNotNil: [self installLineEndConventionInConverter]
>>>>        ].
>>>>        ^result
>>>>
>>>> 2. Use converter: instead, since that installs the lineEndConvention:
>>>> MultiByteFileStream>>open: fileName forWrite: writeMode
>>>>        | result |
>>>>        result := super open: fileName forWrite: writeMode.
>>>>        result ifNotNil: [
>>>>                        converter ifNil: [self converter: UTF8TextConverter new].
>>>>                        lineEndConvention ifNil: [ self detectLineEndConvention ]
>>>>
>>>>        ].
>>>>        ^result
>>>>
>>>> Ironically, if no lineEndConvention is defined, it will default to the same line-ending as you would get with a CrLfStream anyways :P
>>>>
>>>> I'm  submitting a slice with approach 2 to inbox.
>>>>
>>>> Cheers,
>>>> Henry
>>>>
>>>>
>>>
>>> Oh, I see now why I missed this one.
>>> trunk does not have Keith change:
>>>                        lineEndConvention ifNil: [ self
>>> detectLineEndConvention ]
>>> but a direct call to:
>>>                        self detectLineEndConvention
>>> So trunk always set the line end convention in the converter and I
>>> decided it was not necessary to use self converter: here...
>>> Integrating Keith change has broken this fragile constuction, don't
>>> know when it came in.
>>
>> http://code.google.com/p/pharo/issues/detail?id=1013 in 10400
>> http://bugs.squeak.org/view.php?id=6086
>>
>> Now I know
>>
>>> I approve solution 2)
>>>
>>> Cheers
>>>
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> Does it have to be short ? unfortunately I do not have the answer this time...
>
> Nicolas
>
>> Stef
>>
>> On Nov 20, 2009, at 8:50 PM, Nicolas Cellier wrote:
>>
>>> 2009/11/20 Nicolas Cellier <[hidden email]>:
>>>> 2009/11/20 Henrik Johansen <[hidden email]>:
>>>>> Speaking of end of line conventions, here's issue 1472 :)
>>>>>
>>>>> CrLfStream fails horribly currently, since the UTF8-converters latin1map never gets initialized.
>>>>> detectLineEndConvention gets called before converter is installed, and later on,
>>>>> in MultiByteFileStream>>open: forWrite: , converter lineendings never gets set (and latin1map initialized) if lineEndConvention isn't nil.
>>>>>
>>>>> Alternatives:
>>>>>
>>>>> 1. ensure lineEndConvention installation:
>>>>>
>>>>> MultiByteFileStream>>open: fileName forWrite: writeMode
>>>>>        | result |
>>>>>        result := super open: fileName forWrite: writeMode.
>>>>>        result ifNotNil: [
>>>>>                        converter ifNil: [converter := UTF8TextConverter new].
>>>>>                        lineEndConvention ifNil: [ self detectLineEndConvention ]
>>>>>                                                        ifNotNil: [self installLineEndConventionInConverter]
>>>>>        ].
>>>>>        ^result
>>>>>
>>>>> 2. Use converter: instead, since that installs the lineEndConvention:
>>>>> MultiByteFileStream>>open: fileName forWrite: writeMode
>>>>>        | result |
>>>>>        result := super open: fileName forWrite: writeMode.
>>>>>        result ifNotNil: [
>>>>>                        converter ifNil: [self converter: UTF8TextConverter new].
>>>>>                        lineEndConvention ifNil: [ self detectLineEndConvention ]
>>>>>
>>>>>        ].
>>>>>        ^result
>>>>>
>>>>> Ironically, if no lineEndConvention is defined, it will default to the same line-ending as you would get with a CrLfStream anyways :P
>>>>>
>>>>> I'm  submitting a slice with approach 2 to inbox.
>>>>>
>>>>> Cheers,
>>>>> Henry
>>>>>
>>>>>
>>>>
>>>> Oh, I see now why I missed this one.
>>>> trunk does not have Keith change:
>>>>                        lineEndConvention ifNil: [ self
>>>> detectLineEndConvention ]
>>>> but a direct call to:
>>>>                        self detectLineEndConvention
>>>> So trunk always set the line end convention in the converter and I
>>>> decided it was not necessary to use self converter: here...
>>>> Integrating Keith change has broken this fragile constuction, don't
>>>> know when it came in.
>>>
>>> http://code.google.com/p/pharo/issues/detail?id=1013 in 10400
>>> http://bugs.squeak.org/view.php?id=6086
>>>
>>> Now I know
>>>
>>>> I approve solution 2)
>>>>
>>>> Cheers
>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Pharo-project mailing list
>>>>> [hidden email]
>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project