Squeak-dev May 1999

squeak-dev@lists.squeakfoundation.org

126 participants
289 discussions

Start a nNew thread

Smalltalk 2001
by John-Reed Maffeo 21 May '99

21 May '99

Is this really the new name for Squeak 4.0?

2 1

ExternalByteArray
by Stephen Pair 21 May '99

21 May '99

A while back, I did some work to create an external memory proxy mechanism. It was part of a larger effort to build a generic call-out and call-in mechanism. I started to give it out, but held off because I wanted some help porting it to other platforms (I only have Windows right now...my Linux machine died on me). I've now decided that it's better to put it out instead of waiting. I've also added my own Squeak related web site. Simply get the change set and there are instructions on creating the external module for the pluggable primitives. The change set and the Windows pluggable primitive DLL are available at: http://www.advantive.com/squeak If anyone creates (and tests) the pluggable primitive module for other platforms, I'll gladly add it to the web site. Enjoy! - Stephen Content-Type: application/octet-stream; name="Stephen Pair.vcf" Content-Disposition: attachment; filename="Stephen Pair.vcf" Attachment converted: Anon:Stephen Pair.vcf 4 (????/----) (0000A75F)

2 3

Re: KeyboardPolicy (was: Cut, Copy & Paste Policy)
by Joachim Durchholz 20 May '99

20 May '99

"Norton, Chris" wrote: > > Hi Joachim. > > One thing I'd like to see in KeyboardPolicy: a mechanism that maps a > keyboard event into various editing/text cursor movement events. > [Snipped your discussion regarding KeyboardPolicy, menus and > accelerators] > > Great thoughts -- all of 'em. This is the kind of thinking we will > have to pursue for each "Policy" object. Thanks :)) (I know I'm good at this type of game... don't ask me why. But I'm glad whenever I can make use of this ability - it's not in very high demand where I work right now.) > Question: Do you think it might be useful to have some kind of > KeySequence object that explicitly defines a combination of "keys > pressed"? It would be required to create a dictionary of key combinations against editing actions, so I'd say Yes to that one. I would not call it a *sequence*. That would imply a fixed order. Combinations with multiple modifier keys wouldn't work: It doesn't matter if you press Ctrl-Alt-F or Alt-Ctrl-F (and it *should not* matter, remembering an exact sequence isn't easy). It might be useful to structure the key combination into a set of "modifier keys" plus a single "main key". At least that's the logic behind the Windows keyboard input. > If we had a KeySequence instance that represented a particular key or > keys pressed, we could then apply that object to an "editing" feature. > Then, I suppose, each "editing" feature would have to be defined by an > object too (because, as you pointed out, you may tie multiple > KeySequence objects to each "editing" feature). Right. These features may not be very interesting; just enough to identify the key combination. > So what kinds of attributes would an instance of KeyboardPolicy have? > * an identifier (what kind of keyboard policy is this? Is it > just for editing on a Mac? Is it for games?) OK. * a collection of modifier keys * a collection of main keys These two define what's valid for a KeyCombination object. > * a collection of the available KeySequence objects KeyCombination object in my terminology. Otherwise agreed. > * a dictionary that ties "editing" features to collections of > KeySequence objects The "features" being just names. LineDown in a drawing application is quite different from LineDown in a DTP program. > * perhaps some kind of collection of arrays of keys that might > be used to "draw" a virtual keyboard morph? YES! This would be essential to build keyboard mapping editors. The model behind the keyboard morph should also provide the modifier key and main key collections. > Can anyone else think of any useful attributes and/or behaviors of > KeyboardPolicy? > (More use cases would be a good start :-) For gaming, some way to find "the leftmost top-row key on the keyboard" might be useful. (This might be a less-than-optimal idea. It might be better to allow the user to pick the appropriate keys on the keyboard morph. OTOH it would allow some nice things: e.g. the user says "have my gizmo controller around the S key" and the software knows which six keys are around it, so the user can specify six keys for the price of one.) Menu controllers should tell menu views which keyboard combination is tied to which menu entry. The menu view could then display a textual representation of the combination on the menu line. (*Very* useful to learn the shortcuts for an application.) For gaming, you need key-down and key-up events. The automatically generated key-repeat events are typically ignored (at least in real-time games, like arcade shooters). A separate typematic rate for each key might be a good idea; e.g. the letter and digits keys could work with typematic, but no typematic for Return. (Not sure whether this is a good idea. Just brainstorming.) (Probably not a good idea. You can always ignore key-repeat events for "dangerous" keys.) Policies could also apply to Shift-Lock. One policy switches Shift-Lock off when you press the normal Shift key, the other switches Shift-Lock off if you press Shift-Lock again. In the latter case, pressing Shift will get you lowercase letters. Shift-Lock has also different effects on non-letter keys: In one policy it will result in the shifted characters, in the other it will have no effect on them. I'm not sure how command keys are routed to menu actions in MVC and Morphic. Some standard mechanism to map keyboard events to menu events would be very handy if it's not already there. Regards, Joachim -- Please don't send unsolicited ads.

1 0

RE: Platform independent abstractions on platform specific models
by Norton, Chris 20 May '99

20 May '99

Hi Lex! [snipped object Policy hierarchy] > Lex Spoon [SMTP:lex@cc.gatech.edu] said: > Sounds fine, but two notes. > > First, it might be possible to make the policy objects instances instead > of classes. It all depends on what goes into a "policy". You might have > meant this, but I wanted to spell it out. > > Which leads to the second note: what exactly goes into the policies? So > far, it's a mapping of keys -> editting commands, which could be a simple > dictionary stored in some class or global variable. A standard file > format would be nice for these, so that people could share them around, or > we could simply use Smalltalk code. (Yet another menu item in the > FileLists? :( ) > > Anyway, I say, let's figure out what we really want to be able to > customize, and then we can figure out what kind of abstraction will work > best. The general scheme of having global policy objects seems like a > good one, but at this point, do we know what should actually go into them? > [Norton, Chris] I agree that the actual policy objects need to be instances (how else would we accomplish the kind of swappability that I proposed? :-). And it is most likely true that all "Policy" objects would inherit from an abstract Policy class, so that they can share an interface. However, I expect that we will want some concrete classes to keep things straight. KeyboardPolicy, AbstractPointingDevicePolicy, etc., might help to imply usage. I also expect that we will want to ask our currently defined OsPolicy object questions (like... what is my OS end of line character, or what is my file name separator?). Your second question is a good one. As a community, we need to think about what kinds of things would achieve added value from defining their "look & feel" or "behavior" or "interface" by some swappable policy. I think the following policies might be a good place to start: * OS policy (Win / Mac / Unix / OS2 / PDA / Risc / etc.) * keyboard policy (programmable via a point & click KeyboardPolicyEditorMorph (thanks Bolot Kerimbaev)) * mouse / pointing device policy * generic API call calls (these would be optimized / customized for each unique OsPolicy) * look policy for widgets / windows * sound policy for widgets / and for all of Squeak * image policy (this may be used to tell another image what classes are available??? -- I'm not so sure about this one) I'd love your input on this! Anybody... Wild suggestions are welcome. This whole Policy concept can be as revolutionary (I know -- somebody else already invented look policies in VisualWorks ;-) as pluggable primitives and the portable kernel! Wouldn't it be cool if you could tell your image to display every widget "as if" it were running on some other OS? Your Input Is Requested (need space suit to travel ;-) ---==> Chris

3 2

Re: Messaging vs. subroutines
by Michael S. Klein 20 May '99

20 May '99

On Wed, 19 May 1999, Joachim Durchholz wrote: > John Sarkela wrote: > > > > When I used to teach Smalltalk I would often have a copy > > of Webster's Ninth New Collegiate dictionary. If one looks > > up the definitions of class, object, message, method and > > framework, one will discover that Smalltalk is the language > > that avoids jargon. These words mean precisely what they > > mean in everyday parlance. > > Bzzt, wrong. Umm, puting the word 'precisely' in the same sentence as 'everyday parlance' is bound to be sorta problematic. (I often use the word 'sorta' to convey *precisely* this kinda fuzziness) You guys can all go off discussing OO philosophy, which is fun, but if we want some real progress, let's try to get a little concrete. The lexicographic approach is a powerfull one. Squeak would benifit from having a lexicon. It could inherit from a Smalltalk-80 lexicon (along with VW), which in turn could inherit from a Smalltalk lexicon (along with VA), wich could ... (Where the hell does ANSI Smalltalk fit in?) Even within the context of a *single* image (i.e. ignore version, platform, etc.) the word "object" has several definitions (as do most words in any dictionary). 1. An identifiable unit of computation within the image. 2. The usual class which is the root of the inheritence hierarchy for the majority of the system (Always capitalized) 3. A sub-instance of the class in (2) 4. A direct instance of the class in (2) -- rare 5. An identifiable unit of computation outside the image Of course all the words in a lexicon are defined in terms of themselves. The trick is to avoid useless small cycles, like: Recursion: see recursion. (For a laughable definition, see ANSI X3J20: Number >># positive) I would much rather see the Y-combinator under recursion. It has a unique structure that is recognizable in any language!!! (Its just more beautiful in the lambda-calculas) (Damn, where's the greek letters on my keyboard :-) Smalltalk's beauty comes from the interlocking definitions of: class, instance, method, message, and object And, as far as messages being just subroutines, you might as well say methods are just case statements. (Just dont say it around me :-) -- Mike mklein(a)alumni.caltech.edu

2 1

Re: Messaging vs. subroutines
by John Sarkela 20 May '99

20 May '99

Joachim Durchholz wrote: > > John Sarkela wrote: > > > > When I used to teach Smalltalk I would often have a copy > > of Webster's Ninth New Collegiate dictionary. If one looks > > up the definitions of class, object, message, method and > > framework, one will discover that Smalltalk is the language > > that avoids jargon. These words mean precisely what they > > mean in everyday parlance. > > > > So, I would put forth that it is Smalltalk that has traditionally > > eschewed jargon. This isn't mysterious terminology to an > > English speaker. An object is an object. A message is a message. > > A method is a method. > > Bzzt, wrong. > > An object in Smalltalk parlance is not a physical object. It does not > necessarily have a weight, a color, or whatever physical objects have. > All definitions in this message are according to Websters New World Dictionary 2nd edition (it's handy) object [...] 4.a noun or substantive that directly or indirectly receives the action of a verb or one that is governed by a preposition. Nothing about physicality inherent in that definition. I'm not at all sure what a gerund looks like after all. ;-) > A Smalltalk message is not an everyday message. A Smalltalk message is > an instruction to the receiver to do something specific. An everyday > message is just a bit of information that is passed to somebody. > message 1. a communication passed or sent between persons by speech, in writing, by signals, etc. I would argue that the fundamental point of Smalltalk is that all of computing can be boiled down to entities passing bits of information to each other. The beauty of Alan Kay's vision is that the primitive of communication, message send, can serve as the basis for all computing. > A Smalltalk method is a step-by-step description of what to do. An > everyday method is often a much more fuzzy thing; a set of principles, > promises ("do this and you'll easily get a useful result"), step-by-step > instructions. I.e. an everyday method may contain step-by-step > instructions, but not necessarily so. > method 1. a way of doing anything; mode; procedure; process; esp. a regular, orderly definite procedure I would once again assert that a Smalltalk method is quite adequately defined as a regular orderly definite procedure. > What *can* be said is that Smalltalk jargon uses some very intuitive > metaphors. But even those Smalltalk metaphors are just that, and once > you reach their limits, they won't help you anymore (and might even > hinder you). > I stand by my statement that Smalltalk usage of object, message, method, class, and framework were chosen precisely to avoid the use of jargon. The standard definitions do indeed accurately describe their referents. > > No mystery if you haven't been conditioned by traditional programming > > languages. > > I'll admit any day that I'm conditioned by years of using traditional > programming languages. However, I think anybody who claims he isn't > conditioned by his working environment and terminology just hasn't > noticed the conditioning yet. > The "anybody" in the sentence above is intentional. I don't think it is > possible to program a computer without giving up some of the real world > concepts. In fact doing a full simulation of the world would be > fruitless; the world itself is its best and most accurate simulation :) > So what computers are good for is not doing objects, it's doing > abstractions. Computer objects have been observed to be one of the best > ways of doing such abstractions; the Smalltalk terminology provides some > very useful metaphors that make thinking about the abstractions inside > the computer easier. But that doesn't mean that a Smalltalk message send > is the same as a real-world message send. "The map is not the territory." Count Korzybski > Regards, > Joachim > -- > Please don't send unsolicited ads.

2 1

Re: Random Numbers
by Joachim Durchholz 20 May '99

20 May '99

"Michael S. Klein" wrote: > > > On scaling: > > A single byte can be interpreted as a number between 0 and 255 (then > > it's called "unsigned") or between -128 and 127 (then it's called > > "signed"). > > To scale such a byte to a number between 0.0 and 1.0, just divide > > the byte value by the range of numbers expressible with it (which is > > 256 in both cases: you have 256 values to select from). > > Common mistake... Divide by 255, not 256, otherwise you dont get full > range of 0 thru 1. Don't be tempted to 'optimize' by doing bit-shift > division. That was intentional. You usually want numbers in the range including 0.0 and excluding 1.0. Most (if not all) standard random number generators with a floating-point output work that way. This is no surprise, as one usually doesn't want 1.0 as a result. Another hint: It's usually not very interesting to use floating-point results. You usually want some fixed sets of integers. Conversion to and from floating-point representation risks losing bits due to round-off errors (not if you're dividing by a power of two, but even then a bug in some floating-point library or in the FPU of the processor can foul things up). So what I usually do if I have to write a random generator from scratch is the following: 1) Get me a good source random seed. User input, the current millisecond, whatever. 2) Write a random number generator. Depending on the application, it will be a simple multiply-divide-remainder one, or a cryptographically secure one. I make sure that the random numbers have enough bits to satisfy the application (just using two consecutive outputs to generate a double-size random number won't do, at least not if I'm serious about the quality of the random numbers - I like to be serious, so I'll probably do it even if I'm just doing a simple game). 3) Write a function that takes two bounds and scales my random numbers to the desired range. This will be equivalent to conversion to floating-point and conversion back, but it will have the additional advantage that I don't even have to think about round-off errors. Something like Random>>rangedFrom: To: Of course you'd have to look out for fencepost errors (an inherent danger of integer ranges). One additional wrinkle: Scaling will divide the random number output into a set of intervals. As the original numbers are integers, the the intervals may differ by 1 in width. This is not a noticeable problem if you have a large number of bits in your random numbers and small result ranges. It can become a problem if you have, say, an 8-bit random number generator and 120 categories: You'll get 16 intervals with 3 numbers in them and 240 intervals with 2 numbers in them. If this is of concern to you, you'll have to keep generating random numbers until you get one that's below 240, and divide by 240. If you have a good generator with a long period, this can take a while in the worst case. Off the top of my head, I don't know of an algorithm that would solve this problem. Regards, Joachim -- Please don't send unsolicited ads.

1 0

Re: Messaging vs. subroutines
by Glenn Krasner 20 May '99

20 May '99

I've always thought that "method" was inferior to "function". (Of course, I may have always been wrong.) The arguments made on this list, pro and con, about "method", "message", "object", etc. as to whether it would have been better to reuse terminology from other programming languages or use a new term, it seems to me, also apply to "class", "variable", "statement", "expression", "code", "number", or many other terms that Smalltalk did reuse. I see as much validity in rejecting "variable" or "expression" on the grounds that Smalltalk's semantics for those is (or could be) dramatically different from the semantics in other languages, so to use similar terms would mislead programmers into never realizing the beauty of the Smalltalk semantics. Similarly, I see as much validity in accepting "variable" or "expression" becuase they help the beginner and eventually the beauty is understood by the enlightened. I don't believe there's a single value function that could determine which are and are not the best terms. For me, the Smalltalk terms, both borrowed and invented, are all pretty good choices, except for "method", for which I think "function" would have been better (but retain "mesage"). The choice of "best" terms probably changes over time. In the early '90s, for example, ParcPlace made a correct choice to drop the term "Virtual Machine" from our lexicon--no customer understood what we meant--and to use "ObjectEngine" instead, which did communicate to customers. Nowadays, becuase of you-know-what (and unfortunately, I don't mean Squeak), customers are totally confused by "ObjectEngine" and very much understand and prefer "Virtual Machine". Since you-know-what also reused "method" from Smalltalk, I don't expect it ever to change, even to a better term. glenn

1 0

RE: Platform independent abstractions on platform specific models
by Carl Gundel 20 May '99

20 May '99

>Well, I certainly wouldn't call it a toy...but, you have a point. If you >want it to be a great environment, that's one thing...if you want it to be >widely accessible, that's an entirely different thing. :) > >As for your company, if Squeak had good database and Windows integration >(native widget support, callbacks, etc), would they be tempted to switch? Add to that list: - better performance - exception handling - full block closures - ENVY or something like it It also would not hurt Squeak if some second organization would pop up to add value (like Red Hat does for Linux). For example: - do real QA - provide documentation - provide visibility - collect and distribute a library of goodies & addons I've also got my eyes on Disney Imagineering to see what real system they realize in Squeak. Go Squeak! ;-) -Carl _______________________________________________________________ Get Free Email and Do More On The Web. Visit http://www.msn.com

1 0

Re: Thinking about a better UI (volume of discussion)
by Jeffrey J Hallman 20 May '99

20 May '99

Unfortunately, some of us don't have that option. My organization just switched us all over to Lotus Notes for email, which means that Notes is the ONLY way I can read my email. (Yes, I protested, and No, it didn't make any difference.) I can still use Emacs and GNUS to read Usenet newsgroups, so I would love to see a newsgroup that mirrored the content of the mailing list, allowing me to unsubscribe from it. Using Notes has really slowed me down at reading email, as it has to go out to a server for each and every piece of mail. All in all, I really dislike it. Are any of the web-based services like HotMail good at handling large volumes of email? [original msg from Peter Crowther deleted]... Or, you can upgrade to GNUS, the mail/news-reader inside GNU Emacs, which reads mailing lists as if they were news under a unified model. Scorefiles... threads... etc etc. Very nice. -- Name: Randal L. Schwartz / Stonehenge Consulting Services (503)777-0095 Keywords: Perl training, UNIX[tm] consulting, video production, skiing, flying Email: <merlyn(a)stonehenge.com> Snail: (Call) PGP-Key: (finger merlyn(a)teleport.com) Web: <A HREF="http://www.stonehenge.com/merlyn/">My Home Page!</A> Quote: "I'm telling you, if I could have five lines in my .sig, I would!" -- me

1 0

← Newer
1
...
6
7
8
9
10
11
12
...
29
Older →

Jump to page: