Ever since I started using Squeak with Squeak 3.6
 (I only use Linux, currently Ubuntu 9.10)
I have always had trouble with line separators.
I am checking out  Squeak 4.1 and things have
changed though I am not sure if they are any better.

If I have  FileStream>>contreteStream return MultiByteFileStream
(the default) then when I fileOut code the .st file consists of a single
line so that I cannot use utilities such as  wc and vi on these files.
If I modify concreteStream to return  CrLfFileStream then the problem
goes away but a host other of problems occur.

1) It used to be that if you looked at the versions of a method
each version would be written on a single line  (I believe linefeeds
were used instead of carriage returns).
This no longer happens.  Instead every line of a version is separated
by a blank line.  An improvement I suppose; it is more readable.
(I believe what is happening is that end line separator contains
a line feed and a carriage return and both are treated as line
separators.)

2) It used to be that if you wrote out a file (with concreteStream returning
CrLfFileStream) then when you filed in the file using:
  (FileStream oldFileNamed:  'filename.st')  fileIn
you got carriage returns for line separators.
Now you get linefeeds.
This causes problems with Menu labels as in:

aMenu labels:
'find class... (f)
recent classes... (r)
browse all
browse
...

because carriage returns are expected.
Consequentially your Menu has a single entry. :-(
I expect there are other problems as well.
Now, even if you set  concreteStream  back to the default the same
problem occurs.  This works in 3.10.2 so we have gone backwards here.

3) If I cut and paste from a different  4.1 image I lose
my line separators altogether.  this is unchanged from before.

4?) Finally,  I used to have problems loading in .mcz files.  So far in 4.1 I
haven't had a problem but I have only loaded 2 .mcz files.
In prior versions of Squeak loading a .mcz file would sometimes succeed.

Are other Linux users having similar experiences?

Frankly, I think only one of  Cr  and  Lf  should be accepted in
Smalltalk code, the
other generating a syntax error except inside strings and inside
strings it should
have to be escaped somehow.

If  Cr is the character chosen for line separators then it should be
impossible to
write:

returnAString
      ^'a two line string where
the line separator is a linefeed'

The fact that the above code is legal leads to subtle errors such
as those above.  A blatant compiler error is preferred.


One final curiousity:  Why is the following method written as it is
(in both 4.1 and 3.10.2)?

Method  CrLfFileStream>>new

	^ (MultiByteFileStream new) wantsLineEndConversion: true; yourself.


I presume it is correct but a comment explaining why wouldn't hurt.

Regards,

Ralph Boland



--
Quantum Theory cannot save us from the tyranny of a deterministic universe
but it does give God something to do