[squeak-dev] Re: problems with line separators in Linux

Ralph Boland rpboland at gmail.com
Sat Jun 12 15:12:53 UTC 2010


...
> >> 10) This 6.a) strategy could eventually replace 2.a), but it does not
> >> have to, and we didn't went this way...
> >> So both Squeak 4.1 and Pharo 1.1 are not any worse than Squeak > > always
> >> has been with this respect.
> >
> > Except that now the conversion of Lf in Linux files to  Cr in Squeak no longer
> > occurs and this breaks things such as Menu labels.  Thus things that used
> > to work now don't.
> >

> I don't see what change could cause this problem...


I checked out loading a .st file in both  Squeak 10.2 and Squeak 4.1.
filing in the
following file:

'From Squeak4.1 of 17 April 2010 [latest update: #9957] on 7 June 2010
at 9:30:22 pm'!
Object subclass: #Junk
	instanceVariableNames: ''
	classVariableNames: ''
	poolDictionaries: ''
	category: 'Kernel-Objects'!

!Junk methodsFor: 'as yet unclassified' stamp: 'rpb 6/7/2010 21:27'!
junk

	| a |
	a := 'abc
	def
	ghi'.
	self halt.
	a := a.! !

In  Squeak 10.2
  a)  If  concreteStream returns  CrLfFileStream:
       ClassCategoryReader  eventually calls  scanFrom: aStream where  aStream
       is a  MultiByteFileStream and the next chunk of text is:

junk

	| a |
	a := 'abc
	def
	ghi'.
	self halt.
	a := a.! !

At this point 'aStream nextChunkText' is called.
which does:  string := self nextChunk.
nextChunk then does a 'self skipSeparators' and then calls  'self
next' in a loop.

The 'self next'  reads the next character and does a 'self doConversion' test
which returns true so if the character read is a  Lf character it is
 converted into a Cr character.

b)  If  concreteStream returns  MultiByteFileStream:
     The same thing happens except  doConversion returns false and so
      Lf characters are NOT converted into Cr characters.

In  Squeak 4.1 everything is the same up to the point  'aStream
nextChunkText' is called.
nextChunkText calls:

	'^converter nextChunkTextFromStream: self'

where converter is a MacRomanTextConverter.

Following the trail from here looks completely different than the
Squeak 10.2 code.
In particular I could not find where an attempt to convert  Lf
characters to Cr characters
was supposed to occur let alone why it failed if  concreteStream
returns CrLfFileStream.


Note that in  10.2  if   concreteStream returns  MultiByteFileStream:
then  Lf  characters
are NOT converted into  Cr characters.   I would have expected  Lf
characters and
Cr,Lf  character pairs to be converted to  Cr characters regardless of
what  concreteStream
returns.  We do at this point know we are reading  Squeak code so Lfs
are inappropriate.
>From my point of view there is no need for the 'doConversion' test at
all except in strings
where the user may intensionally want  Lf or  Cr,Lf for some odd
reason and we shouldn't
break his/her code.  In that case no conversion should be done under
any circumstances
so the code is wrong both ways:  it fails to convert when it should
and converts when
it shouldn't.

Since I couldn't figure out how 4.1 handles things I can't say if it
does any better.

Hope this explains a few things.

> The recent commit should solve the menu problem in presence of LF leakage.

How do I install the version with this fix rather than the version of  4.1 found
on the Squeak page?

Regards,

Ralph Boland



More information about the Squeak-dev mailing list