New SqueakMap

Hi!

Just wanted to mention that I intend to upgrade SM tomorrow (3 apr)
night european time. I am guessing it might be down an hour or so worst
case - I will not bother trying to make it shorter.

Hopefully this will remove some "odd" issues with the map and make it
work properly in 3.9 (more issues than just logChange:). It will also
make sure that all Squeaks run the same code and from now on I will try
to track the release team better (somehow).

regards, Göran

[hidden email] skrev: Could you fix the SMPackageLoader window color bug at the same time.
I did a quick fix by changing the model of the PackageLoader to be
MorphicModel instead of SystemWindow. I can probably dig that change set up
if you want it.
Karl

Hi Karl!

karl <[hidden email]> wrote:
> Could you fix the SMPackageLoader window color bug at the same time.
> I did a quick fix by changing the model of the PackageLoader to be
> MorphicModel instead of SystemWindow. I can probably dig that change set up
> if you want it.

I can fix it and I appreciate a cs if you can dig it up. And oh, please
verify that it works correctly in Squeak 3.5-3.9 too. :) AFAIK it works
differently in different versions.

> Karl

regards, Göran

txxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxx
stef

On 2 avr. 06, at 21:54, [hidden email] wrote:

  Göran,

  It sounds like you took a path to use StandardFileStream
explicitly...  To me, the "correct" way to fix is to send #binary and
#text property.  It would be nice if we can get rid of
StandardFileStream (or rename MultiByteFileStream to
StandardFileStream)...

-- Yoshiki

At Sun, 2 Apr 2006 21:54:45 +0200 ,
[hidden email] wrote:

[hidden email] skrev: Here is a rehack from memory...
Not tested much at all...

Karl

>  
>> Karl
>>    
>
> regards, Göran
>
>
>
>  

Hi!

Yoshiki Ohshima <[hidden email]> wrote:
>   Göran,
>
>   It sounds like you took a path to use StandardFileStream
> explicitly...  To me, the "correct" way to fix is to send #binary and
> #text property.  It would be nice if we can get rid of
> StandardFileStream (or rename MultiByteFileStream to
> StandardFileStream)...
>
> -- Yoshiki

Code that works "properly" in 3.5-3.9 is welcome, perhaps it is
"trivial" I don't know - I just took the "cheap way out". :)

I am frankly a bit pressed to get this thing out and don't want to delay
it further. But I understand that I am "cheating" and I promise in any
case to take a second look for the next release, ok? :)

It's just that it seems to work now and I don't want to muddle it up
again.

regards, Göran

>   It sounds like you took a path to use StandardFileStream
> explicitly...  To me, the "correct" way to fix is to send #binary and
> #text property.  It would be nice if we can get rid of
> StandardFileStream (or rename MultiByteFileStream to
> StandardFileStream)...

Hi Yo
could we do that safely ;)?

Sometimes ago I play with encoding stream for french and I have problem
to see how w newbie could find its way in streams.....
Stef

  Göran,

> I am frankly a bit pressed to get this thing out and don't want to delay
> it further. But I understand that I am "cheating" and I promise in any
> case to take a second look for the next release, ok? :)
>
> It's just that it seems to work now and I don't want to muddle it up
> again.

  That is fine (and sort of expected response^^;) I just wanted to let
you know.

-- Yoshiki

  Stéphane,

> >   It sounds like you took a path to use StandardFileStream
> > explicitly...  To me, the "correct" way to fix is to send #binary and
> > #text property.  It would be nice if we can get rid of
> > StandardFileStream (or rename MultiByteFileStream to
> > StandardFileStream)...
>
> Hi Yo
> could we do that safely ;)?

  Conceptually, it should be safe as MultiByteFileStream *can* behave
identical to StandardFileStream.  It is just you need to tell it to do
so, and not all the code around do so.

-- Yoshiki

Hi Yoshiki!

Yoshiki Ohshima <[hidden email]> wrote:
The decision to let default filestreams to be #ascii instead of #binary
- what are the arguments for that?
I mean, to me "the least surprising thing" would have been binary
instead of a default conversion. So in the same vein as CrLfFileStream
it could have been binary until explicitly asked to make conversions.

But perhaps I am in minority in this "default expectation".

regards, Göran

  Göran,

> The decision to let default filestreams to be #ascii instead of #binary
> - what are the arguments for that?
> I mean, to me "the least surprising thing" would have been binary
> instead of a default conversion. So in the same vein as CrLfFileStream
> it could have been binary until explicitly asked to make conversions.
>
> But perhaps I am in minority in this "default expectation".

  One thing to be clarified is that a binary stream takes ByteArrays,
not Strings; #binary doesn't only mean non-conversions.

  So the question probably was about non-conversions vs conversions.

  For a first time Squeaker, they would want to write out a string and
read it back from a file (they wouldn't know the difference of
ByteString and WideString, or even the line end problem).  Otherwise,
there will be strings that *cannot* write out to a file.  For such
user, putting UTF-8 conversion (no matter what platform he is on) by
default would help.

  (Year, along this line, there can still be an argument that the
line-end-conversion should match the platform one.  But still I would
say keep it Squeak native would cause less confusion.)

  For somebody more than a novice, the user should set up things as he
wants.  I could say that this follows "Keep simple things simple, and
make complex things possible."^^;

-- Yoshiki

Yoshiki Ohshima wrote:
..
>   For a first time Squeaker, they would want to write out a string and
> read it back from a file (they wouldn't know the difference of
> ByteString and WideString, or even the line end problem).  Otherwise,
> there will be strings that *cannot* write out to a file.  For such
> user, putting UTF-8 conversion (no matter what platform he is on) by
> default would help.
>

Yoshiki,

I think the question is whether the first time Squeaker would want to
write out a String or something else or read something else in. The
general Squeak user doesn't want to write out anything and the
programmer is probably astonished about (and bitten by) the text
default, at least I was.

About another question of this thread: StandardFileStream is faster than
MultiByteFileStream for binary operations (25%-30% for a simple loop
with #next). So IMHO we should not "get rid of it".

Regards,
Martin

  Martin,

  I should've phrased differently.  "For a novice Squeak programmer
who is trying to deal with files first time" is closer what I meant.

  Yes, when we talk about the "least surprise principle", we always
have to be careful about "whose surprise?" question.  What would you
suggest?

> About another question of this thread: StandardFileStream is faster than
> MultiByteFileStream for binary operations (25%-30% for a simple loop
> with #next). So IMHO we should not "get rid of it".

  The better design would be to separate the responsibility, which
Andreas mentioned.  I'm pretty sure that we are not going to get rid
of StandardFileStream just for the sake of simplicity.

  On the other hand, I would say that reading a byte by a byte is not
a common practice and 30% improvement doesn't necessary warrant having
special cases.

-- Yoshiki

Yoshiki Ohshima wrote:

>
>   I should've phrased differently.  "For a novice Squeak programmer
> who is trying to deal with files first time" is closer what I meant.
>
>   Yes, when we talk about the "least surprise principle", we always
> have to be careful about "whose surprise?" question.  What would you
> suggest?
>

That  FileStream oldFileNamed: 'xyz.gif'  assumes that xyz.gif is a text
file of UFT-8 format looks to me like the principle of the biggest
surprise ;)

I think you can't help the programmer who doesn't know crlf and text
format problems with this rigid default much, because UTF-8 is a
relatively uncommon text format and there are many other file operations
than writing out strings and reading them back. Very soon and in any
case the novice will find out that something strange is going on there...

Regards,
Martin

  Martin,

> That  FileStream oldFileNamed: 'xyz.gif'  assumes that xyz.gif is a text
> file of UFT-8 format looks to me like the principle of the biggest
> surprise ;)

  Opening a .gif file as a text file with *any* encoding (including
non-conversion latin1) is logically wrong anyway...  So this example
may not tell us anything^^;

> I think you can't help the programmer who doesn't know crlf and text
> format problems with this rigid default much, because UTF-8 is a
> relatively uncommon text format and there are many other file operations
> than writing out strings and reading them back. Very soon and in any
> case the novice will find out that something strange is going on there...

  Whether it is rigid or not depends on the point of view, IMO... It
can be said that it is forgiving.

  I might agree that it is uncommon^^;, but not all the time.

  I agree that the programmer needs to take care of it, but reading
any non-text file in text mode creates all sort of problems.  One
could say that setting UTF-8 as default helps to find out the bug (or
"something strange") soon.

  I'm not too sticky about it and am willing to agree to change the
default conversion (it'll hide many potential bugs, which many of you
seem to want), fixing file list, etc.  Just want to hear a bit more
convincing reasons...

-- Yoshiki

Hi Yoshiki!

Yoshiki Ohshima <[hidden email]> wrote:
[SNIP]
I would like to hear more about the different ways the #converter
instvar is set - which I commented on in... this post:

        http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-April/10252
6.html

...because I don't follow the logic. :)

regards, Göran

Yoshiki Ohshima wrote:
>> That  FileStream oldFileNamed: 'xyz.gif'  assumes that xyz.gif is a text
>> file of UFT-8 format looks to me like the principle of the biggest
>> surprise ;)
>
>   Opening a .gif file as a text file with *any* encoding (including
> non-conversion latin1) is logically wrong anyway...  So this example
> may not tell us anything^^;

It's actually funny for me to follow this discussion because it's at the
heart of why I think a separation of concerns is necessary. The way I
look at the above statements is that there is an implicitly different
assumption about what role "FileStream" has. Martin makes the (not
unreasonable) assumption that FileStream is a byte-oriented stream,
whereas Yoshiki makes the (equally reasonable) assumption that
FileStream is a character-oriented stream.

Who is right? If characters are bytes, both. If characters are not bytes
(I think) neither. We're living in a state of confusion these days
because historically FileStream has been used for both purposes and
we're now learning that when characters are no longer bytes we need to
be a little clearer about the roles.

Cheers,
   - Andreas

I agree with Andreas.

It seems to me that character-oriented streams (and any other streams  
that deal with structured data) should be layered on top of byte-
oriented streams, as is done by SmartRefStream (through its  
superclass, DataStream).  A SmartRefStream doesn't care whether it's  
ultimately reading from / writing to a buffer in memory, from a file,  
or a network socket connection; that's the responsibility of its  
'byteStream'.

Josh


On Apr 12, 2006, at 5:03 PM, Andreas Raab wrote:

  Josh,

> It seems to me that character-oriented streams (and any other streams  
> that deal with structured data) should be layered on top of byte-
> oriented streams, as is done by SmartRefStream (through its  
> superclass, DataStream).  A SmartRefStream doesn't care whether it's  
> ultimately reading from / writing to a buffer in memory, from a file,  
> or a network socket connection; that's the responsibility of its  
> 'byteStream'.

  Almost, yes.  Just the fact that SmarRefStream sends #ascii (old
day's #text, I consider) and #binary and sometimes it reads some
encoded text from byteStream suggests it is overdue of refactoring.

-- Yoshiki