how come my variable names keep changing to t<x>

Mark Mullin mark at vibrant3d.com
Thu Feb 21 14:49:09 UTC 2002


I went and did something to my image, and now whenever I save a method, the
system reprints it with all the variables changed to t1 thru tn.  I've
turned off all my printing prefs, anything else that looked guilty but the
bad behavior remains.  Problem is if I double save, poof, there go all my
meaningful variable names.  Whatever have I messed up ?

On a related note, anyone know why my generated plugin has StarPlugin_ in
front of every variable name ?

TIA
Mark/Vibrant 3D

-----Original Message-----
From: squeak-dev-admin at lists.squeakfoundation.org
[mailto:squeak-dev-admin at lists.squeakfoundation.org]On Behalf Of
squeak-dev-request at lists.squeakfoundation.org
Sent: None
To: squeak-dev at lists.squeakfoundation.org
Subject: Squeak-dev digest, Vol 1 #453 - 42 msgs


Send Squeak-dev mailing list submissions to
	squeak-dev at lists.squeakfoundation.org

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.squeakfoundation.org/listinfo/squeak-dev
or, via email, send a message with subject or body 'help' to
	squeak-dev-request at lists.squeakfoundation.org

You can reach the person managing the list at
	squeak-dev-admin at lists.squeakfoundation.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Squeak-dev digest..."


Today's Topics:

   1. [ANN] [VM] [WIN32] Win32 build enhancements swiki (Ross Boylan)
   2. RE: [VM] Build report and queries (Unix and Win32) (Andreas Raab)
   3. Re: Showing the essence of programming in 20 minutes to schoolkids -
(Cees de Groot)
   4. Re: FAQ section on licenses (Cees de Groot)
   5. Re: [updates] 6 for 3.3a (JPEGReaderWriter2.h clash) (Juan Manuel
Vuletich)
   6. [BC][FIX] Block Closures, Version 2 Fix (Anthony Hannan)
   7. RE: Process local variable and debugging (Terry Raymond)
   8. Re: [BUG][Modules] Finding class Project (Hannes Hirzel)
   9. Re: [Modules] Upper case message names for accessing modules (Hannes
Hirzel)
  10. Re: Best way (morph) for working with pixels (Hannes Hirzel)
  11. Re: MacOS X 3.2 VM updated (CocoaSqueak) (Alain Fischer)
  12. RE: [VM] Build report and queries (Unix and Win32) (Ross Boylan)
  13. Re: MacOS X 3.2 VM updated (CocoaSqueak) (Avi Bryant)
  14. RE: Process local variable and debugging (Anthony Hannan)
  15. Re: quick mac comswiki question (Raymond Asselin)
  16. Re: Good Hashing paper (Stephan Rudlof)
  17. Re: Good Hashing paper (Scott A Crosby)
  18. BLock Closure VM for Mac 3.2.4 (oops 4.x?) (John M McIntosh)
  19. Re: BLock Closure VM for Mac 3.2.4 (oops 4.x?) (Scott A Crosby)
  20. Re: [VM] [ENH] [WIN32] Win32 enhancements (Rob Withers)
  21. [ENH] Remember window size for tools (Jim Benson)
  22. [BC2] Windows VM (was: Re: BLock Closure VM for Mac 3.2.4
       (oops 4.x?)) (Rob Withers)
  23. [ANN] Seaside: Squeak Enterprise Aubergines Server (Avi Bryant)
  24. Re: Namespaces - Importing versus Explicit Naming (was Re: [Modules]
       Upper (Doug Way)
  25. Re: Good Hashing paper (Martin McClure)
  26. Re: [VM] [ENH] [WIN32] Win32 enhancements (Ross Boylan)
  27. Re: [Modules] Upper case message names for accessing modules (Doug
Way)
  28. Re: Good Hashing paper (Stephan Rudlof)
  29. Re: [Modules] Upper case message names for accessing modules (Doug
Way)
  30. RE: [VM] Build report and queries (Unix and Win32) (Lex Spoon)
  31. Re: Good Hashing paper (Lex Spoon)
  32. Pending mac vm 3.2.4 (need a tester or two) (John M McIntosh)
  33. Re: [Modules] Upper case message names for accessing modules (Doug
Way)
  34. Re: MacOS X 3.2 VM updated (CocoaSqueak) (Marcel Weiher)
  35. Re: [BUG][Modules] Finding class Project (goran.hultgren at bluefish.se)
  36. Re: [Modules] Upper case message names for accessing modules
(goran.hultgren at bluefish.se)
  37. [ENH] Obey Colors (Jim Benson)
  38. stanford mouse video archive (Bruce O'Neel)
  39. Re: [Modules] Upper case message names for accessing modules
(goran.hultgren at bluefish.se)
  40. Re: [Modules] Upper case message names for accessing modules
(goran.hultgren at bluefish.se)

--__--__--

Message: 1
Date: Wed, 20 Feb 2002 15:00:29 -0800
To: squeak-dev at lists.squeakfoundation.org
From: Ross Boylan <RossBoylan at stanfordalumni.org>
Subject: [ANN] [VM] [WIN32] Win32 build enhancements swiki
Cc: Andreas Raab <Andreas.Raab at gmx.de>,
 Tim Rowledge <tim at sumeru.stanford.edu>,
 ross Boylan <RossBoylan at stanfordalumni.org>
Reply-To: squeak-dev at lists.squeakfoundation.org

I've just modified http://minnow.cc.gatech.edu/squeak/1787  (Building a
Windows VM) to describe how I did the Win32 build with MSVC, and created a
page http://minnow.cc.gatech.edu/squeak/2281 that "describes the current
status, open issues, and possible future plans for building Squeak on
Win32. Currently it only has stuff that has attracted the author's
attention (Ross Boylan), but I encourage you to add to it."

I think the most notable general interest item in these changes is that
they permit MS Win squeaks to work with newer Unix images.

I should emphasize that though the result seems to work, it might not be
solid.  Also, things are likely to change quite a bit more in the
future--this is just a snapshot of something that seems to work.

Feedback welcome.


--__--__--

Message: 2
From: "Andreas Raab" <Andreas.Raab at gmx.de>
To: <squeak-dev at lists.squeakfoundation.org>
Subject: RE: [VM] Build report and queries (Unix and Win32)
Date: Wed, 20 Feb 2002 23:59:54 +0100
Reply-To: squeak-dev at lists.squeakfoundation.org

Lex,

> It's kind of interesting how different platforms are affected by this.
> Old Unix VM's are perfectly fine with these images, because they just
> obediently pass on the requested image file to the
> platform-independent portion of Squeak.  The Windows VM's (and maybe
> the Mac VM's?) try to do some sanity checking to protect the
> user from Bad Catastrophic Horrible Bad Things that they couldn't
> possibly want,

Actually no. What you're seeing is a side effect of an entirely
different feature - namely that of being able to start Squeak just by
double clicking on the executable or dropping some project file or
whatever onto it. In order for this to work, the VM checks if the thing
you're passing in is a Squeak image file and if not, tries to find one
on its own.

> and end up being a tiny bit too restrictive. Instead of fixing the
sanity
> check, it would be possible to just *remove* the check, but I don't
remember
> anyone proposing that kind of solution.

For good reasons. Many (most?) Windows people are used to start
applications and therefore, if there is a Squeak.exe they will try to
start it and if it dies for no good reason or gives questionable
responses (like popping up dialog boxes etc) you've just lost a possible
user.

Cheers,
  - Andreas



--__--__--

Message: 3
To: squeak-dev at lists.squeakfoundation.org
From: cg at cdegroot.com (Cees de Groot)
Subject: Re: Showing the essence of programming in 20 minutes to
schoolkids -
Date: 21 Feb 2002 01:00:40 +0100
Organization: cdegroot.com
Reply-To: squeak-dev at lists.squeakfoundation.org

These seem to be more applicable to demoing Squeak. Whereas my intent
(well-understood by Andreas) is to use Squeak as a tool (if necessary, if
possible) to explain the essence of our work. Which basically boils down to
paid riddle/puzzle solving, not?

(whether it's riddle of puzzle solving depends on the quality of the specs
:-)).


Jerzy Karczmarczuk <karczma at info.unicaen.fr> said:
>1. Show that computers can hold THINGS which obey simple commands. Not only
>   textual: Bunny jump.  grasshopper move. etc., but also *gestual*. Show
>   that anybody, even a 5-year old Master can communicate with those
>   objects.
>
>2. Show that the objects are persistant, that the kids may do something
they
>   find nice, and
>   a. they may send it to their pals. They may share it!
>   b. they may *keep* it for a few minutes, or a week; they may change it.
>
>3. Show that the environment is safe. That they can't really spoil
anything.
>   (Weeelll, we know they can, but keep that secret for a moment...)
>


--
Cees de Groot               http://www.cdegroot.com     <cg at cdegroot.com>
GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD  1986 F303 937F E098 9E8B

--__--__--

Message: 4
To: squeak-dev at lists.squeakfoundation.org
From: cg at cdegroot.com (Cees de Groot)
Subject: Re: FAQ section on licenses
Date: 21 Feb 2002 00:53:38 +0100
Organization: cdegroot.com
Reply-To: squeak-dev at lists.squeakfoundation.org

Bijan Parsia <bparsia at email.unc.edu> said:
>> They redistribute just the parcel, not linked with non-GPL code. Squeak
>> doesn't have such a mechanism (yet),
>
>Change sets?
>
Oops. I'm so into publishing modules and projects over the Net, that I
totally
forgot that you can write a change set to your local drive ;-).

>Can I distribute a bunch of c files, some gpled, some proprietory that
>someone else *can* compile together, that I *intend* for them to so
>compile? They aren't linked at point of distribution.
>
If you make it two tarballs, I think you can.

>While "code" contributions will best, I think, be licensed by Squeak-L, I
>do wonder about "content". I.e., if Squeak is to be a kind of
>"player" for "active content" we should want the widest possible licensing
>possibilities.
>
>Of course, if not being actually loaded in the image at point of
>distribution is sufficent, yay. But image segments seems sorta of like
>DLLs rather than "non-linked" bits. I *clearly* don't know :) And I
>*should* after reading the FAQ :)
>
Well, there are two kinds of image segments - one is just a swap-out, and
I'd
call that linked to the image; the other one is a real export, and that I'd
call not linked to the image. Or?

For the latter one, and that's the stuff that's being published as 'content'
(ugly word...), I'd say pretty much any license will work.

Another thought: in a way, Squeak is an OS and the image is its filesystem.
Now from that POV (I'm not sure whether it would hold up in court, but it's
interesting) try to define linking, derived works, and whatever...


--
Cees de Groot               http://www.cdegroot.com     <cg at cdegroot.com>
GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD  1986 F303 937F E098 9E8B

--__--__--

Message: 5
Date: Wed, 20 Feb 2002 21:14:33 -0500
From: Juan Manuel Vuletich <jmvuletich at sinectis.com.ar>
To: squeak-dev at lists.squeakfoundation.org, tim at sumeru.stanford.edu,
        jmvuletich at sinectis.com.ar
Subject: Re: [updates] 6 for 3.3a (JPEGReaderWriter2.h clash)
Reply-To: squeak-dev at lists.squeakfoundation.org

Hi Tim,

I'm sorry I didn't answer before, I'd missed your message. Please send
with copy to my address if you want to be sure I'll read something.

In fact, I always compiled the plugin in just one directory (the
generated files and libjpeg together).

The updated standard image contains a modification by Andreas to put
libjpeg in a subdirectory. On 6/2 I sent a message to the list with
subject: [FIX] RE: [updates] 6 for 3.3a (JPEGReaderWriter2.h clash). It
contains a changeset to fix a bug in Andreas' modif (and a description
of it).

I really believe the latest standard code should always be in the
updated standard image. So I'd try to avoid preparing a zip with the
"correct" code. The correct code should be in the image. Please take an
updated image, and filein my cs from 6/2. Then read the
JPEGReadWriter2Plugin class comment, and generate the code with
JPEGReadWriter2Plugin translate. The libjpeg files should go in the
subdirectory (as it ways in the class comment). I believe the makefiles
need an update.

Please tell about any problem (cc to me). There should not be any
filename clashing. So, it would be OK for me to put everything in a
single subdirectory, if needed. But then, we should get another cs in
the image, to get where we were before Andreas' cs.

Best Regards,

Tim Rowledge wrote:
>
> I was just attempting to make sure that the SF codebase for
> JPEGReadWriter2Plugin is up to date and I find myself a little confused
> as to the proper state of the files. There has been quite a lot of
> discussion but I couldn't find a message that really seemed to clear it
> up.
>
> Juan, I'd really apreciate it if you could please assemble a directory
> with the files as you believe they should be and zip it and send it to
> me. Then I can compare to the SF files and correct things. If the
> library is intended to be kept in a subdirectory, I imagine there will
> have to be a small tweak to the Mac & unix makefiles.
>
> tim
>
> --
> Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
> Useful random insult:- All booster, no payload.

--
                   Juan Manuel Vuletich
                jmvuletich at sinectis.com.ar
     Español: http://www.sinectis.com.ar/u/jmvuletich
English: http://www.sinectis.com.ar/u/jmvuletich/studio.html


--__--__--

Message: 6
Date: Wed, 20 Feb 2002 19:25:14 -0500
From: Anthony Hannan <ajh18 at cornell.edu>
Subject: [BC][FIX] Block Closures, Version 2 Fix
To: squeak-dev at lists.squeakfoundation.org
Reply-To: squeak-dev at lists.squeakfoundation.org


--Boundary_(ID_CdTgbIEU3RvWMFJ3yzvmyQ)
Content-type: TEXT/PLAIN
Content-transfer-encoding: 7BIT

Finally, with a help from John McIntosh, I figured out what was wrong
with BCv2.  Attached is a changeset you should file-in after
BCInterpreter-ajh.cs.  Don't forget to file-in
CGeneratorEnhancements-ajh.cs as well.  Then build the VM and run the
preconverted BC image (or your own converted image), then file in the
same updates from the BC page.

The bug was in Interpreter>>jumpBack.  I was pre-incrementing localIP
and adding to it in the same line.  I though the order within the line
would dictate to the compiler the correct order, but I guess for most
compilers except mine this was not good enough.  So I seperated the
pre-increment and the add into separate lines, and it worked on John's
machine.

I could not have debugged this without John's help.  He set me up with a
remote login to his machine and walked me through it (via AOL Instant
Messenger).  Cheers to John.

And thanks to the rest of you who tried again and again to get the
version running.  What a great community.

Thankfully,
Anthony

--Boundary_(ID_CdTgbIEU3RvWMFJ3yzvmyQ)
Content-type: application/octet-stream; NAME=BCJumpBackFix-ajh.cs
Content-transfer-encoding: base64
Content-disposition: attachment; filename=BCJumpBackFix-ajh.cs

J0Zyb20gU3F1ZWFrMy4yZ2FtbWFbQkNdIG9mIDE1IEphbnVhcnkgMjAwMiBbbGF0ZXN0IHVw
ZGF0ZTogIzQ3NDNdIG9uIDIwIEZlYnJ1YXJ5IDIwMDIgYXQgNjoxMTo0MCBwbSchDQ0hSW50
ZXJwcmV0ZXIgbWV0aG9kc0ZvcjogJ2J5dGVjb2Rlcycgc3RhbXA6ICdhamggMi8yMC8yMDAy
IDE3OjU2JyENanVtcEJhY2sNDQl8IGRpc3RhbmNlIHwNCWRpc3RhbmNlIF8gc2VsZiBmZXRj
aEJ5dGUuDQlsb2NhbElQIF8gbG9jYWxJUCAtIGRpc3RhbmNlICsgMS4gICJpbmNyZW1lbnQg
aXAgYmVmb3JlIGFjY2Vzc2luZyBpdCINCWN1cnJlbnRCeXRlY29kZSBfIHNlbGYgYnl0ZUF0
OiBsb2NhbElQLg0NCSJObyBjaGVjayBmb3IgaW50ZXJ1cHRzIG9uIGJhY2t3YXJkcyBqdW1w
IGhlcmUsIGFzc3VtaW5nIHRoZXJlIGlzIGF0IGxlYXN0IG9uZSBub3JtYWwgc2VuZCBpbiB0
aGUgbG9vcCwgd2hpY2ggY2hlY2tzIGZvciBpbnRlcnJ1cHRzLiAgSWYgdGhlIGNvbXBpbGVy
IHN1c3BlY3RzIGEgbG9vcCB3aXRoIG5vIG5vcm1hbCBzZW5kcywgaXQgc2hvdWxkIGdlbmVy
YXRlICNqdW1wQmFja0ludGVycnVwdCBpbnN0ZWFkIg0hICENDSFJbnRlcnByZXRlciBtZXRo
b2RzRm9yOiAnYnl0ZWNvZGVzJyBzdGFtcDogJ2FqaCAyLzIwLzIwMDIgMTc6NTUnIQ1qdW1w
QmFja0ludGVycnVwdA0JImZvciBiYWNrd2FyZCBqdW1wcyBpbiBzbWFsbCBsb29wcyB3aXRo
IG5vIHNlbmRzIHRoYXQgd291bGQgY2hlY2sgZm9yIGludGVycnVwdHM7IHNvIGNoZWNrIGZv
ciBpbnRlcnJ1cHRzIGhlcmUiDQ0JfCBkaXN0YW5jZSB8DQlkaXN0YW5jZSBfIHNlbGYgZmV0
Y2hCeXRlLg0JbG9jYWxJUCBfIGxvY2FsSVAgLSBkaXN0YW5jZS4NCXNlbGYgaW50ZXJuYWxR
dWlja0NoZWNrRm9ySW50ZXJydXB0cy4NCXNlbGYgZmV0Y2hOZXh0Qnl0ZWNvZGUuDSEgIQ0N
IUludGVycHJldGVyIG1ldGhvZHNGb3I6ICdieXRlY29kZXMnIHN0YW1wOiAnYWpoIDIvMjAv
MjAwMiAxODowMSchDWxvbmdKdW1wDQ0JfCBoaSB8DQloaSBfIChzZWxmIGZldGNoQnl0ZSAt
IDEyOCkgKiAyNTYuICAia2VlcCBmZXRjaEJ5dGVzIG9uIHNlcGFyYXRlIGxpbmVzIHRvIGF2
b2lkIGFtYmlndWl0eSB3aGVuIHByZS1pbmNyZW1lbnRpbmcgbG9jYWxJUCINCXNlbGYganVt
cDogaGkgKyBzZWxmIGZldGNoQnl0ZSEgIQ0NIUludGVycHJldGVyIG1ldGhvZHNGb3I6ICdi
eXRlY29kZXMnIHN0YW1wOiAnYWpoIDIvMjAvMjAwMiAxODowMSchDWxvbmdKdW1wSWZGYWxz
ZQ0NCXwgYm9vbGVhbiBoaSB8DQlib29sZWFuIF8gc2VsZiBpbnRlcm5hbFN0YWNrVG9wLg0J
Ym9vbGVhbiA9IGxvY2FsRmFsc2UgaWZUcnVlOiBbDQkJaGkgXyAoc2VsZiBmZXRjaEJ5dGUg
LSAxMjgpICogMjU2LiAgImtlZXAgZmV0Y2hCeXRlcyBvbiBzZXBhcmF0ZSBsaW5lcyB0byBh
dm9pZCBhbWJpZ3VpdHkgd2hlbiBwcmUtaW5jcmVtZW50aW5nIGxvY2FsSVAiDQkJc2VsZiBq
dW1wOiBoaSArIHNlbGYgZmV0Y2hCeXRlLg0JXSBpZkZhbHNlOiBbDQkJYm9vbGVhbiA9IHRy
dWVPYmogaWZGYWxzZTogWw0JCQlsb2NhbElQIF8gbG9jYWxJUCAtIDEuICAicmV0cnkgdGhp
cyBqdW1wIGFmdGVyIHJldHVybiBmcm9tIG11c3RCZUJvb2xlYW4iDQkJCW1lc3NhZ2VTZWxl
Y3RvciBfIHNlbGYgc3BsT2JqOiBTZWxlY3Rvck11c3RCZUJvb2xlYW4uDQkJCWFyZ3VtZW50
Q291bnQgXyAwLg0JCQleIHNlbGYgbm9ybWFsU2VuZA0JCV0uDQkJbG9jYWxJUCBfIGxvY2Fs
SVAgKyAyLiAgInNraXAgb2Zmc2V0IGJ5dGVzIg0JCXNlbGYgZmV0Y2hOZXh0Qnl0ZWNvZGUu
DQldLg0Jc2VsZiBpbnRlcm5hbFBvcDogMS4NISAhDQ0hSW50ZXJwcmV0ZXIgbWV0aG9kc0Zv
cjogJ2J5dGVjb2Rlcycgc3RhbXA6ICdhamggMi8yMC8yMDAyIDE4OjAxJyENbG9uZ0p1bXBJ
ZlRydWUNDQl8IGJvb2xlYW4gaGkgfA0JYm9vbGVhbiBfIHNlbGYgaW50ZXJuYWxTdGFja1Rv
cC4NCWJvb2xlYW4gPSBsb2NhbFRydWUgaWZUcnVlOiBbDQkJaGkgXyAoc2VsZiBmZXRjaEJ5
dGUgLSAxMjgpICogMjU2LiAgImtlZXAgZmV0Y2hCeXRlcyBvbiBzZXBhcmF0ZSBsaW5lcyB0
byBhdm9pZCBhbWJpZ3VpdHkgd2hlbiBwcmUtaW5jcmVtZW50aW5nIGxvY2FsSVAiDQkJc2Vs
ZiBqdW1wOiBoaSArIHNlbGYgZmV0Y2hCeXRlLg0JXSBpZkZhbHNlOiBbDQkJYm9vbGVhbiA9
IGZhbHNlT2JqIGlmRmFsc2U6IFsNCQkJbG9jYWxJUCBfIGxvY2FsSVAgLSAxLiAgInJldHJ5
IHRoaXMganVtcCBhZnRlciByZXR1cm4gZnJvbSBtdXN0QmVCb29sZWFuIg0JCQltZXNzYWdl
U2VsZWN0b3IgXyBzZWxmIHNwbE9iajogU2VsZWN0b3JNdXN0QmVCb29sZWFuLg0JCQlhcmd1
bWVudENvdW50IF8gMC4NCQkJXiBzZWxmIG5vcm1hbFNlbmQNCQldLg0JCWxvY2FsSVAgXyBs
b2NhbElQICsgMi4gICJza2lwIG9mZnNldCBieXRlcyINCQlzZWxmIGZldGNoTmV4dEJ5dGVj
b2RlLg0JXS4NCXNlbGYgaW50ZXJuYWxQb3A6IDEuDSEgIQ0N

--Boundary_(ID_CdTgbIEU3RvWMFJ3yzvmyQ)--

--__--__--

Message: 7
From: "Terry Raymond" <traymond at craftedsmalltalk.com>
To: <squeak-dev at lists.squeakfoundation.org>
Subject: RE: Process local variable and debugging
Date: Wed, 20 Feb 2002 09:14:30 -0500
Reply-To: squeak-dev at lists.squeakfoundation.org

> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org
> [mailto:squeak-dev-admin at lists.squeakfoundation.org]On Behalf Of Tim
> Rowledge
> Sent: Tuesday, February 19, 2002 6:45 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: RE: Process local variable and debugging
>
>
> "Terry Raymond" <traymond at craftedsmalltalk.com> is claimed by
> the authorities to have written:
>
> > Ultimately, I think you would find a process faithful
> debugger would be
> > the be solution.  This would also a
> I'd love one. I'll even offer to review the code if you happen to have
> one sitting around in your disk tree :-)

It only takes a couple of days to write the guts.  If you look at the
current
version of VW you will see the technique they used.  Independently,
I arrived at the same basic technique.

Just download the VW NC version and study it.

> tim
>
> --
> Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
> Strange OpCodes: NBRM: Unconditional No BRanch Multiple

Terry

===========================================================
Terry Raymond       Smalltalk Professional Debug Package
Crafted Smalltalk   *Breakpoints* and *Watchpoints* for
80 Lazywood Ln.                  VW and ENVY/Developer
Tiverton, RI  02878
(401) 624-4517      traymond at craftedsmalltalk.com
http://www.craftedsmalltalk.com
===========================================================


--__--__--

Message: 8
Date: Wed, 20 Feb 2002 17:45:35 +0100 (MET)
From: Hannes Hirzel <hirzel at spw.unizh.ch>
To: squeak-dev <squeak-dev at lists.squeakfoundation.org>
Subject: Re: [BUG][Modules] Finding class Project
Reply-To: squeak-dev at lists.squeakfoundation.org



On Wed, 20 Feb 2002, Henrik Gedenryd wrote:

> Hannes Hirzel wrote:
>
> > Hi
> >
> > When trying to find the class Project in the SystemBrowser I get a
> > walkback.
> >
> > The following works
> > TextMorph category  'Morphic-Core-Basic'
> > Project category 'Technology-Support'
> >
> > But not
> > Browser>>selectCategoryForClass: theClass
> >
> > Regards
> > Hannes Hirzel
>
>
> I don't get this error. Also the code in findClass explicitly checks that
> the found definition is a class--it's not like I didn't get this bug
myself
> back in the day ;-)
>
> Browser>>findClass
> <snip>
>     foundClass _
>         Module root allDefinitionsFor: (classNames at: index) asSymbol
>             onlyExported: false detect: [:value :module | value
isBehavior].
>      self selectCategoryForClass: foundClass.
>     self selectClass: foundClass
>
> So what do you do to produce this bug?

I retested it and found out that at the time of writing the [Bug] report
I used Squeak 3.3a-4730. With the version 3.3a-4744 the bug is gone.

Sorry for not giving the change set number in the first place.
You obviously have fixed it meanwhilem. Thanks you!

As I learned from your answer to Alexandre there is a module called
#Project as well as the class called #Project. Do you plan to unify
these two in the future?


Regards
Hannnes Hirzel


--__--__--

Message: 9
Date: Wed, 20 Feb 2002 18:24:22 +0100 (MET)
From: Hannes Hirzel <hirzel at spw.unizh.ch>
To: squeak-dev <squeak-dev at lists.squeakfoundation.org>
Subject: Re: [Modules] Upper case message names for accessing modules
Reply-To: squeak-dev at lists.squeakfoundation.org


Hi Henrik

>
> PS. Can't we find an even more minor issue to debate, to keep us from ever
> dealing with the important stuff?

I agree with the principle that important stuff should be dealt with
first.

But is the question of cross-referencing other classes
unimportant? Probably not. This surfaces rather quicky when looking at
the module system. It is a user interface question (Smalltalk programmer
seen as a user).

There should be a standard answer you could point people at.
(For example: "We don't discuss this anymore because Dan decided this
because of A... and B... explained on the Swiki page X").

There were big discussions last autumn and there is not yet a write
up of what you are finally going to implement. You did some efforts
on the Swiki I read with interest. They helped me. But they are not
fully updated.

Stephane was arguing from the point
of view as a university teacher of Smalltalk who wants to be able to
communicate a concept to students. And that's really a valuable point.

Going further I would say it's not a syntax question but rather a
semantics question if the same literal works in one case as a
message name and in the other case as a module name.


Putting this aside, which important issues do you consider members of the
Squeak list to deal with?

Some suggestions would probably be read with interest.
You have mentioned before that you would appreciate more cooperation of
members of the list. For this to take place a list of open issues
what other people can contribute given the actual state of
documentation would be helpful.

Or you could say that you don't like to be asked questions because
you need more time to concentrate on the implementation of modules.

Regards
Hannes


--__--__--

Message: 10
Date: Wed, 20 Feb 2002 21:05:11 +0100 (MET)
From: Hannes Hirzel <hirzel at spw.unizh.ch>
To: "Hans N. Beck" <HNBeck at t-online.de>
cc: Squeak-Dev <squeak-dev at lists.squeakfoundation.org>
Subject: Re: Best way (morph) for working with pixels
Reply-To: squeak-dev at lists.squeakfoundation.org



On Wed, 20 Feb 2002, Hans N. Beck wrote:

> Hi,
>
> which morph may be the best for the following problem:
> I want to read a picture from file (bmp, gif) and then
> manipulating the picture pixel for pixel, i.E. for
> implementing special picture operations.
>


There is a receipe on the Squeak Swiki
http://minnow.cc.gatech.edu/squeak/1917
Access a jpeg File Pixel by Pixel?

It works with forms. Check out as well

http://minnow.cc.gatech.edu/squeak/697  (Form)

and

http://minnow.cc.gatech.edu/squeak/2191
ThumbnailMorph


An ImageMorph has an instance variable 'image', which can be accessed
with the method #form.

ImageMorph is a subclass of Morph and has 20 subclasses.

Regards
Hannes Hirzel



--__--__--

Message: 11
Date: Thu, 21 Feb 2002 00:10:46 +0100
Subject: Re: MacOS X 3.2 VM updated (CocoaSqueak)
From: Alain Fischer <alain.fischer at bluewin.ch>
To: squeak-dev at lists.squeakfoundation.org
Reply-To: squeak-dev at lists.squeakfoundation.org

Hi Avi,

I have read the description of Seaside on the swiki and it seem=20
promising.
I am impatient to try it. I will have a few question after.

Have a nice day.
Alain


Le Mercredi 20 f=E9vrier 2002, =E0 01:57 , Avi Bryant a =E9crit :

> On Tue, 19 Feb 2002, Alain Fischer wrote:
>
>> I intend to experiment what integration is possible between
>> EOF, WebObjects, Cocoa and Squeak.
>
> You may be interested in Seaside, a WebObjects-inspired framework (but
> with a number of added twists) that will be released for Squeak in the
> next week.  It's pretty easy for WO developers to pick up, although =
the
> lack of a good replacement for EOF in Squeak is sad (so when's someone
> gonna port GLORP?).  If you want more info, feel free to email me=20
> off-list.
>
> Cheers,
> Avi
>
>


--__--__--

Message: 12
Date: Wed, 20 Feb 2002 16:42:27 -0800
To: squeak-dev at lists.squeakfoundation.org
From: Ross Boylan <RossBoylan at stanfordalumni.org>
Subject: RE: [VM] Build report and queries (Unix and Win32)
Cc: ross Boylan <RossBoylan at stanfordalumni.org>
Reply-To: squeak-dev at lists.squeakfoundation.org

At 11:59 PM 2/20/02 +0100, Andreas wrote:
>Lex,
>
> > It's kind of interesting how different platforms are affected by this.
> > Old Unix VM's are perfectly fine with these images, because they just
> > obediently pass on the requested image file to the
> > platform-independent portion of Squeak.  The Windows VM's (and maybe
> > the Mac VM's?) try to do some sanity checking to protect the
> > user from Bad Catastrophic Horrible Bad Things that they couldn't
> > possibly want,
>
>Actually no. What you're seeing is a side effect of an entirely
>different feature - namely that of being able to start Squeak just by
>double clicking on the executable or dropping some project file or
>whatever onto it. In order for this to work, the VM checks if the thing
>you're passing in is a Squeak image file and if not, tries to find one
>on its own.
>
> > and end up being a tiny bit too restrictive. Instead of fixing the
>sanity
> > check, it would be possible to just *remove* the check, but I don't
>remember
> > anyone proposing that kind of solution.
>
>For good reasons. Many (most?) Windows people are used to start
>applications and therefore, if there is a Squeak.exe they will try to
>start it and if it dies for no good reason or gives questionable
>responses (like popping up dialog boxes etc) you've just lost a possible
>user.
>
>Cheers,
>   - Andreas

But the same check is implemented in several different places in the code:
checkImageVersionFromstartingAt in interp.c does it (and this is ultimately
why the image can be read)
SqueakImageLength in sqWin32Window.c does it
IsImage in SqWin32Args.c does it

I just excised IsImage from my source, and replaced the one call to it with
SqueakImageLength()>0 (this is not in the diffs I put out).  So those two
seem redundant.  And I wonder if there's a way to get rid of
SqueakImageLength too.  The failure behavior of checkImage version is
probably no good, but there's some redundancy here it would be nice to
eliminate.



--__--__--

Message: 13
Date: Wed, 20 Feb 2002 16:54:50 -0800 (PST)
From: Avi Bryant <avi at beta4.com>
To:  <squeak-dev at lists.squeakfoundation.org>
Subject: Re: MacOS X 3.2 VM updated (CocoaSqueak)
Reply-To: squeak-dev at lists.squeakfoundation.org

On Thu, 21 Feb 2002, Alain Fischer wrote:

> Hi Avi,
>
> I have read the description of Seaside on the swiki and it seem
> promising.
> I am impatient to try it. I will have a few question after.

Stay tuned.  Looks like the release will be very soon.

Cheers,
Avi


--__--__--

Message: 14
Date: Wed, 20 Feb 2002 19:55:09 -0500
From: Anthony Hannan <ajh18 at cornell.edu>
Subject: RE: Process local variable and debugging
To: squeak-dev at lists.squeakfoundation.org
Reply-To: squeak-dev at lists.squeakfoundation.org

Terry Raymond <traymond at craftedsmalltalk.com> wrote:
> > > Ultimately, I think you would find a process faithful
> > debugger would be
> > > the be solution.  This would also a
> > I'd love one. I'll even offer to review the code if you happen to have
> > one sitting around in your disk tree :-)
>
> It only takes a couple of days to write the guts.  If you look at the
current
> version of VW you will see the technique they used.  Independently,
> I arrived at the same basic technique.
>
> Just download the VW NC version and study it.

I would called the BC debugger "process faithful" because it always uses
"thisContext process".

--__--__--

Message: 15
Date: Wed, 20 Feb 2002 20:18:44 -0500
Subject: Re: quick mac comswiki question
From: Raymond Asselin <raymondasselin at sympatico.ca>
To: squeak-dev at lists.squeakfoundation.org
Reply-To: squeak-dev at lists.squeakfoundation.org


Le Mercredi 20 f=E9vrier 2002, =E0 01:14 , Benoit St-Jean a =E9crit :

> --- Ned Konz <ned at bike-nomad.com> wrote:
>> On Wednesday 20 February 2002 07:20 am, jack wrote:
>> What port did you start it up on?
>>
>> You can start it on port 80, or 8080, or 8081 (as I
>> recall).
>
> In fact, you can use ports 80, 8000, 8080 or 8888 but
> not 8081...
>
> =3D=3D=3D=3D=3D

If you use port 80 with MacOSX  you'll have the message
'the server cannot be located'


--__--__--

Message: 16
Date: Thu, 21 Feb 2002 03:10:28 +0100
From: Stephan Rudlof <sr at evolgo.de>
To: squeak-dev at lists.squeakfoundation.org
Subject: Re: Good Hashing paper
Reply-To: squeak-dev at lists.squeakfoundation.org

Scott A Crosby wrote:
>
> Just found this online. Apparently the origional page is dead, but google
> has cached it.
>
>
http://www.google.com/search?q=cache:lTJRondwlQgC:burtleburtle.net/bob/hash/
doobs.html+hash+hashing+rotate&hl=en

Very nice paper!

>
> Now, do we want to consider using this or something like it for squeak?

Sounds reasonable to me.

>
> BTW, we might be able to make hashing strings and byte arrays go a bit
> faster, by, say, only hashing the first 100 bytes.

There could be a problem: what about a set of byte arrays equal in just the
first 100 bytes?
I'd prefer the slower, but safe version, as default.

And we should use only 31 bits of the 32 bit hash value and return them as
SmallInteger instead of going into the LargeInteger range.


Greetings,

Stephan

>
> Scott

--
Stephan Rudlof (sr at evolgo.de)
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3

--__--__--

Message: 17
Date: Wed, 20 Feb 2002 22:09:56 -0500 (EST)
From: Scott A Crosby <crosby at qwes.math.cmu.edu>
To: Stephan Rudlof <sr at evolgo.de>
cc: <squeak-dev at lists.squeakfoundation.org>
Subject: Re: Good Hashing paper
Reply-To: squeak-dev at lists.squeakfoundation.org

On Thu, 21 Feb 2002, Stephan Rudlof wrote:

> >
> > BTW, we might be able to make hashing strings and byte arrays go a bit
> > faster, by, say, only hashing the first 100 bytes.
>
> There could be a problem: what about a set of byte arrays equal in just
the
> first 100 bytes?
> I'd prefer the slower, but safe version, as default.

Not a problem. Any hash table *has* to deal with two objects, by chance,
hashing to the same value. A conforming hash-code generation
implementaiton can return '42' as the hash code for all objects. (Try it!)

The only requirement is that if 'a=b' then 'a hash == b hash'

By cutting it off at 100, you're assuming that almost all object that are
the same for the first 100 bytes are the same throughout.. Which is IMHO a
fairly safe assumption, and it avoids stupid cases of, say, trying to hash
8kb of email text. :)

Yes, it'll suck if someone has hundreds of strings that differ only on the
101'st byte, but.... Except for a contrived example, where would you see
this? :) [*]

Scott

[*] And even in this case, it may be a win if this is only true for a
small percentage of the strings.  You lose time from slightly more
ineffecient hashing on some strings, but if the strings are 8kb long, you
save a factor of 1.8 on all the other strings because you are spending 80x
less time on computing the hash code. (Normally, you hash, then compare
the entry there for equality, if hashing is 80x cheaper, this cuts the
total time by a lot.)



--__--__--

Message: 18
Date: Wed, 20 Feb 2002 19:52:30 -0800
To: squeak-dev at lists.squeakfoundation.org
From: John M McIntosh <johnmci at smalltalkconsulting.com>
Subject: BLock Closure VM for Mac 3.2.4 (oops 4.x?)
Reply-To: squeak-dev at lists.squeakfoundation.org

I'll right I've posted some 3.2.4 series VM for the mac  that have
Anthony Hannan block closure logic.  Yes now it works for both os-x
and Classic!

http://minnow.cc.gatech.edu/squeak/2119

Mind I think I need to call these 4.x or something? Oh well too late
to change that tonight.
--
--
===========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================

--__--__--

Message: 19
Date: Wed, 20 Feb 2002 22:59:18 -0500 (EST)
From: Scott A Crosby <crosby at qwes.math.cmu.edu>
To: John M McIntosh <johnmci at smalltalkconsulting.com>
cc: <squeak-dev at lists.squeakfoundation.org>
Subject: Re: BLock Closure VM for Mac 3.2.4 (oops 4.x?)
Reply-To: squeak-dev at lists.squeakfoundation.org

On Wed, 20 Feb 2002, John M McIntosh wrote:

> I'll right I've posted some 3.2.4 series VM for the mac  that have
> Anthony Hannan block closure logic.  Yes now it works for both os-x
> and Classic!

What was the secret sauce to get it to work?


Scott


--__--__--

Message: 20
Date: Wed, 20 Feb 2002 23:24:28 -0500
To: squeak-dev at lists.squeakfoundation.org
From: Rob Withers <rwithers12 at mediaone.net>
Subject: Re: [VM] [ENH] [WIN32] Win32 enhancements
Reply-To: squeak-dev at lists.squeakfoundation.org

At 04:01 PM 2/20/2002, you wrote:
>I've attached a file with some modifications to VMMaker-3-2-5 and changes
>to the code on SF (in unified diff format).
>I used these to build a 3.2gamma VM using MSVC.  Note that the changes
>will break the gcc build.  I see this as a way station to getting a proper
>win32 build with multiple directories for internal and external
>plugins.  Rather than get gcc working with the current lame state, it
>seems more useful to define the unlame state and then move MSVC and gcc to
it.

Well done, Ross!   Unfortunately, I can't do MSVC.  It's lame!   Although
the idea of debugging is an interesting one.   hehe :)    Anyway, I would
really prefer if the gcc Makefile is also generated, before we go rolling
these changes into 'official' VMMaker.  Unfortunately, I am in crunch mode
on the job and I just don't have much time.  If you do and are interested,
supporting internal plugins generated to the intplugins directory would be
the last operation to get it not-lame, the antithesis of lame, the goal of
every healthy person in this modern archaic metaworld.

cheers,
Rob


--__--__--

Message: 21
From: "Jim Benson" <jb at speed.net>
To: "Squeak" <squeak-dev at lists.squeakfoundation.org>
Subject: [ENH] Remember window size for tools
Date: Wed, 20 Feb 2002 20:42:11 -0800
Reply-To: squeak-dev at lists.squeakfoundation.org

This is a multi-part message in MIME format.

------=_NextPart_000_0074_01C1BA4F.12330200
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

This changeset remembers the size of SystemWindows for Squeak tools. This
option is available from a SystemWindow from the red halo menu under
'remember this size'.  This changeset includes fixes by Mark Schwenk for
remembering Transcripts and SelectorBrowsers window sizes.

Written and tested for Squeak 3.2 gamma.


Jim Benson

------=_NextPart_000_0074_01C1BA4F.12330200
Content-Type: application/octet-stream;
	name="Remember.2.cs.gz"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="Remember.2.cs.gz"

H4sIAAAAAAAAAL1WbW/bNhD+rA/8D5fsg1sgVfySdIk+LXUXrEWTFXO6AgvcgpZONmuK1EgKjof8
+B0pKVFs930dYEDyvTz33PF4p9650QVM/q6QL0fxcM6LgoPOYXAML7mquFnDsN8fwrXkDq2Dqszo
JYGfjn4+Gk1BK1LDOc7MvSl3cJKMRsnoFMqit8f2xwuu5ggTdEkU/YEFFjM07LnHiaJocAK/p06T
yLsP2FnlFtp4zUtRwDNUVivG3i5QgUWJqcMMck/aLRBWQmV6BQWq6gAKvkQbxGllDCrXqq34B4M8
w5xX8qE81ybouLU6FdzDO61lDGcWuAK84UUp8QB0SQw4TNbWIfEyemXRHIDBgCLcAVlnDUXotWkS
tLAhUG8n6xhCZmtd1QHoxYDCG9cEuosjPGspYVZnYnmBNX9ua6c251ntEcMbi3klQ36SmzlxyYQt
JV/bmLEXKpVVRuVKw+FYmK3hgpslTNLFCtUyYezBseXiZhJS06ahdKayK8OVTY0o3YSYtCkLNX9S
cMvYWZZZ+Ksyc7m78ubeIbC8h7OhlhsBPe3X3Djfnr4Ed8h26XQJpdEfyHx/j7ELnaGEVNKRskgo
67hK8U9uBJ9JvKTK2QR6pcEcqWTZrzfO1406tZOPM8iLb4Bge3XwAqmLM3tOnQy9itiDUA5NzlNq
BEIrSpJ/kDMY9A9Hh77xYfA0GTwlCKGEE1zWmCyijsprIrAZT+SX2l0K+VwncA0Jf60pCNzCO2he
pzGL3oGtyhC/AxvvAXFtydboDyjzNEVr6WQ+xfaI2G5w8vE2RCHUfx8paZJk0WZZ3jeaJseNNtqI
TrcHaaypwEzkArN7HtTFMCQSh2Gu9ftJv/8jzmd03P9leNxnLd9w8d+2M6JD1g+MT1Rp6LuHZ9m4
sk4XF2T8goCoUfm9BOhSZyT5jR4X2pQLSiC0x9f6xWyfjEq/FuI43mdR15jAXgmF8ZaUaGNGo0zy
GUry6wFPndCKForBWrjLx+yYph3HWulnUFwX8TtqeEo1nFVCZrWzJ8GiW+CBzS2RCy/vwT9CIWha
r9rxduXnLHWm74m4ta1TqOcsOOEkfjTxzeJ1/C0qv5hgxtNlx9mLr/QzEm7Y+2UYFskTp+lXFtq6
jp9XTzDV3jvodoQPnV3QWVAXj6W2yKJI5Femov1/vRUrJQs/HDeCjBvxNDifc2l3evsLuNP/zZ1i
2lIkpOD5KBAUduJEulyTtEOvRs0Mn88D6LRRtwTaqB2Lxx63De30nJZLQKZiWPuZ06FFK4FWB6Lq
8PfSSRC21RR2rKXkpcXso/VoVmSqpTYPO8Wiq7tyHHQ+Jf4tt6QeO8H1e6/LCV2XLnTbNX7ahwzr
CUgpFp0FsDXKgxOGP9NmDG4t4y9aqfXIHpzWI3vov0L/55W6+yPisztvi/jwa7brjwz6hYv2X/3e
FI1KDAAA

------=_NextPart_000_0074_01C1BA4F.12330200--


--__--__--

Message: 22
Date: Wed, 20 Feb 2002 23:45:29 -0500
To: squeak-dev at lists.squeakfoundation.org
From: Rob Withers <rwithers12 at mediaone.net>
Subject: [BC2] Windows VM (was: Re: BLock Closure VM for Mac 3.2.4
  (oops 4.x?))
Reply-To: squeak-dev at lists.squeakfoundation.org

I just posted a windows version to the swiki.  Anthony, it runs
great!   Here are my numbers:

>http://minnow.cc.gatech.edu/squeak/2119

bcBytecodesPerSec := 140659340.
bcSendsPerSec := 5252723.

normalBytecodesPerSec := 119514472.
normalSendsPerSec := 3170754.

percentage increase in bytecodes/sec: 17%
percentage increase in sends/sec: 65%

(AMD 1.2Ghz, 256MB)

cheers,
Rob


--__--__--

Message: 23
Date: Wed, 20 Feb 2002 21:00:48 -0800 (PST)
From: Avi Bryant <avi at beta4.com>
To:  <squeak-dev at lists.squeakfoundation.org>
Subject: [ANN] Seaside: Squeak Enterprise Aubergines Server
Reply-To: squeak-dev at lists.squeakfoundation.org


The first public release of the Seaside web application framework is now
available at http://www.beta4.com/seaside.

Thanks to Cees de Groot, there is also a swiki at
http://swiki.squeakfoundation.org/sea, and a mailing list at
http://lists.squeakfoundation.org/listinfo/seaside.

Since this is a beta-quality release, the next link is also an important
one: the Seaside bug tracker is at http://bugs.beta4.com.

-----------

>From the Swiki:
"What's Seaside all about? Major design goals included:

* Complete separation of logic from presentation. Yeah, everybody says
this, but we actually mean it. Seaside templates require absolutely no
extra tags, non-standard attributes, or special syntax. Seaside code
contains no HTML generation or HTTP request processing. Period.

* Flexible application control flow. The HTTP request/response loop
generally imposes a restrictive control flow model onto web applications:
in essence, every move from page to page is a GOTO. Seaside uses
continuations and coroutining to graft traditional smalltalk send/return
control flow onto the web. As a bonus, it throws in backtracking and
transactions.

* Reuse by composition. Every page, navbar, or widget developed in Seaside
can be embedded into any other page, and dynamically configured to adjust
to its enclosing context. Extensions and replacements for standard form
elements can be transparently dropped in without even changing the
template, and megawidgets like trees and tabs can be shared and reused.

* Smooth interaction with the web browser. The web browser is an imperfect
platform, and many web applications cope with this by restricting users to
a certain subset of browser functionality: the back button cannot be used,
javascript and cookies must be enabled, and so on.  Seaside tries to be as
browser-friendly as possible by not depending on anything but basic HTML
and HTTP, while supporting the browser interactions users expect from the
web. Of particular note are the backtracking features, which use snapshots
of state and continuation wizardy to transparently rewind and replay
portions of methods in response to the dreaded browser back button.
Seaside also provides a "safe browsing"  feature which ensures that page
reloads occur without unwanted reposts and side effects."

------------

Beta4 Productions <http://www.beta4.com>
Avi Bryant <avi at beta4.com>
Julian Fitzell <julian at beta4.com>



--__--__--

Message: 24
Date: Wed, 20 Feb 2002 23:51:41 -0500
From: Doug Way <dway at riskmetrics.com>
To: squeak-dev at lists.squeakfoundation.org
Subject: Re: Namespaces - Importing versus Explicit Naming (was Re:
[Modules]
 Upper
Reply-To: squeak-dev at lists.squeakfoundation.org


Cees de Groot wrote:
>
> Doug Way <dway at riskmetrics.com> said:
> >The Java project I'm working on strictly uses approach B.  There are *no*
duplicate classnames among 1000 or so classes across many packages in the
app.  A few imported classnames from other frameworks conflict, but very
rarely.  (Two different external packages each had their own implementation
of a Date object, which was confusing.)
> >
> Just to add a data point: in my current VW project, with some 400 classes
and
> no 'thou shall not make up duplicate names' rule, we have one duplicate
name
> and that has attended us to the fact that the name in fact was a bad name
for
> both classes (FooBarProcessor, 'Processor' being much too
> abstract/generic/whatever). In Java, I used to have similar metrics.

Actually, I should correct my earlier point a bit... we do have one case of
duplicate classnames.  Each of our packages/modules has a class called
TestCase which handles unit tests.  This class name is the same for all
packages.  This sort of name duplication makes sense, though, since it's a
class that performs the same function for every package.

- Doug Way
  dway at riskmetrics.com

--__--__--

Message: 25
Date: Wed, 20 Feb 2002 20:55:54 -0800
To: squeak-dev at lists.squeakfoundation.org, Stephan Rudlof <sr at evolgo.de>
From: Martin McClure <martin at hand2mouse.com>
Subject: Re: Good Hashing paper
Cc: <squeak-dev at lists.squeakfoundation.org>
Reply-To: squeak-dev at lists.squeakfoundation.org

At 10:09 PM -0500 2/20/02, Scott A Crosby wrote:
>On Thu, 21 Feb 2002, Stephan Rudlof wrote:
>
>>  >
>>  > BTW, we might be able to make hashing strings and byte arrays go a bit
>>  > faster, by, say, only hashing the first 100 bytes.
>>
>>  There could be a problem: what about a set of byte arrays equal in just
the
>>  first 100 bytes?
>>  I'd prefer the slower, but safe version, as default.
>
>Not a problem. Any hash table *has* to deal with two objects, by chance,
>hashing to the same value. A conforming hash-code generation
>implementaiton can return '42' as the hash code for all objects. (Try it!)
>
>The only requirement is that if 'a=b' then 'a hash == b hash'
>
>By cutting it off at 100, you're assuming that almost all object that are
>the same for the first 100 bytes are the same throughout.. Which is IMHO a
>fairly safe assumption, and it avoids stupid cases of, say, trying to hash
>8kb of email text. :)
>
>Yes, it'll suck if someone has hundreds of strings that differ only on the
>101'st byte, but.... Except for a contrived example, where would you see
>this? :) [*]

Well, you'd think so, but beware. I can't think of a non-contrived
example, but just because I can't readily see a real-world example
doesn't mean there isn't a common one. Folks have been tripped up by
this before.

Java 1.1 only hashed part of Strings (something like the first 15
chars and the last 15 chars). They obviously didn't expect to see too
many different Strings that were identical at both the beginning and
the end. Turned out that they had horrible performance on collections
of URLs. In Java 1.2, the whole string was hashed, no matter how long.

This change made me do some quick scrambling at GemStone, since I had
to make sure that 1.1 hashed collections could be migrated to 1.2....

-Martin

--__--__--

Message: 26
Date: Wed, 20 Feb 2002 21:13:01 -0800
To: squeak-dev at lists.squeakfoundation.org
From: Ross Boylan <RossBoylan at stanfordalumni.org>
Subject: Re: [VM] [ENH] [WIN32] Win32 enhancements
Cc: ross Boylan <RossBoylan at stanfordalumni.org>
Reply-To: squeak-dev at lists.squeakfoundation.org

At 11:24 PM 2/20/02 -0500, you wrote:
>At 04:01 PM 2/20/2002, you wrote:
>>I've attached a file with some modifications to VMMaker-3-2-5 and changes
>>to the code on SF (in unified diff format).
>>I used these to build a 3.2gamma VM using MSVC.  Note that the changes
>>will break the gcc build.  I see this as a way station to getting a
>>proper win32 build with multiple directories for internal and external
>>plugins.  Rather than get gcc working with the current lame state, it
>>seems more useful to define the unlame state and then move MSVC and gcc to
it.
>
>Well done, Ross!   Unfortunately, I can't do MSVC.  It's lame!   Although
>the idea of debugging is an interesting one.   hehe :)    Anyway, I would
>really prefer if the gcc Makefile is also generated, before we go rolling
>these changes into 'official' VMMaker.  Unfortunately, I am in crunch mode
>on the job and I just don't have much time.  If you do and are interested,
>supporting internal plugins generated to the intplugins directory would be
>the last operation to get it not-lame, the antithesis of lame, the goal of
>every healthy person in this modern archaic metaworld.
>
>cheers,
>Rob

The source code changes are distinct from the VMMaker changes, so perhaps
they could go in sourceforge?  Preferably after somebody reviews them.

I have trouble following your last sentence.  Does it mean doing internal
plugins would come after external plugins, or just that it is a nice goal?

I agree that in its current state the changes to VMMaker (Win32VMMaker
actually) should not go into the baseline, since they break gcc
builds.  However, if you're suggesting tweaking it so the appropriate
makefile for gcc gets spit out, I think that's not worth it, since that
would all be scrapped when we move to separate directories.  I think it
would be better to get both MSVC and gcc working with the separated
directories to spare wasted effort.



--__--__--

Message: 27
Date: Thu, 21 Feb 2002 00:22:06 -0500
From: Doug Way <dway at riskmetrics.com>
To: squeak-dev at lists.squeakfoundation.org
Subject: Re: [Modules] Upper case message names for accessing modules
Reply-To: squeak-dev at lists.squeakfoundation.org


Frank Sergeant wrote:
>
> ducasse <ducasse at iam.unibe.ch> wrote:
>
> > For ellipse := (Module path: #(Squeak Morphic Core Basic)
> >                      class: #EllipseMorph) new
> >
> > this could be better
> > as
> >     ellipse := (Module class: #EllipseMorph inPath: #(Squeak Morphic
Core
> > Basic) new
> >     because we are interested in the class
> >
> > Or we can have something new to refer to class in namespace
>
> Are you and/or the other module people saying that with a modularized
> Squeak system, everytime we wish to refer to a class that is in a
> module, we would need to use something like one of the above examples?
> I hope I have misunderstood!  I think that would be horrible.

Well, I mostly agree, but explicit module path naming wouldn't necessarily
have to be used most of the time, which is what my (long-winded)
"Namespaces..." post was about yesterday.  You could import names from other
modules by default, or something similar, and then you would use the usual
"ellipse := EllipseMorph new".  In the hopefully unusual case of an actual
name clash, you would need to use something like one of the above examples,
though.

(Or not exactly like the above, the other alternative was "ellipse := Squeak
Morphic Core Basic EllipseMorph new".)

- Doug Way
  dway at riskmetrics.com

--__--__--

Message: 28
Date: Thu, 21 Feb 2002 06:39:00 +0100
From: Stephan Rudlof <sr at evolgo.de>
To: Scott A Crosby <crosby at qwes.math.cmu.edu>
CC: squeak-dev at lists.squeakfoundation.org
Subject: Re: Good Hashing paper
Reply-To: squeak-dev at lists.squeakfoundation.org

Scott A Crosby wrote:
>
> On Thu, 21 Feb 2002, Stephan Rudlof wrote:
>
> > >
> > > BTW, we might be able to make hashing strings and byte arrays go a bit
> > > faster, by, say, only hashing the first 100 bytes.
> >
> > There could be a problem: what about a set of byte arrays equal in just
the
> > first 100 bytes?
> > I'd prefer the slower, but safe version, as default.
>

> Not a problem. Any hash table *has* to deal with two objects, by chance,
> hashing to the same value. A conforming hash-code generation
> implementaiton can return '42' as the hash code for all objects. (Try it!)

I know (without trying ;-) ).
'Safe' possibly is to hard here: I mean a good distribution of hash values
for *every* case, pathological cases included.

>
> The only requirement is that if 'a=b' then 'a hash == b hash'
>
> By cutting it off at 100, you're assuming that almost all object that are
> the same for the first 100 bytes are the same throughout.. Which is IMHO a
> fairly safe assumption, and it avoids stupid cases of, say, trying to hash
> 8kb of email text. :)

BTW: If you are hashing e.g. 8kb mail messages it takes much more time to
read them from disc than for hashing...

>
> Yes, it'll suck if someone has hundreds of strings that differ only on the
> 101'st byte, but.... Except for a contrived example, where would you see
> this? :) [*]

There may be other byte arrays to be hashed, e.g.:
- images where the pixels in the beginning are equal,
- numbers between 2 different very LargeIntegers;
you get the idea.

>
> Scott
>

> [*] And even in this case, it may be a win if this is only true for a
> small percentage of the strings.  You lose time from slightly more
> ineffecient hashing on some strings, but if the strings are 8kb long, you
> save a factor of 1.8 on all the other strings because you are spending 80x
> less time on computing the hash code. (Normally, you hash, then compare
> the entry there for equality, if hashing is 80x cheaper, this cuts the
> total time by a lot.)

An idea: what about a hash function with your limit as argument (or none/nil
for the default case)?


Greetings,

Stephan
--
Stephan Rudlof (sr at evolgo.de)
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3

--__--__--

Message: 29
Date: Thu, 21 Feb 2002 01:04:18 -0500
From: Doug Way <dway at riskmetrics.com>
To: squeak-dev at lists.squeakfoundation.org
Subject: Re: [Modules] Upper case message names for accessing modules
Reply-To: squeak-dev at lists.squeakfoundation.org


Henrik Gedenryd wrote:
>
> >> For ellipse := (Module path: #(Squeak Morphic Core Basic)
> >> class: #EllipseMorph) new
>
> Everyone seems to miss the fact that Module is also defined in another
> module, so you wouldn't be able to write code like this! So how do you
then
> make _any_ reference to something outside your own module? (It's not
> impossible.)
>
> That's why I said there is a bootstrapping issue here.

Ah, so only the toplevel module names will be globally accessible, then?
(such as "Squeak", "People", "Com", "Org", etc.)

Makes sense.  It's easy to forget that "Module" won't be available, since we
currently have the weak modules thing running, and it is available now.
(Hmm, also http://minnow.cc.gatech.edu/squeak/2252 uses "Module" in its
examples to access modules.)

So, I guess if someone were looking for an alternative to the upper-case
messagename convention to access a module, you'd need to have a
#subModulePath: method or similar, such as:

ellipse := ((Squeak subModulePath: #(Morphic Core Basic)) class:
#EllipseMorph) new.

> PS. Can't we find an even more minor issue to debate, to keep us from ever
> dealing with the important stuff?

I'd think of this as a prelude to future discussions about the other
"important stuff".  This debate could help people to start thinking about
how modules will work in Squeak.

But I wouldn't consider adding a new message name convention (upper case) to
be unimportant, and it hasn't really been discussed at all until the last
few days.

- Doug Way
  dway at riskmetrics.com

--__--__--

Message: 30
Date: Thu, 21 Feb 2002 00:43:43 -0400
Subject: RE: [VM] Build report and queries (Unix and Win32)
To: squeak-dev at lists.squeakfoundation.org
From: "Lex Spoon" <lex at cc.gatech.edu>
Reply-To: squeak-dev at lists.squeakfoundation.org



> > and end up being a tiny bit too restrictive. Instead of fixing the
> sanity
> > check, it would be possible to just *remove* the check, but I don't
> remember
> > anyone proposing that kind of solution.
>
> For good reasons. Many (most?) Windows people are used to start
> applications and therefore, if there is a Squeak.exe they will try to
> start it and if it dies for no good reason or gives questionable
> responses (like popping up dialog boxes etc) you've just lost a possible
> user.
>

Hey Andreas, there's this company "Microsoft".  I think you would really
enjoy the line of operating systems they sell. :)

I prefer dumb software that just does what I ask.  Smart software can
ease things along sometimes, but on the other hand, when it messes up,
smart software can be harder to debug and fix.

But, we all have our preferences.  MS Windows and autoconf both really
irritate me, but both have huge followings who rave about how smart they
are.


-Lex

--__--__--

Message: 31
Date: Thu, 21 Feb 2002 01:11:27 -0400
Subject: Re: Good Hashing paper
To: squeak-dev at lists.squeakfoundation.org
From: "Lex Spoon" <lex at cc.gatech.edu>
Reply-To: squeak-dev at lists.squeakfoundation.org



> >By cutting it off at 100, you're assuming that almost all object that are
> >the same for the first 100 bytes are the same throughout.. Which is IMHO
a
> >fairly safe assumption, and it avoids stupid cases of, say, trying to
hash
> >8kb of email text. :)
> >
> >Yes, it'll suck if someone has hundreds of strings that differ only on
the
> >101'st byte, but.... Except for a contrived example, where would you see
> >this? :) [*]
>
> Well, you'd think so, but beware. I can't think of a non-contrived
> example, but just because I can't readily see a real-world example
> doesn't mean there isn't a common one. Folks have been tripped up by
> this before.
>

Well, any data with a constant header on it.  For example, a lot of C
files will have big README's in the comments saying what the file is
part of.  Also, email messages in fact tend to have quite a few bytes at
the beginning that are at least very similar, if not exactly the same.
Oh I dunno, it's just that, when it bites, it will bite hard!


Anyway, if we could all step away from the micro-optimization for a
moment, consider this cool alternative: cache the hash.  This was
described either here or on comp.lang.smalltalk, I don't remember.
Anyway, the idea (and the guy had implemented it, in a different system)
is that once the hash has been computed, store it in an instance
variable.  Then, whenever an at:put: or replace:from: or whatever else
happens that changes the characters in the string, update the hash.  And
that's it!

In this scheme, #hash itself is of course extremely fast, and the hash
value is sensitive to the entire string's contents.  You do pay some
overhead on update operations, but I'd guess it's only a small constant
overhead in most cases: "is hashCache nil?  yes."  But even the worst
case is still linear in the number of characters being updated.

Pretty neat, scheme, isn't it?  I bet there aren't even all that many
update operations in String, because most should be defering to at:put:
or replaceFrom:to:with:startingAt:.  A tricky bit, sadly, is figuring
out where to stash the hash value; I don't think you can just add an
instance variable to String, can you?


-Lex

--__--__--

Message: 32
Date: Wed, 20 Feb 2002 22:24:44 -0800
To: squeak-dev at lists.squeakfoundation.org
From: John M McIntosh <johnmci at smalltalkconsulting.com>
Subject: Pending mac vm 3.2.4 (need a tester or two)
Reply-To: squeak-dev at lists.squeakfoundation.org

Morning (is it' morning yet)

Ok I"m looking at os-9 packages, (see below) However I need one or
two people to try the VM before I commit to doing this.
This means I need someone who has both os-9, os-x, and say (ok three
operating systems) os-8.x of some form. Although I've a few machines
here in my lab to play with it's always better to have someone else
confirm I've done things correctly.

Please email me and I'll email back an application to try.

Feb 20th 2002 3.2.4

For this version of the VM I have migrated towards using OS-9 packages.
This allows us to provide one folder/package that supports os-x and
previous operating system versions.

Given Squeak 3.2.4Beta1.app
The classic VM is found in the *.app:Contents:MacOSClassic, with an
alias in *.app:
The mach-o OS-X VM is found in *.app.Contents:MacOS

If you are running OS-9 then clicking on the *.app or doing drag and
drop will just run Squeak, same applies for OS-X.
If you are running OS-7.5.5 or OS-8.x then the *.app package will
appear as a folder, just open and click on the alias within.
Note that if you want to use classic plugins I suspect you need to
put them in the MacOSClassic Folder beside the VM.
Bundles for os-x go in the same location as the *.app application package.

Changes
a) Drag and drop at open time with image file that has no meta type,
will now open the image, versus prompting you.
b) Use an os-x window attribute at open time to signal that the
window should not be moved by the dock when you go to full screen.
c) Fix window update logic to use window that needs updating versus
stWindow to fix issues with print dialog windows in classic.
d) bitblt gets recompile to pickup fixes posted in 3.2 update stream.

--
--
===========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================

--__--__--

Message: 33
Date: Thu, 21 Feb 2002 01:25:44 -0500
From: Doug Way <dway at riskmetrics.com>
To: squeak-dev at lists.squeakfoundation.org
Subject: Re: [Modules] Upper case message names for accessing modules
Reply-To: squeak-dev at lists.squeakfoundation.org


ducasse wrote:
>
> on 18/02/02 7:42 PM, Hannes Hirzel at hirzel at spw.unizh.ch wrote:
> > (B)
> > ellipse := Module Squeak Morphic Core Basic EllipseMorph new.
>
> With B How do I distinguish between module and classes.
> May be we should not, but in such a case why Module is needed?

Actually, "Module" should not be in the expression above, that looks like a
typo.  It should be:

ellipse := Squeak Morphic Core Basic EllipseMorph new.

You can actually try this right now in a workspace in 3.3alpha and it will
work.

Beating this thread into the ground a bit, I suppose if you were looking for
a convenient way to access classnames with a module path, and you didn't
want to use the upper-case messages, you could add a method to Array so that
you could do something like:

ellipse := #(Squeak Morphic Core Basic EllipseMorph) classFromModulePath
new.

Or ellipse := (#(Squeak Morphic Core Basic) moduleWithClass: #EllipseMorph)
new.

Yes, it's purely a convenience method, but for something as basic as
referencing a class, convenience *is* very important.

- Doug Way
  dway at riskmetrics.com

--__--__--

Message: 34
Date: Thu, 21 Feb 2002 09:04:28 +0100
Subject: Re: MacOS X 3.2 VM updated (CocoaSqueak)
From: Marcel Weiher <marcel at metaobject.com>
To: squeak-dev at lists.squeakfoundation.org
Reply-To: squeak-dev at lists.squeakfoundation.org

Hello Alain!

Nice to see Sente on the Squeak list as well :-)

On Tuesday, February 19, 2002, at 09:29 PM, Alain Fischer wrote:

> I have seen your Objective-C bridge in CocoaSqueak and it seem very
> interesting to do dynamic programming with all the frameworks.
> Have you some example how to use it ?

There are some trivial examples in the ChangeSet.  I don't

> I have your change set "Objc-Bridge.12Aug1015am.cs" and "Objective-C
> Tr.7.cs",
> is it those who are are used to generate the Objective-C bridge ?

Only the Objc-Bridge is needed.  It implements the image side of the
bridge.  The VM side of the bridge is a fixed part of the CocoaSqueak VM.

  Objective-C Tr. adds an option to generate the whole interpreter as an
Objective-C class.  It even runs for a couple thousand bytecodes before
crashing ;-)

> And the rest of the VM ?

CocoaSqueak.

> They appear to be old:

Yes.  It worked for what I tried, and I haven't actually done much with
it since.

> 'From Squeak 2.4b of April 23, 1999 on 12 August 1999 at 10:15:53 am'!
> 'From Squeak2.9alpha of 13 June 2000 [latest update: #2710] on 19
> January 1969 at 3:14:07 am'!
> Have you some new versions ?

Nope.

> I intend to experiment what integration is possible between
> EOF, WebObjects, Cocoa and Squeak.

I think the main issue you will see is calling back into Squeak,
although I am  now working on some simple mechanism for that.

Take care,

Marcel
p.s.:  say hello to Marco


--__--__--

Message: 35
Date: Thu, 21 Feb 2002 09:47:27 +0100
Subject: Re: [BUG][Modules] Finding class Project
To: squeak-dev at lists.squeakfoundation.org
From: goran.hultgren at bluefish.se
Reply-To: squeak-dev at lists.squeakfoundation.org

Hannes Hirzel <hirzel at spw.unizh.ch> wrote:
> As I learned from your answer to Alexandre there is a module called
> #Project as well as the class called #Project. Do you plan to unify
> these two in the future?

These are two different beasts altogether. Well, this is my take anyway:

The module Project is a toplevel module for organizing all the modules,
the others
are Squeak, People, Org, Com etc. So if there is a project which is not
a personal project (People)
and which has no organization behind it (Org, Com) and which isn't in
base Squeak (Squeak) then...
Say... Comanche? Comanche or other addons/applications are "projects"
and would fit in that module.

The class Project on the other hand is, well, you know what that is of
course.

regards, Göran

--__--__--

Message: 36
Date: Thu, 21 Feb 2002 09:54:52 +0100
Subject: Re: [Modules] Upper case message names for accessing modules
To: squeak-dev at lists.squeakfoundation.org
From: goran.hultgren at bluefish.se
Reply-To: squeak-dev at lists.squeakfoundation.org

Ok, more fuel on the fire:

Why not just add an optional literal syntax? Dots are already taken so
why not $:?

ellipse := #(Squeak Morphic Core Basic EllipseMorph) classFromModulePath
new.
ellipse := Squeak:Morphic:Core:Basic:EllipseMorph new.

It would just be sugar of course.

regards, Göran

--__--__--

Message: 37
From: "Jim Benson" <jb at speed.net>
To: "Squeak" <squeak-dev at lists.squeakfoundation.org>
Subject: [ENH] Obey Colors
Date: Thu, 21 Feb 2002 00:59:09 -0800
Reply-To: squeak-dev at lists.squeakfoundation.org

This is a multi-part message in MIME format.

------=_NextPart_000_00D2_01C1BA72.F818D6A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

This changesets places the PackagePaneBrowser and MessageName search tool in
the window color preference panel.

Tested under Squeak 3.2 gamma.

Jim Benson

------=_NextPart_000_00D2_01C1BA72.F818D6A0
Content-Type: application/octet-stream;
	name="ObeyColors.1.cs.gz"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="ObeyColors.1.cs.gz"

H4sIAAAAAAAAAN1ZX2/bOBJ/1oO+w8R9cAx0vY6TdPech2ucXm67lzRBnTY4BLmAlmibG4pUSSmp
F/3wN0NKlmTLSQ67BQ4roKnFGc4/zm84pLqnRicw+ZJzdr/fH85ZkrCb8ckt6BnsHcKvTOXMLGE4
GAzhRrKM2wzyNMYfI3h18NPBPnIqGO7BKZ+aipVlsDccHR6OkMKS7k7YOVkwNecw4dkoCC6mfHmi
pTY2fEeigiBYFxEe59lCGyL9KhIYc2W1CsNzds8hW3A459ayOUd5MDX6kRtgKoZLFt3j6CVTfIyj
Foc16nIzHoWK9SNEpFeoOdhowRNu+zDW2YL8RSZLbFKCQka7wD95CkJtTIfU8Bk3XEUcUtQl4Sg8
lla/hljj3AyYlMjbmBILJvUcMg1TnCSiex6T9OkSIolvZFFTEwnuhGEHLiWLvNNOkkU+lPKUTbGI
MqEVxRIlfCv4XMTfIQm+hWGwuz54B5crCRa1G5bwjJvjDFe6xmt7IGYfdPZByBHchMGGcEYTiuX5
gDJQVo5Du44DzAgG/TcHhzAfwV5/AFN6Pzgc9jCEQeDmbi5isCaBJtbnv+n14bYf7oRhuFN3IpLM
WkA3Fjq2p5hN0K2HzHbBZixJcfg3OYXhj8PBjy59h/ujgzeYtUIhXcqxEfNFdl2LQRh06nq28nXC
oC36we5lGV6aHMk85vZffNkS6VMmLR9haG5qU9j6mvgQv4+5ykS2fFctv+KPGJigZa2fkNbH9Hi1
G+yW0cdHkmf/NJyrHtqy69F8Jmy2Io5lzmu0iTaZm9okvuPTfD6vyfzIY0/ImWzObE48FZKfaJWh
h3ZlV8bUilga4+edYwKpjDlqVSo2jb2Y/sYjP+9xITI/OOESB7Wp/HeTTpaFuklGBeQXLeOK+G9O
kHfkK8OUjYxIM2TkLCk4Lgx5RxzQwwDHmlY1uBmlTBjKCTKhBUqOPBMGC28dBSk3M22Sgo55nvVu
ad06wOK4SDmLRQIr8YI9cEi04YAx4YbJso50wuD/A7w7sPNHkbvnkTsYjAb7FXIvMS5cPo/cTb6/
DHJTJvk24BJtG24btDpsH7hZXiJxO3IbU1uBSxxXbeAlwnbsNgS/ELo055KzaNEGXSI+iVxiKID7
3UD73TE73HOIHR78jRBHb84j/Hl4+D9BlyTUBe3XBeH++8dhXNuAf6pg/EkJitvzOG5h/MsAuUry
JojXx1cIrgh1+NZGN4Bb0VpR2ySvMFsNN9Fajb8QqjVaE6YVYROhG9odBOrjLYcCT/xOiP5zcbBP
21nNohMSxTH//wOvVukBtZSA+prCaulhfbmhbY1htbK1A9baSkF9dWB9RaBRiVpi3/tTd/v9g1V4
JimPxExEjJBHGiUViZwOrMCKcxouFljHt6QTV0NLJ1wrKtvEupLC3E+Y5lmm1UcUwsbuJzD3Mnlk
WbQA5tOE+YoE7Fwoca2NjCnVChF3cIwNokpwHc61SRdUMXBanihYfORW/I6WYnmwC4z6/bVh6RE8
tI9j9kq21Hn2Xlk8aGNzFa604BbjpGPqVja3qf5YBgQ5C/PvwP+P/Ta4XpabHtb7IAxq7sexSwU8
OKK0SYpnVnMxm4jfaXt4i5Y0eZ26MWYHapmIJMWN3ZFXZiCYphyPmN2/d49QsZmTQ5bL2REwV1vL
rGxWzl+4xPig92M6g2t1xb/ivO4JnbHd6qML/GsqmXLr6c/9wvr0QE2F595fanU+478zf/phyyPA
6Bqyotd/qfM/O+epmHf9AbELwdYDY7B03YgrQ0H3E95HIKOKmYnxmoOYyz7AuYI3FUXX0O+6Utf1
jWw3CLY2tvUWq01N6mY8o+aa6mc32L7rFvW3psC9wxRXfG50ruJK9kp1paQHVJdpyx19yVns63IJ
sLttGVPPkp5TXeSQk+GK95EbXk8gR7c80ir2DGX++zRwb6d4UVZwYsKYuOc51zPNq8IkyRaeoUyY
Pr1tg0Dh2ibP1qzaG7wduAMfyYbN/QH8xnYzYm6AqjF8AxfGFwDf496ZU1ayogYUb8juvGsA043g
azsyqa57FtxAaywYwesmV6YLRhSek4lkUOmFp2Cs3fjuwQDe4oVhryXYrB5nXD4nx9vfoG+N8e7e
EIXv9TallYXLbYQ+gFGxk9ZtxUQgpZQZk2wp8WKOz1gus1McLqQ2i3ORDajKrS1MEswthNg9COsY
RBTC2iNmVybH/hS2PDcvLve1VX9pGg4PXXULGvB8Hp1rUxpFlzaZJI8WZ36jWWMtd4VP7hIarrSW
Fk4lS7F2e85VTtKobdktDE/pRtVNJZ42h7dgs7JjY4fBxgF7mAX2DnTHm/o7W2cdVj5ETG79HS6b
6ofy5vYHf3MbLbSgfqO62PVuzci4bqm4LVNWNlO2OK6i0bgr+5NH7AtSHr9XnnAtssWVyCQuXbdg
9QW7VNPBwqG65Q127ZL56YtrK2JOZ9OapVphrBONfr/TjxQwFeNAiVCUNypsLDS70Sg3lGS+RSp9
PcERjCtOL9zrN52lFX7AbDhWMZaPiJ9RjlzpCV3g37bgpTjQbQXMbq1Nu4PzzyfX4tptpJ/SVTo7
Kmq7NJrONiNQQvaKBKxardJB2P7UdOFGaLBQ8DTFoE7yaUJC7MXseTlOnRPyWSDUdMrVBYa/kv2U
Be4pcdVMimenlXW45sUsx8bG7/Ceeusa/paTgOEJYqGGzKI8jldNgjNjJ2wcKV48q3OpbeaPJqPw
jNONCuWzFKpA4Wv3zagoB45m6PtW2RJGOqFKSZnOCL7oGCY174f/+MqjPGNT6dqmjBOXpe9FObmv
C+RUErweTw8RRJbT15UMcYSi8QQp8NTzGnGGn6GUxqDhcSjx3WmqBYne3dnB7WKMM/OivOCphqkl
xhr7DG5KRXSTgfjN0bIfvuQav9a9RnfdFzO0hmzv0EeS/wLYCEsf9RsAAA==

------=_NextPart_000_00D2_01C1BA72.F818D6A0--


--__--__--

Message: 38
Date: Thu, 21 Feb 2002 10:00:03 +0100 (MET)
From: Bruce O'Neel <beoneel at bluewin.ch>
Subject: stanford mouse video archive
To: the Squeak list <squeak-dev at lists.squeakfoundation.org>
Reply-To: squeak-dev at lists.squeakfoundation.org

I think that this might interest some of you:

http://slashdot.org/article.pl?sid=02/02/20/0846238
--
Of course it runs NetBSD

Bruce O'Neel                       phone:  +41 22 950 91 57
INTEGRAL Science Data Centre               +41 22 950 91 00 (switchb.)
Chemin d'Ecogia 16                 fax:    +41 22 950 91 33
CH-1290 VERSOIX                    e-mail: Bruce.Oneel at obs.unige.ch
Switzerland                        WWW:    http://isdc.unige.ch/


--__--__--

Message: 39
Date: Thu, 21 Feb 2002 10:04:08 +0100
Subject: Re: [Modules] Upper case message names for accessing modules
To: squeak-dev at lists.squeakfoundation.org
From: goran.hultgren at bluefish.se
Reply-To: squeak-dev at lists.squeakfoundation.org

Hannes Hirzel <hirzel at spw.unizh.ch> wrote:
[SNIP]
> Putting this aside, which important issues do you consider members of the
> Squeak list to deal with?

Peace brothers! :-)

Henrik is just a bit frustrated over the fact that there are so many
important things we need to resolve and apart from Henrik we all have
some serious studying to do before we can really help.

I am personally focusing on the "minimal meta info" (please respond to
my earlier post on that because it is IMPORTANT) and cataloging problem.

regards, Göran

--__--__--

Message: 40
Date: Thu, 21 Feb 2002 10:18:26 +0100
Subject: Re: [Modules] Upper case message names for accessing modules
To: squeak-dev at lists.squeakfoundation.org
From: goran.hultgren at bluefish.se
Reply-To: squeak-dev at lists.squeakfoundation.org

Ok, apart from how we syntactically write direct references in the
module system I would envision this:

1. Imports are made on module level. We already have that - the neighbor
modules. I think.
2. If you type a direct reference in the code it would generate an
automatic neighbor module reference on compile. It would of course barf
if that module is not loaded (it doesn't have to be active, right?).
3. If you type a non direct reference like "EllipseMorph" then I would
like it to:
	1. If there is already ONE and ONLY ONE neighbor module exporting
EllipseMorph then do nothing. All is fine.
	2. If there are two or more neighbor modules exporting EllipseMorph
then barf and ask user to make a direct reference using whatever
syntactic means there are for that. :-)
	3. If there are no neighbor modules exporting EllipseMorph, find it
among all loaded modules and if there is ONLY ONE - add that module as a
neighbor. Ask user for confirmation. This could be a Preference.
	4. If there are more than one loaded module exporting EllipseMorph, ask
which one should be added as a neighbor.

The problem I see with all this is that we can not guarantee that the
non direct references are ok. If I add a neighbor module which also
exports EllipseMorph - which one does the old method reference now? That
could on the other hand be checked by the system - when we add neighbors
we could crosscheck the exported names and if there are overlaps we
could check if those names are referenced in the methods of the class
and if they are then we need to ask the user to either abort adding the
neighbor or change the references into direct references.

Phew.

Well, whatever, perhaps I am "out bicycling" as we say in Sweden. :-)

regards, Göran

PS. One "value" I like is to be able to just type EllipseMorph and that
would be ok. I want Squeak to "autoimport" semiintelligently and perhaps
sprinkle it with a few confirmations based on Preferences. DS


--__--__--

_______________________________________________
Squeak-dev mailing list
Squeak-dev at lists.squeakfoundation.org
http://lists.squeakfoundation.org/listinfo/squeak-dev

End of Squeak-dev Digest




More information about the Squeak-dev mailing list