Squeak-dev October 2001

squeak-dev@lists.squeakfoundation.org

191 participants
600 discussions

Start a nNew thread

Squeak 3.1???
by Roger Vossler 31 Oct '01

31 Oct '01

Howdy, Any indication when Squeak 3.1 for the Macintosh is going to be available? cheers, Roger.....

3 4

[newbie] Keybindins
by Philip Knodle 31 Oct '01

31 Oct '01

Is it possible to change the key bindings that the browser (and the package-browser) use? I looked at how the different TextMorph's deal with key events, and I was just confused. I'm not sure if I'm looking in the right place. Thanks, Philip Knodle

2 1

Re: Critique my code
by danielv＠netvision.net.il 31 Oct '01

31 Oct '01

Dennis, that's cool! I already have a few uses for it, if you do extend it to accept more kinds of sources - I want to do a POP mailbox checker, and a current changeset size indicator, for example... Sam already gave you lots of good things worth doing, so I'll just add my two cents. Basically the changes Sam indicates are refactorings - changes to the code that mostly don't change functionality, but make the code easier to understand and thus improve. Two problems with this sort change - they're sometimes tedious, and they give you opportunities to add bugs. For example, you have a class AbstractMeter with variables named meterZones, meterLow and so forth. The context is already clear enough from the class you're writing in - you can rename the variables, removing the repetitive prefix. This would be an imporvement, but to do each rename, you'd have to find and change manually each reference to each variable - lots of work, and if you forget an occurance, that's a bug. Enter the Refactoring Browser. This is a tool that looks and behaves like the regular system browsers, except that it supports and automates many common refactorings. For example, Rename Instance Variable. Also Extract Method, which is the easiest way to make you methods smaller. Sam Adams <ssadams(a)us.ibm.com> wrote: > Dennis, > That's a significant accomplishment for your first coding effort in Squeak! > Many years ago I wrote and sold the first commercial gauges/meters > framework for Smalltalk (PluggableGauges- 1987), and I must say I am > impressed with all the functionality you have included (much more than I > did!). > > A few suggestions: > > **Method size > In general Smalltalk/Squeak methods are only a few lines long. Years ago > at Knowledge Systems we ran stats on methods across the Digitalk image and > found that the average number of messages sent in a method was only 6! > That's not lines of code, but individual messages. While its OK to have > longer methods for reasons like performance(very, very rare) or algorithmic > clarity, your code will typically be much more readable and reusable if it > is broken up into smaller methods that have nice "intention revealing" > names, as Ward Cunningham used to say (and still does, I imagine!). Try > rewriting your draw method to separate scale drawing from indicator/needle > drawing, and perhaps within your scale drawing method, split it between > major/minor tics and labels. This will give users who want to subclass and > extend your code lots of easy places to override specific aspects of the > drawing without cloning the entire drawing code. > > **RedZones and parsing > Keeping your red zone data in string form and constantly reparsing it in > various methods is unnecessary and overly complex, especially since Squeak > is about objects, not data structures. Why not simply create a new class > called AlarmZone or something like it and let it model the zone range, > color and possibly an alarm action to be executed when the value of the > meter is in range. In your properties dialog, you can keep the same kind > of textual specification for zones (with some simplification...see below) > and then on OK/Apply, parse it once and create and save the appropriate > zone objects in your meter to later inform the draw methods. > > **RedZone specification made easier > Squeak has lots of ways to parse and manipulate strings, but for simple > data structure entry like (10,20)(90,100) you can let the compiler do the > work for you. For instance, you could convert the string '(10 20)(90 100)' > into an array of arrays of numbers with the folowing code: > > inputString := '(10 20)(90 100)'. > correctSyntaxString := '#(',inputString,')'. > array := Compiler evaluate: correctSyntaxString . > > in other words, you let the user enter Smalltalk syntax or somethign close > and then simply evaluate the text into an object. Hey, since you are using > the Smalltalk compiler anyway, you could even have the user enter something > like: > > {AlarmZone min: 10 max: 20 color: Color blue action:[Broker buyStock]. > AlarmZone min: 90 max: 100 color: Color red action:[Broker sellStock]} > > And the compiler expression above will return an array of AlarmZone objects > ready to be saved in the meter. End user programming on the cheap! > > **Display performance > Last critique, since most of your submorphs don't change each step, don't > remove and recreate them each step. Even with the needle, you only need to > update it if the value has changed since last time, unless of course the > user is moving or scaling the whole meter, in which case you need to redo > everything. > > **Enhancement suggestion > Why limit your source to a URL? You could again let the user enter a > Smalltalk expression that you assume results in a number when evaluated. > Then use the 'Compiler evaluate: theSource' approach each time you need the > value. This turns your meters into a more general gauges package that can > be used for any value in Squeak. > > To summarize: > In general, use more, smaller methods with intention revealing names. > Make first class objects for your data structures and give them appropriate > behavior. > Let Squeak do the parsing work whenever possible (and practical from a user > skill standpoint). > Don't redraw/rebuild morphs unless necessary. > and of course, > Keep on squeaking! > > Regards, > Sam > > > > > Dennis Damico wrote: > << > Hi all, > > > I'm new to Squeak and Smalltalk. Enclosed is my first coding effort. I > invite you experts to critique my code. > > > Have I chosen morphs and methods appropriately? Is the implementation > efficient? Does the style look like an acceptable Smalltalk style? Your > feedback and helpful suggestions will be appreciated. > > > The code was developed under Squeak 3.0 on Windows. > > > thanks > > > < code elided> > > > >> > > > > > Sam S. Adams, IBM Distinguished Engineer, IBM Research > tie line 444-0736, outside 919-254-0736, email: ssadams(a)us.ibm.com > <<Hebrews 11:6, Proverbs 3:5-6, Romans 1:16-17, I Corinthians 1:10>>

1 0

[BUG] area fills incorrect in 8 bit little endian
by Mike Rutenberg 31 Oct '01

31 Oct '01

When running on Windows in 8 bit little endian display mode, the balloon help area fills do not happen correctly. They seem to be half filled with the yellow colour, and the rest of the balloon is transparent. The same help balloon shows correctly in other display settings, including 8 bit big endian Mike Display depth: 8 bit little endian VM: Win32 - Squeak3.1alpha of 28 February 2001 [latest update: #4044] Image: Squeak3.2alpha [latest update: #4461] 3.1 alpha 6 VM (Squeak-D3D.exe) on Win98. An example picture is attached.

1 0

RE: Lots of concurrency
by G.J.Tielemans＠dinkel.utwente.nl 31 Oct '01

31 Oct '01

I remember from the Logo-camps in the Netherlands a child, that was proudly writing the longest program of all... Then a Belgium professor came in and said: "what you are doing can be done in one line, let me show you." That day the boy did leave the camp.. So I recognize your experience. Mine is longer ago: we had to create punch-cards to feed the computer. (There were already terminals, but it was good for your education.) The philosophical part of a punchcard was nice: "the moer information you store in the holes, the lighter it becomes." But after destroying the same card for the fourth time we went to the pub. (and sneaked in the terminalroom the next day) So what me wonders most: How could you then - with your childhood experience - survive the initiation in Smalltalk/Squeak ? -----Original Message----- From: Alan Grimes [mailto:alangrimes@starpower.net] Sent: Wednesday, October 31, 2001 4:10 PM To: squeak-dev(a)lists.squeakfoundation.org Subject: Re: Lots of concurrency <snip> The biggest gripe about my logo days is that I never was able to understand the big picture of what was going on. Sure, making the turtle act like a dope was easy as anything but it didn't give me any clue as to how this could possibly relate to writing real software. Most notably, there was a really cool shell called "superdos" (Which runs only on DOS 2.x and 3.x); How do I get that flaming turtle out of my sight and make stuff that is actually cool? In a summer camp one time with Logo Writer I spent the entire time writing a patheticly stupid game. I turn around and someone else in the same room had designed a game that had actual rooms in it that could be navigated 3D-man style. The memory still drives me up the wall... In highschool I was furrious at other kids who knew the mysteries of 32 bit programming and stuff where the computer lab (in 1995) was still running off of dual-flopy Zenith XTs... I really wanted to rip their lungs out... I don't know what the hell I wasn't doing or wheather it was even my fault at all... I have finally achieved an understanding of what goes on in my windows 3.11 machine that I feel that I would loose part of my soul if I ditched it in favor of Linux. (Linux sucks for countless other reasons too). Sorry for bending your ear like this.... -- Uncle Sam has the Gremlin's touch. http://users.erols.com/alangrimes/ <my website.

2 1

Confusing tutorials
by compufriend 31 Oct '01

31 Oct '01

Goodday all, Thank you for all your help so far! I have to say, of all tutorials so far, the most accurate and helpful of all would have to be John Maloney's 'BankAccount tutorial'. When and were something was supposed to happen, it did and he explained why. Now I'm even able to follow how to make head or tail of the little Debug Window that pops up with MessageNotUnderstood. Thanx John. Problem: Dan Shafer's Counter tutorial works up to Step 6. I opened all the relevent script viewers. I created a script1 tile for the increment button. I opened the viewer for CounterDisplay and saw the green and purple arrow in question (which reads as a line: CounterDisplay's counterValue 'greenarrow 3) The tutorial sais as follows:" Now, click and drag the purple and green arrow in the instance variable area and drag into the scripting tile window you just created. Keep going until you see a small green rectangle appear in the bottom of the script window. This indicates the first line of the script is ready to accept what you're dragging in. Just drop the scripting tile. Your script should expand and you should see a copy of the tiles indicating that CounterDisplay's counterValue is 2 (or whatever value yours started life with)." Drag as I like, no green rectangle appears nowhere. I've hovered the mouse and tile over every inch of the Script1 window and even tried dropping it inside the Script1 window. Help anyone please. Thanx Compufriend

2 1

[EXPERIMENTAL] Celeste support for accented characters
by Mike Rutenberg 31 Oct '01

31 Oct '01

>From the change set: Makes Celeste properly display accented characters which are part of an email message, especially text message body, HTML message body, text header lines, and header lines encoded with mime. This is very nice if you receive or send messages in French, Danish, German, etc... I have tested this in my system and it works fine, but am looking for evaluation by anyone else who uses accented characters, especially in languages other than German. Please send me the full contents of any message that does not display correctly. Note that accented header information displayed in the message list will only only be displayed for new messages you receive after that change set or if you close Celeste, delete the .index file and then regenerate it. Mike NOTE: This will need to be modified a bit after Lex's Celeste changes are included and so this change is not yet for inclusion in the main system release

1 0

RE: Lots of concurrency
by G.J.Tielemans＠dinkel.utwente.nl 31 Oct '01

31 Oct '01

In the old LOGO days we let children "Be the mouse" - first be a mouse: Step forward, turn right.... hello, you made a circle, funny, how comes.. - then design a script for actions in the classroom on paper and check it with your feet. Taking the viewpoint of the mouse on the screen became easier this way. The same seams to happen when people are asked to take resposibilty for a card, even being the card, during CRC-Cards-Design during a scenario-check meeting. -----Original Message----- From: Alan Kay [mailto:Alan.Kay@squeakland.org] Sent: Wednesday, October 31, 2001 12:48 AM To: squeak-dev(a)lists.squeakfoundation.org Subject: RE: Lots of concurrency Mtichel Resnick wrote an excellent little paper a few years ago http://www.media.mit.edu/~mres/papers/JLS/JLS-1.0.html "Beyond the Centralized Mindset" (his bibliography is at http://www.media.mit.edu/~mres/papers.html , and many of his papers are online). One of his very interesting opinions about the problems he observed was that they didn't seem to be so much about "concurrency being hard", but that it was quite difficult for students of most ages (even high school students) to be able to take the point of view of one of the little particles and to think about what it could see and do. This "taking a different point of view other than your own" was a centerpiece of some of Piaget's work. In theory, this is supposed to get easier as you get older, but it also seems to be something that has to be learned, and many don't learn it. The students had a kind of god-like, from their POV, way of looking at the world -- much like programmers who start off with simple algorithms munging datastructures. This doesn't scale well. In good OOP, the programmer should take the POV of the object in its environment, and help the object become self-sufficient, productive and robust. This way of programming really opens the doors to concurrency. Cheers, Alan ------ At 11:17 PM +0100 10/30/01, G.J.Tielemans(a)dinkel.utwente.nl wrote: >Children and students live in this era: >- They can send each other emails, it is possible to send eamils to a list >- They can send each other SMS, it is possible to send an sms to a group >- They can chat in a chatbox, private or in a group > > >> -----Original Message----- >> From: Ken Kahn [mailto:kenkahn@toontalk.com] >> Sent: dinsdag 30 oktober 2001 20:33 >> To: squeak-dev(a)lists.squeakfoundation.org >> Subject: Re: Lots of concurrency >> >> >> Richard A. O'Keefe wrote: >> >> > >> > The question I think is interesting is whether telling students to >> > think in terms of objects TALKING to each other makes it harder for >> > them to think of concurrent implementations. Would some other >> > metaphor (perhaps sending couriers with messages, or thinking about >> > a factory with things concurrently moving from machine to machine >> > at the same time) make it easier for them to think of and understand >> > concurrency? >> > >> >> Before settling upon a carrier pidgeon metaphor for >> communcation in ToonTalk >> I considered lots of other alternatives including a postal >> system with mail >> carriers and mail boxes, rivers where you can place floating >> messages to >> those downstream, wires, fax machines, email, and telephones. I never >> considered face-to-face talking since I took for granted that >> objects are >> spread out spatially. I think the answer to Richard's >> question is that the >> right choice of metaphor can significantly facilitate thinking and >> understanding concurrent programs. >> >> Wires may be how messages are really passed within and >> between computers but >> wires are not an ideal metaphor. The messages are invisible. >> Wires cannot be >> sent along wires. Directionality isn't apparent. Wireless >> communication is >> even worse. >> >> Talking or telephones aren't good because both parties need >> to be available >> at the same time. Many-to-1 communication by telephone is >> confusing. While >> phone numbers can be communicated over the phone that would >> lead to a model >> where numbers denote objects or communication channels. So >> can they be made >> up and dialed at random? Not good. >> >> Even the postal system doesn't provide an ideal metaphor. If >> you want to >> send the receiving end of a communication channel to someone >> do you have to >> pick up your mail box and send it by mail to someone? And >> then does the >> postal system know that the mailbox has moved or do you need >> to think about >> forwarding addresses? >> >> A bird that when given something flies to her nest and leaves >> it there and >> returns works out very well. You can give a bird a box that >> might contain >> other birds and nests - not too strange. The only strange > > thing is that a >> bird always finds her nest no matter where it has been moved >> to. But that >> doesn't seem to cause any confusion. >> >> > All I know about Ken Kahn's ToonTalk is what I've read in >> this thread, >> > but it sounds as though uses a "physical" rather than "verbal" >> > metaphor, so I think his observations are particularly >> interesting here. >> > >> >> You all are welcome to try out ToonTalk. There is a free >> trial version and >> you are all welcome to try to beta version as well. It only >> runs on PC with >> Windows (or Macs emulating a PC with Windows - don't know about Linux >> emulators). Details at www.toontalk.com >> >> Best, >> >> -ken kahn >> >> >> >> --

3 2

RE: Lots of concurrency
by G.J.Tielemans＠dinkel.utwente.nl 31 Oct '01

31 Oct '01

>-----Original Message----- >From: Stefan Schmiedl [mailto:s@xss.de] >Sent: Wednesday, October 31, 2001 11:05 AM >To: squeak-dev(a)lists.squeakfoundation.org > >Subject: Re: Lots of concurrency > >> The same seems to happen when people are asked to take resposibilty for a >> card, even being the card, during CRC-Cards-Design during a scenario-check >> meeting. > > Looking forward to your description of stacking cards on top of each other .-) Sorry for you: Cards should be "open" on the table, at best grouped together, but still free view.

1 0

Re: Lots of concurrency
by Ken Kahn 31 Oct '01

31 Oct '01

Alan Kay wrote: > > One of his [Mitchel Resnick's] very interesting opinions about the problems he observed > was that they didn't seem to be so much about "concurrency being > hard", but that it was quite difficult for students of most ages > (even high school students) to be able to take the point of view of > one of the little particles and to think about what it could see and > do. This "taking a different point of view other than your own" was a > centerpiece of some of Piaget's work. In theory, this is supposed to > get easier as you get older, but it also seems to be something that > has to be learned, and many don't learn it. The students had a kind > of god-like, from their POV, way of looking at the world -- much like > programmers who start off with simple algorithms munging > datastructures. This doesn't scale well. In good OOP, the programmer > should take the POV of the object in its environment, and help the > object become self-sufficient, productive and robust. This way of > programming really opens the doors to concurrency. > I saw Kristen Nygaard a couple weeks ago and he was talking about his experiences prior to Simula. He was building simulations for the Norwegian military and said he would build the simulation thinking if I was a tank what would I be able to do, what would I know, and so on. The fact that he used the first person when referring to simulation objects led to a discussion. My impression was that he thought it was so natural to use the first person that he didn't see why it was worth pointing out. I wonder if he didn't take this first person viewpoint whether he still would have co-invented the first object-oriented programming language. And I wonder if we should always write comments in first person... Best, -ken kahn ( www.toontalk.com )

2 1

← Newer
1
2
3
4
5
6
7
8
...
60
Older →

Jump to page: