New SqueakMap on the air... and we got problems Houston!

goran at krampe.se goran at krampe.se
Fri Apr 7 07:00:57 UTC 2006


Hi Andreas!

Andreas Raab <andreas.raab at gmx.de> wrote:
> Hi Goran -
> 
> goran at krampe.se wrote:
> > Well, SM does more than "looking" (if IE 5 renders a page ugly it
> > doesn't hurt that much - if SM screws up installing things it hurts
> > more) and I am aiming for it to do even more in the future - actually
> > modifying the map (getting rid of the web UI for modifying the map and
> > instead letting client images upload modified SMObjects in XML form - at
> > least that is the plan this hour).
> 
> I think that's a discussion for another day but I'd recommend to keep 
> the web UI up.

Yes, I will never *drop* the web UI - but hopefully we can then move to
make Squeak tools to modify the map instead of being *forced* to use the
web UI.

> > AFAIK you haven't yet mentioned 2.2 failing to install. I just tried it
> > though (in Croquet) and I noted you are forbidding underscores as
> > assignments - that was at least one issue (and I now changed the
> > underscores in the load script). Hmmm, let me test again btw...
> > 
> > ...yes, ok, it works fine (unless I have missed something) if you first
> > do:
> > 
> > 	Preferences enable: #allowUnderscoreAssignment
> 
> Actually, yes I missed something. My problem wasn't really installing (I 
> just thought it was) but earlier in the process. There is a bug in 2.1 
> in SMSqueakMap>>reload stating, e.g.,
> 
> contents := (self directory oldFileNamed: fname) ascii upToEnd unzipped.
> 
> Since you're setting it to ascii, the stream installs a UTF8Converter 
> and stops reading at certain characters (this is another place that 
> really should raise an error to inform the user that something went 
> wrong instead of returning nil which informs the sender that the stream 
> is apparently at end). The above needs to be "binary upToEnd asString 
> unzipped" or somesuch. I got caught by that because I expected that 
> Squeakmap was already installing.

Yes, I know. This code has been fixed in 2.2. I can't remember the exact
details but for some odd reason (I think I was trying to find how to
unzip the darn thing and didn't really understand at that moment that
ascii would start doing funky conversions - or perhaps it was that it
doesn't in 3.7 but does in 3.8, I dunno) I ended up with the above code
and didn't discover that it actually doesn't work. :)

Btw, yesterday I was staring at the MultiByteFileStream stuff and...
well, IMHO it would have been better *for me* (other users may have
other stories to tell) if the default was binary and not ascii. The
principle of least surprise. If I open a filestream and don't tell it
*anything*, then I would expect it to just feed me the bits and bytes -
as Strings or ByteArrays, but not doing any conversions or line end
mumbo jumbo or any other non expected "nice things". An example of this
is inspecting a file in the file list - I really appreciated the fact
that filelist didn't do *any* conversion on the stuff it showed me - now
it does. And I also wonder where the hex view went... anyway:

Yesterday my collegue wanted to save stuff with platform specific line
endings (wantsLineEndConversion: true etc) but NOT doing any other
conversions. We realized that you can't set converter to nil - it will
lazily set itself to the default platform converter (seems to me at
least). And if you tell the stream to be binary it will not do line end
conversions.

What I ended up doing was creating NullTextConverter (which does no
conversion at all) and then it worked fine. It seems to me that a
cleaner approach here would be to:

1. Do line end conversions or not regardless of the 2 choices below..
2. Binary or ascii - only decides if we use ByteArrays or Strings,
doesn't concern conversions or line ends.
3. Selection of converter where we also have a NullConverter that does
nothing.

IMHO (having not dissected this in total detail) the above three options
should be combinable. So for example, in our case we have utf8 strings
that we want to write out *as is* and use #cr to get platform specific
line endings.

> > But I can clean those underscores up of course, anyone got a nice script
> > that *works* :) to do that?
> 
> Oh, I am *very* confident that I have thoroughly debugged Bert's script. 

:)

> That exercise was a major part of my painful experiences yesterday 
> because in the process of noting where it had failed earlier I blew up 
> all of our repositories (and badly so). But actually it will work fine 
> if you do just one change - that is use #hasLiteralSuchThat: instead of 
> just looking at the top-level literals. That's because 
> hasLiteralSuchThat: will look inside Array literals and that will avoid 
> issues like here:
> 
>          version >= 1.1 ifTrue:[
>              extensions addAll: #(
>                  'GL:=EXT:=blend:=logic:=op'
>                  'GL:=EXT:=copy:=texture'
>                  'GL:=EXT:=polygon:=offset'
>                  'GL:=EXT:=subtexture'
>                  'GL:=EXT:=texture'
>                  'GL:=EXT:=texture:=object'
>                  'GL:=EXT:=vertex:=array'
>              ).
>          ].
> 
> 
> Nice, eh?

Neato. Btw, the method in which I discovered that it had messed up my
literals (in an array) I also noted it had changed the underscores
inside the method comment. Or at least I think it had, can't swear on my
laptop though. ;)

> Cheers,
>    - Andreas

regards, Göran



More information about the Squeak-dev mailing list