Squeak-dev October 1999

squeak-dev@lists.squeakfoundation.org

141 participants
396 discussions

good OOD methods
by Graham Telfer 01 Oct '99

01 Oct '99

Hi, I'm new to Smalltalk and Squeak in particular. I've mainly used Forth and Prolog up to now. By preference I use VDM for specifictions. The OOD methods I've briefly looked at do not seem very rigorous. Z++ and VDM++ both feel like hybrids. What design methods do people think are best suited to Squeak? Should I continue to use VDM and predicate calculus, as I do for Prolog.

1 0

RE: red/yellow/blue buttons an anachronism?
by Michael Klein 01 Oct '99

01 Oct '99

On Friday, October 01, 1999 12:28 AM, Peter Crowther [SMTP:Peter.Crowther@IT-IQ.com] wrote: > > The names of the buttons should be semantic, not color or positional. > > ... unless the semantics vary between different parts of the same system, in > which case no single semantic naming convention can suffice. For example: > > > In MVC, <select> <operate> and <window> are the names I think of for the > > mouse. In Morphic, <select> <operate> and <halo> . > > Case closed, to me at least. Exactly. No single naming scheme an suffice. The names should be chosen appropriate to the module within which they reside. If you are writing device drivers, than left/red is right. If you are doing a UI framework, like MVC or Morphic, Then I would hope you would have some coherent semantics for your input scheme. Try to prevent the physical implementation from propagating into the higher layers. For example, NeXTSTEP provides (provided?) three kinds of draging operations: move, copy, and link. Application writers could map those into appropriate actions within the context of their application, rather than writing code like: Keyboard shiftPressed ifTrue: [heldObject copyTo: target] ifFalse [heldObject copyTo: target]. Since squeak strives towards extreme portability, remember that the most variation amonst computer systems occurs on the input devices... specifically the keyboard. But these days, a trip to your local computer megastore will reveal a bewildering array of trackballs, mice, keyboards, yokes, joysticks, and even a steering wheel or two. (How fun would that be... towing windows around your screen :-? ) > > As we're in a situation where a button does not necessarily have a single > physical realisation (for example, option keys to distinguish multiple > virtual buttons on the click of one physical button), let alone the same > physical realisation for all users on all platforms, a positional notation > is also inappropriate. The right thing to do is to decide on the semantics you want, and then figure out good UI gestures to invoke them. Form follows function. If you ever try to develop your own keyboard layout, you will see what I mean. Still, even today, we are plagued by keyboards with an alphabetic layout. How hard would the piano be to play if all of the keys were laid out in a single row, rather than with the white-black scale-revealing system we use today? > Given the above, it seems natural to invent an arbitrary set of names for an > arbitrary set of virtual buttons. I'd quite happily go with Charles, > Renaldo and Kung-Kiu as the names of the buttons provided the names were > used consistently; what is then important is a consistent mapping of these > virtual buttons to operations within any particular interface style, such as > MVC, Morphic, the GIMP, the Windows Style Guide, Paint Shop Pro. > > - Peter Better still, provide an easy mechanism for users to customize and extend their own mappings. -- Mike Klein

1 0

Nominations for 2.6
by Stephen Travis Pope 01 Oct '99

01 Oct '99

Might I nominate the PackageBrowser (ftp://ftp.create.ucsb.edu/pub/Squeak/goodies/STP12/STP12/Packages/PackageBr…) and the TimeProfileBrowser (ftp://ftp.create.ucsb.edu/pub/Squeak/goodies/STP12/STP12/Packages/TimeProfi…) for 2.6? Many squeakers have found them very useful tools. -- stp Stephen Travis Pope -- http://www.create.ucsb.edu/~stp stp(a)create.ucsb.edu -- stp9(a)cornell.edu

2 1

[BUG][FIX] Parser declareTempAndPaste:
by Alexander Lazarevic 01 Oct '99

01 Oct '99

Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit I think it is annoying when I try to accept a method like transistor | flip| flip := true. flop := false. and let the Parser insert the temporary variable flop and get this: transistor | flipflop | flip := true. flop := false. The included fileIn changes declareTempAndPaste: to check if there is a whitespace between the last declared variable and the trailing | character. Alex. Content-Type: text/plain Content-Description: changes declareTempAndPaste: to check if trailing | character Content-Disposition: inline; filename="Parser-declareTempAndPaste.st" Content-Transfer-Encoding: 7bit 'From Squeak 2.5 of August 6, 1999 [latest update: #1499] on 1 October 1999 at 8:18:46 pm'! !Parser methodsFor: 'error correction' stamp: 'laza 10/1/1999 20:18'! declareTempAndPaste: name | insertion tabbed | (requestor text string at: tempsMark) = $| ifTrue: "Paste it before the second vertical bar" [insertion _ name, ' '. (requestor text string at: tempsMark-1) isSeparator ifFalse: [insertion _ ' ', insertion]. tempsMark _ tempsMark + (self substituteWord: insertion wordInterval: (tempsMark to: tempsMark-1) offset: 0)] ifFalse: "No bars - insert some with CR, tab" [insertion _ '| ' , name , ' | '. tabbed _ tempsMark > 1 and: [(requestor text string at: tempsMark-1) = Character tab]. tabbed ifTrue: [insertion _ insertion , (String with: Character tab)]. tempsMark _ tempsMark + (self substituteWord: insertion wordInterval: (tempsMark to: tempsMark-1) offset: 0) - (tabbed ifTrue: [3] ifFalse: [2])]. ^ encoder reallyBind: name! ! Content-Type: text/plain; charset=us-ascii Content-Description: .signature Content-Transfer-Encoding: 7bit -- ------ Alexander Lazarevic ------------------------------------------------ -- Otto-von-Guericke-Universitaet mailto: Alexander(a)Lazarevic.de -- -- Computational Visualistics http://www.cs.uni-magdeburg.de/~lazarevi --

1 0

Re: Squeak's role in a larger world?
by John Tobler 01 Oct '99

01 Oct '99

Tim Rowledge wrote: >> AFAIK, Squeak is not yet embeddable. > Not in the sense of being able to put an image > in rom and run out of rom, no. This usage of "embeddable" has nothing to do with "embedded systems" and is not a hardware-related issue. It has, rather, to do with easily using one language from within another. For example, Python is embeddable because you can relatively seamlessly invoke a Python interpreter from within another language. This makes it easy, for example, to write Python scripts and have them run from within a C/C++ program. If I remember correctly, a complete Python interpreter is provided in a shared library (dll, for Windows) along with the appropriate API hooks to allow it to be invoked from within another language system. In context, then, Squeak would be embeddable if a mechanism existed such that you could (easily) execute Squeak- compliant Smalltalk code from within a program in another language. /John _______________________________________________________ Get Visto! Groups, event calendars, email, and more... Check it out @ http://www.visto.com/info

1 0

RE: [ENH] Empty return expression
by Michael Klein 01 Oct '99

01 Oct '99

On Monday, September 27, 1999 5:08 PM, Stephen Pair wrote: > I (Michael Klein) wrote: > > Smalltalk chooses a "fixed" point in language desing space that is good > > for 99+ % of the time. > > It also gives you all of the powerfull hooks to handle the remaining > > small amount. > > (The powerfull hooks are things like Behavior, #doesNotUnderstand:, > > #become:, thisContext, etc) > > These are very powerful for building frameworks that allow "ordinary" > > (99+%) methods to > > avail themselves of extreme coolness > > That same argument could be applied to C++ by C++ers in saying that 99% of > the time you don't need classes exposed as first class objects. For this > reason, and many others, I prefer Smalltalk. Yes, but, like the inspiration of genius, that remaining 1% is crucial. C++ give you no powerfull hooks. If you are lucky, your C++ will cough up the name of the class of an object in a non-portable fasion.] Also, you seemed to have mistaken my perception of Smalltalk for an argument of why it should stay like it is. I really do wish people gave some *good* thought to the art of a Smalltalk meta-object protocol. I'm pointing out that by adding OO "features" to Smalltalk, you give up a prime benifit of it's simplicity. Read again what I said about exceptions. They use powerful hooks like thisContext, and unwind-protection (in VW). The are part of the code base, like OrderedCollection. > However, I wish things like > message sending, message handling, instance variable accessors, and > messaging were more generalized and accessible. I hope that eventually > Squeak will evolve far beyond ANSI Smalltalk. I hope that ANSI Smalltalk will evolve, but I'm afraid I'm quite alone amongst Smalltalkers in that regard. Squeak, and all of the other Smalltalks are already far beyond ANSI. ANSI is merely an agreement upon the known. > > For example, Smalltalk give you single static inheritence, but if you > > want to implement > > multiple or dynamic inheritence, you can. > > But not easily. Compared to what? Java? C++? Fortran? Sure, it's probably easier to do in Self than Smalltalk. Scheme... tough to say. > > Likewise for > > multi-polymorphism (although I'm > > sure we can do better than double-dispatching & coersion). You can be a > > productive > > Smalltalk programmer, and never even know about primitive methods. > > Of course, and that's a (or should be) key design goal. Sure. Primitive methods and the prime anomoly are rites of passage for Smalltalkers. > > There was a good mind-bending paper at OOPSLA a decade or so ago, on how > > to add > > back-tracking to Smalltalk without VM support (using thisContext). > > > > I'm afraid that if we add stuff like this to Smalltalk, it will turn > > into CLOS. > > In my opinion thisContext is a key concept and we should not strive to hide > it's presence. Also, implementing a return with ^ seems non-smalltalky to > me. It seems cleaner and more consistent to say "thisContext > terminateAndAnswer: someObject" (although it is obviously more cumbersome to > type). The more expressive form clearly indicates exactly what is > happening. It's not hidden. Its just a power tool thats not for everyday use. I dont what to see code like: | tempVar | thisContext tempAt: 1 put: 'Initial Value' I want: | tempVar | tempVar := 'Initial Value' You may find it insightful to browse references to: #tempAt: and #tempAt:put: Similarly, Bad: gun perform: #shoot. Good: gun shoot. Obfuscatory: gun perform: #perform:with: with: #shoot I usually introduce programmers to Smalltalk by saying: "Smalltalk is a very simple language. There's only three things you can do: Assign a variable, Return a value, and send a message. This is obviously a gross simplification, but since everybody knows about what the first 2 things do, this puts the focus upon *messaging*, the soul of Smalltalk. Not objects. Not Classes. Not inheritence. > And, InstructionStreams are really the fundamental unit of processing and > should take much of the responsibility currently held in Process. > Especially when considering how one would architect a Squeak that takes > advantage of multi-processor CPUs. I'm personally more concerned with language design, not implementation. But, fundamentatly, there's got to be that eval/apply gem somewhere. As far as InstructionStreams being fundamental... I'm against byte-code standardization. It only solves political problems. (of course most of Smalltalk's problems are political (compared to Java, for example) not technical, but that's a whoooole other thread) (Do Smalltalker's *really* want Smalltalk to be more popular? In any revolution there are 2 sides.... the establishment, and the movement) > > I say we build stuff like this around the powerful hooks... much the way > > Exceptions > > are built around thisContext. Smalltalk was never about quiet syntax. > > Smalltalk is > > about deeper semantics. > > > > self doStuff. ^ > > vs. > > self doStuff. Processor terminateActive. > > > > I certainly don't want a quiet syntax for killing a process! I want to > > HEAR the BANG > > of the bullet that kills it! > > I didn't mean to imply that "thisContext terminate" should terminate the > Process (as it does), but rather that it should complete processing of a > method context (as "^self" does). > > - Stephen > Squeak kinda has this: thisContext return: 'The Answer' to: thisContext home sender But it is so far from working that it's funny. The OOPSLA paper shows how to make it work. Before I close this lengthly response, let me point out that the above questions I asked are not rhetorical. I really want to know what all of you out there think. If I were to pick one existing OO feature that I would be interested in exploring in Smalltalk, it would be method combination (maybe mixed with mult-methods) -- Mike Klein

1 0

SourceSetManager (was Re: Nominations for 2.6)
by Michael Rueger 01 Oct '99

01 Oct '99

"Stephan B. Wessels" wrote: > But I'm not sure I agree with the moniker. When I think of Package browser I think in terms of TeamBrowser tools or Envy, and this name is misleading. I agree. > But since then I became reasonably comfortable with change set tools and have abandoned the project. Just to avoid conflict with the work Stephen had been doing I decided on SourceSet Manager. I would like to have a look at what you did. Is the code available somewhere? Thanks Michael -- "To improve is to change, to be perfect is to change often." Winston Churchill +------------------------------------------------------------+ | Michael Rueger | | Phone: ++1 (818) 623 3283 Fax: ++1 (818) 623 3559 | +--------Michael.Rueger.-ND(a)online.disney.com----------------+

1 0

Re: Look and feel
by Tim Rowledge 01 Oct '99

01 Oct '99

On Fri 01 Oct, JArchibald(a)aol.com wrote: > --> 10/1/99 4:40:42 AM EDT, apeluso(a)peg.it --> > << I'd like my image to look more similar to my Mac Finder >> > > I want to ask the general question here: ... For _any_ environment, even > Windoze, what is needed to cause separate execution (within the containing OS > environment) of a selected executable from the file system? If you can make, > say, FileList add a menu point to execute the selected file, then basically > you have a Finder, ... right? All you need to add are definition of the > environment, parameters, etc. Then you can roll your own user interface to > fit a desired Look and Feel. Again, right? Within the limited scope of 'how to launch a program from my app', most OSs allow you to somehow spawn a process to execute a command.IIRC you can call DosExec or something like it from windows and pass a string that will then get treated as a command. Thus DosExec("c:/foo/bar/bilbo.exe") would run the bilbo program. I'm sure there are lots of details that differ between platforms. So yes, it should be relatively simple to roll your own Finder/Exploder/DirBrowser/whatever. tim -- "!sgub evah t'nseod CP sihT ?sgub naem ayaddahW" Tim Rowledge: rowledge(a)interval.com (w) +1 (650) 842-6110 (w) tim(a)sumeru.stanford.edu (h) <http://sumeru.stanford.edu/tim>

2 1

Squeak's role in a larger world?
by John Tobler 01 Oct '99

01 Oct '99

Recently, I've seen quite a few posts about putting Java support into Squeak or running Squeak via a Java VM. While discussing the particular case of interaction with Java, perhaps we should contemplate a larger question: "To what degree should Squeak be embeddable and extendable?" We may want to consider various interactions with other languages (e.g. Self, Python, Perl, Tcl-Tk, Rebol, Eiffel, C/C++, etc.). In Python, for example, embeddability and extendability are core concepts in the language design and Python gains considerable power from these mechanisms. Squeak is already extendable, via C/C++. Should it be extendable by other compiled languages? What would this involve? Could Squeak be extended via other interpreted languages? What support would be needed in the class libraries to make Squeak's existing extendability more general? AFAIK, Squeak is not yet embeddable. For what applications might embeddability be desirable? Can a Sqeuak image be somehow packaged as a component? What would be needed to make Squeak available to another language system? I am curious about these questions, in particular, because many very serious programmers are now using scripting languages as glue to bind widely disparate technologies into united solutions to user needs. This trend towards scripting and interacting language systems seems very strong, today, and I'm wondering to what degree Squeak will be able to fit into a scripting-based picture of the future. Ultimately, the question is whether Squeak should be isolationist, standing apart as a completely unique and self-sufficient environment, or cooperative, taking its place in a community of interacting languages. Just musing, /John Tobler _______________________________________________________ Get Visto! Groups, event calendars, email, and more... Check it out @ http://www.visto.com/info

2 1

Re: Squeak on handheld?
by Marc Nijdam 01 Oct '99

01 Oct '99

"John Tobler" <squeakie(a)visto.com> writes: > This is a call for a brief report from you all on which > tiny devices someone has made Squeak-capable (to one degree > or another). > > Recent mention of the Casio E105 (WinCE) and the new Visor > (Palm clone with 8MB of RAM for $250, hardware upgradeable) > has inspired me with technolust! I have examined a number > of messages in the archives but find myself unable to list > precisely which little devices currently support Squeak and > which do not. Should I conclude that currently Palm OS > is "out" and (ouch!) Win CE is "in."" > > The E105 looks really cool, but pricey. I can skip all the > extras but what I *really* want is to be able to tote > everywhere a working Squeak image, including browsers. > Capability to run Morphic would be a big plus but not an > absolute requirement (although the Morphic code would > *have* to be in the image for study and reference purposes). > > Here's my personal wish list. > > * I want something with functioning browsers, > so that I can study the Squeak hierarchy > in my few spare moments. > > * I want a Squeaky device I can grab and use > -- wherever I am -- for image reference and > (at least) limited editing in those odd > mid-night, not-at-home moments when my > muse usually chooses to strike. > > * Laptops, kneetops, and palmtops are too big -- > the thingie must be able to accompany me on > a walk, a bus, an airplane, into a restaurant, > and (especially) into the "little programmers' > room." No, it doesn't have to survive the > shower. > > * Color would be nice but not required. > > * I'm not sure I could justify the bucks for > an E105. I'd like to find something > workable for under $300. > > * I would prefer to avoid paying usury to > the Evil Empire. > > * I live in beautiful San Diego, so my erstwhile > electronic companion must have certain beach > survival skills. > > > So, which are the candidates for "Squeaky Handheld Device > of the Year?" Which might make it into the "almost usable" > category? Which are "gonna be great someday!" Which will > likely always be just a "wannabe"? Not to promote stuff from my employer... but did you consider the Jornada 820. I just got one of them. It's a CE device with a reasonable keyboard. Display is a bit slow (maybe if it would boot Squeak ;-) I've no idea whether Squeak has been ported to it though? Marc

5 5

Jump to page: