Squeak-dev September 1999

squeak-dev@lists.squeakfoundation.org

133 participants
357 discussions

Re: RE: Eliminating assignments and variable syntax (accessors)
by Ivan Tomek 28 Sep '99

28 Sep '99

I would like to join those who oppose this valiant proposal. The main problem for me is that it complicates the beautifully simple and uniform syntax of Smalltalk: As an example, a: b does not have a receiver. I consider the simple syntax one of the great things about Smalltalk both for learning and for code readability. If anything were to be done with variables, I would suggest making them first-class objects. As they are, they are different from everything else and break the uniformity of the language. Assignments could then be handled for example as var assign: x thus removing the need for the assignment statement while maintaining the syntax. A lot of other things could also be done more easily such as (pseudocode) (Array with: selectedVariables) do: [:var| var assign: Strinbg new] instead of a := ''. b := ''. c := ''. etc. Ivan > Thanks for taking the time in looking over my (admittedly pretty > rough) idea. > > > From: "Jarvis, Robert P." <Jarvisb(a)timken.com> > > > > I don't like the idea of implicit targets. One of the great > beauties of > > Smalltalk is its simple and very regular grammar. In my opinion adding > > implicit targets would make the grammar more complex and less regular > > without a corresponding gain in clarity or expressiveness. > > Yes, I also don't want to mess the syntax up. However, for > 'reading' accesses, there is no (visible) change in syntax, it's just > that what used to be variable references are now interpreted as message > sends. That seems like a simplification to me. > > The only 'addition' is that for assigning values, instead of writing: > > a := b. > > you would write > > a: b. > > Considering that the colon syntax is also already in use, and that > := gets removed, that also seems to be a simplification of the > visible syntax, overall (a slight complication and a medium > simplification). As a matter of fact, the compiler could treat a:= as > equivalent to a: I have to admit that I haven't considered what this > will do to the compiler, though. > > > I just don't see > > a great advantage here. It seems more like a hint to the compiler > than an > > aid to the human. > > Well, the aid is that there is now only message sends, assignments > have been eliminated from the language or at least hidden from view. The > practical benefit I have in mind is that the decision wether access to an > instance variables is direct or via accessors is made in one place > instead of everywhere the variable is accessed. Currently, if I have > direct instance variable access, I write. > > myInstanceVar doSomething. > > If I have accessors, I write > > self myInstanceVar doSomething. > > *everywhere* I use myInstanceVar. The same goes for write-access: > > myInstanceVar := newValue > > versus > > self myInstanceVar:newValue. > > The problem is that changes to the access policy are very expensive > because every method *accessing* the instance-var/accessor has to be > changed. Therefore, your (absolutely correct, IMHO) proposition that all > instance var access be done with accessors first and directly only when > absolutely necessary means that a lot of code has to potentially be > modified in the latter case. With lots of coders being prone to > premature optimiziation, they will opt for direct access instead, > especially since it is also less typing. > > With my proposal, code can always be written as if it is using > accessors, making it non-brittle, but at the same time it enjoys all the > benefits cited for direct variable access (privacy, speed, less typing, > etc.) So, I just write > > myInstanceVar doSomething. > and > myInstanceVar:newValue. > > and this very same code will use accessors if available or direct > access if not. > > > Also, if := is eliminated how is a reference assigned to > > a temporary variable? > > Trickery. Just like with instance variables, the compiler detects > that there is a local variable of that name and emits the direct > access code instead. I know this sounds a little insane (turn the > access into a message send and then auto-reduce it back to an > access), but there is some method to the madness :-) > > Regards, > > Marcel > Ivan Tomek, Jodrey School of Computer Science Acadia University Wolfville, Nova Scotia, Canada, B0P 1X0 fax: (902) 585-1067 voice: (902) 585-1467 > Hey, it's monday, I haven't woken up properly yet! It must take you a couple of days because its Tuesday where I am (and all of the world by now) <gg> 8-)

7 13

Can't find any SOCKS
by David N. Smith (IBM) 28 Sep '99

28 Sep '99

Does anyone know of SOCKS support for Squeak (instead of proxy support), or anyone who might be working on it? Are there any rumors of, or code for system level SOCKS support for the Mac? (There is one for Windows called Hummingbird). We unfortunately live behind a SOCKS firewall and have to depend on individual applications (like IE) providing SOCKS support. Thanks, Dave _______________________________ David N. Smith IBM T J Watson Research Center Hawthorne, NY _______________________________ Any opinions or recommendations herein are those of the author and not of his employer.

4 5

RE: [ENH] Empty return expression
by Stephen Pair 28 Sep '99

28 Sep '99

> 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. 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. > For example, Smalltalk give you single static inheritence, but if you > want to implement > multiple or dynamic inheritence, you can. But not easily. > 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. > 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. 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 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

1 0

Re: Can't find any SOCKS
by merlyn＠stonehenge.com 28 Sep '99

28 Sep '99

>>>>> "Joshua" == Joshua Marker <lux(a)umich.edu> writes: Joshua> Oh, god, I really didn't intend to send bad jokes to the entire Joshua> list. Oh, ouch. I'm just going to crawl under my desk now. <meta> Another victim of the *evil* "reply-to" mangling of this list. Oh, when will list maintainers EVER learn? <sigh> .... http://www.unicom.com/pw/reply-to-harmful.html </meta> -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn(a)stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

1 0

RE: [ENH] Empty return expression
by Jarvis, Robert P. 27 Sep '99

27 Sep '99

I don't like this because IMO it obfuscates what's going on without adding value. If you want to answer self in this situation, then type ^self This requires four keystrokes, and it's clear. Besides, if the method is going to answer 'nothing returned' shouldn't it answer nil instead of self? Bob Jarvis The Timken Company > -----Original Message----- > From: Bert Freudenberg [SMTP:bert@isgnw.CS.Uni-Magdeburg.De] > Sent: Monday, September 27, 1999 4:36 AM > To: squeak(a)cs.uiuc.edu > Subject: [ENH] Empty return expression > > Parser patch to allow empty returns that indicate 'nothing returned' like > foo ifTrue: [self doSomething. ^] > instead of the currently often (mis-)used > foo ifTrue: [^self doSomething] > as short form of > foo ifTrue: [self doSomething. ^self] > > Discussion: > This syntax matches the implicit return of self at the end of > a method. It makes the "void" return type of a method explicit, which is > good for self-documenting code. It's backwards compatible. It's a minor > change in the parser. So why not? > > It's not compatible to other Smalltalks - but then, the brace constructs > are even more different. > > /bert << File: >>

3 2

MathMorphs for Squeak 2.5
by Torsten.Bergmann＠phaidros.com 27 Sep '99

27 Sep '99

I've tried to download the MW25.zip from http://mate.dm.uba.ar/~caniglia/mathMorphs.html but the link is broken. Does anyone know the right link ? Torsten

2 1

[ENH] Empty return expression
by Bert Freudenberg 27 Sep '99

27 Sep '99

Parser patch to allow empty returns that indicate 'nothing returned' like foo ifTrue: [self doSomething. ^] instead of the currently often (mis-)used foo ifTrue: [^self doSomething] as short form of foo ifTrue: [self doSomething. ^self] Discussion: This syntax matches the implicit return of self at the end of a method. It makes the "void" return type of a method explicit, which is good for self-documenting code. It's backwards compatible. It's a minor change in the parser. So why not? It's not compatible to other Smalltalks - but then, the brace constructs are even more different. /bert Content-Type: TEXT/PLAIN; charset=US-ASCII; name="return-bf.24Sep148pm.cs" Content-ID: <Pine.LNX.3.96.990927103544.31728U(a)balloon.cs.uni-magdeburg.de> Content-Description: 'From Squeak 2.5 of August 6, 1999 on 24 September 1999 at 1:48:35 pm'! "Change Set: return-bf Date: 24 September 1999 Author: Bert Freudenberg Parser patch to allow empty returns that indicate 'nothing returned' like foo ifTrue: [self doSomething. ^] instead of the currently often (mis-)used foo ifTrue: [^self doSomething] or as short form of foo ifTrue: [self doSomething. ^self]"! !ParseNode class methodsFor: 'accessing' stamp: 'bf 9/24/1999 11:57'! nodeSelf ^NodeSelf! ! !Parser methodsFor: 'expression types' stamp: 'bf 9/24/1999 11:58'! statements: argNodes innerBlock: inner | stmts returns start more blockComment | stmts _ OrderedCollection new. "give initial comment to block, since others trail statements" blockComment _ currentComment. currentComment _ nil. returns _ false. more _ hereType ~~ #rightBracket. [more] whileTrue: [start _ self startOfNextToken. (returns _ self match: #upArrow) ifTrue: [self expression ifFalse: [parseNode _ ParseNode nodeSelf]. self addComment. stmts addLast: (parseNode isReturningIf ifTrue: [parseNode] ifFalse: [ReturnNode new expr: parseNode encoder: encoder sourceRange: (start to: self endOfLastToken)])] ifFalse: [self expression ifTrue: [self addComment. stmts addLast: parseNode] ifFalse: [self addComment. stmts size = 0 ifTrue: [stmts addLast: (encoder encodeVariable: (inner ifTrue: ['nil'] ifFalse: ['self']))]]]. returns ifTrue: [self match: #period. (hereType == #rightBracket or: [hereType == #doIt]) ifFalse: [^self expected: 'End of block']]. more _ returns not and: [self match: #period]]. parseNode _ BlockNode new arguments: argNodes statements: stmts returns: returns from: encoder. parseNode comment: blockComment. ^ true! !

1 0

[GOODIE] Magnifier
by Bert Freudenberg 27 Sep '99

27 Sep '99

A magnifying glass morph. If you drag it around it magnifies the stuff below. It can track the pointer's position, too. Bug: Since it redraws only if the pointer's position changes (to reduce cpu time), you have to move the mouse constantly when magnifying an animation. /bert Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="Magnifier-bf.22Sep359pm.cs" Content-ID: <Pine.LNX.3.96.990927101907.31728M(a)balloon.cs.uni-magdeburg.de> Content-Description: 'From Squeak 2.5 of August 6, 1999 on 22 September 1999 at 3:59:38 pm'! "Change Set: magnifier-bf Date: 16 September 1999 Author: Bert Freudenberg Provides a magnifying glass."! BorderedMorph subclass: #MagnifierMorph instanceVariableNames: 'magnification trackPointer lastPos srcExtent ' classVariableNames: '' poolDictionaries: '' category: 'Morphic-Demo'! !MagnifierMorph commentStamp: 'bf 9/20/1999 16:17' prior: 0! Provides a magnifying glass. Magnifies the morphs below (if grabbed) or the area around the mouse pointer.! !MagnifierMorph methodsFor: 'initialization' stamp: 'bf 9/20/1999 15:54'! initialize super initialize. trackPointer _ true. magnification _ 2. color _ Color black. borderWidth _ 1. lastPos _ self sourcePoint. self extent: 128@128. ! ! !MagnifierMorph methodsFor: 'geometry' stamp: 'bf 9/21/1999 09:31'! borderWidth: anInteger "Grow outwards preserving innerBounds" | c | c _ self center. super borderWidth: anInteger. super extent: self defaultExtent. self center: c.! ! !MagnifierMorph methodsFor: 'geometry' stamp: 'bf 9/21/1999 09:22'! defaultExtent ^(srcExtent * magnification) truncated + (2 * borderWidth)! ! !MagnifierMorph methodsFor: 'geometry' stamp: 'bf 9/21/1999 09:23'! extent: aPoint "Round to multiples of magnification" srcExtent _ (aPoint - (2 * borderWidth)) // magnification. ^super extent: self defaultExtent! ! !MagnifierMorph methodsFor: 'drawing' stamp: 'bf 9/20/1999 15:56'! drawOn: aCanvas super drawOn: aCanvas. "border and fill" aCanvas isShadowDrawing ifFalse: [ "Optimize because #magnifiedForm is expensive" aCanvas image: self magnifiedForm at: self innerBounds origin]! ! !MagnifierMorph methodsFor: 'drawing' stamp: 'bf 9/21/1999 08:51'! hasTranslucentColor "I may show what's behind me, so tell the hand to don't cache" ^self sourceRect intersects: self bounds! ! !MagnifierMorph methodsFor: 'stepping' stamp: 'bf 9/20/1999 15:34'! step lastPos = self sourcePoint ifFalse: [self changed]! ! !MagnifierMorph methodsFor: 'stepping' stamp: 'bf 9/18/1999 19:25'! stepTime ^50! ! !MagnifierMorph methodsFor: 'events' stamp: 'bf 9/18/1999 20:42'! handlesMouseDown: evt ^evt yellowButtonPressed or: [super handlesMouseDown: evt]! ! !MagnifierMorph methodsFor: 'events' stamp: 'bf 9/21/1999 10:45'! mouseDown: evt evt yellowButtonPressed ifTrue: [self chooseMagnification: evt] ifFalse: [super mouseDown: evt]! ! !MagnifierMorph methodsFor: 'menu' stamp: 'bf 9/20/1999 15:53'! addCustomMenuItems: aCustomMenu hand: aHandMorph super addCustomMenuItems: aCustomMenu hand: aHandMorph. aCustomMenu addLine; add: 'magnification...' action: #chooseMagnification; addUpdating: #trackingPointerString action: #toggleTrackingPointer.! ! !MagnifierMorph methodsFor: 'menu' stamp: 'bf 9/20/1999 13:54'! chooseMagnification | result | result _ (SelectionMenu selections: #(1.5 2 4 8)) startUpWithCaption: 'Choose magnification (currently ', magnification printString, ')'. (result isNil and: [magnification ~= result]) ifFalse: [ magnification _ result. self extent: self extent. "round to new magnification" self changed].! ! !MagnifierMorph methodsFor: 'menu' stamp: 'bf 9/21/1999 12:09'! chooseMagnification: evt | handle origin aHand currentMag | currentMag _ magnification. aHand _ evt ifNil: [self currentHand] ifNotNil: [evt hand]. origin _ aHand gridPointRaw y. handle _ HandleMorph new forEachPointDo: [:newPoint | self magnification: (newPoint y - origin) / 8.0 + currentMag]. aHand attachMorph: handle. handle startStepping. self changed. "Magnify handle"! ! !MagnifierMorph methodsFor: 'menu' stamp: 'bf 9/20/1999 15:48'! toggleTrackingPointer trackPointer _ trackPointer not! ! !MagnifierMorph methodsFor: 'menu' stamp: 'bf 9/20/1999 15:49'! trackingPointerString ^trackPointer ifTrue: ['stop tracking pointer'] ifFalse: ['start tracking pointer']! ! !MagnifierMorph methodsFor: 'magnifying' stamp: 'bf 9/21/1999 12:27'! magnification: aNumber | c | magnification _ aNumber min: 8 max: 0.5. magnification _ magnification roundTo: (magnification < 3 ifTrue: [0.5] ifFalse: [1]). srcExtent _ srcExtent min: (512@512) // magnification. "to prevent accidents" c _ self center. super extent: self defaultExtent. self center: c.! ! !MagnifierMorph methodsFor: 'magnifying' stamp: 'bf 9/21/1999 08:46'! magnifiedForm | srcRect form | lastPos _ self sourcePoint. srcRect _ self sourceRectFrom: lastPos. "cheaper method if the source is not occluded" form _ (srcRect intersects: self bounds) ifTrue: [self world patchAt: srcRect without: self andNothingAbove: false] ifFalse: [Display copy: srcRect]. "smooth if non-integer scale" ^form magnify: form boundingBox by: magnification smoothing: (magnification isInteger ifTrue: [1] ifFalse: [2]). ! ! !MagnifierMorph methodsFor: 'magnifying' stamp: 'bf 9/20/1999 15:38'! sourcePoint "If we are being dragged use our center, otherwise use pointer position" ^(trackPointer not or: [owner isKindOf: HandMorph]) ifTrue: [self center] ifFalse: [self currentHand lastEvent cursorPoint]! ! !MagnifierMorph methodsFor: 'magnifying' stamp: 'bf 9/21/1999 08:47'! sourceRect ^self sourceRectFrom: self sourcePoint ! ! !MagnifierMorph methodsFor: 'magnifying' stamp: 'bf 9/21/1999 09:16'! sourceRectFrom: aPoint ^(aPoint extent: srcExtent) translateBy: (srcExtent // -2). ! !

1 0

[FIX] Named primitive stepping
by Bert Freudenberg 27 Sep '99

27 Sep '99

Fixes a walkback when simulating the new compiled primitive stuff, and a typo in one example. /bert Content-Type: TEXT/PLAIN; charset=US-ASCII; name="CcgStepFix-bf.27Sep854am.cs" Content-ID: <Pine.LNX.3.96.990927102232.31728O(a)balloon.cs.uni-magdeburg.de> Content-Description: 'From Squeak 2.6alpha of August 6, 1999 on 27 September 1999 at 8:54:14 am'! "Change Set: CcgStepFix-bf Date: 27 September 1999 Author: Bert Freudenberg Fixes a walkback when simulating the new compiled primitive stuff, and a typo in one example"! !FlippyArrayPlugin2 methodsFor: 'as yet unclassified' stamp: 'bf 9/24/1999 14:39'! primReverse | rcvr t a b | rcvr _ self primitive: 'primReverse' parameters: #() receiver: #Array. a _ 0. b _ rcvr size - 1. [a < b] whileTrue: [t _ rcvr at: a. rcvr at: a put: (rcvr at: b). rcvr at: b put: t. a _ a + 1. b _ b - 1]. ^rcvr asOop: Array! ! !TestCodeGenerator methodsFor: 'C linkage new' stamp: 'bf 9/24/1999 14:53'! ccgValBlock: valString ^[:index | String streamContents: [:aStream | aStream nextPutAll: 'interpreterProxy success: (interpreterProxy '; nextPutAll: valString; nextPutAll: ': (interpreterProxy stackValue: '; nextPutAll: index asString; nextPutAll: '))']] fixTemps! !

1 0

[ENH] DepthMenu
by Bert Freudenberg 27 Sep '99

27 Sep '99

Changes the 'set display depth...' menu to only offer supported display depths. Requires my MiscFixes change set posted earlier. /bert Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="DepthMenu-bf.22Sep334pm.cs" Content-ID: <Pine.LNX.3.96.990927100243.31728C(a)balloon.cs.uni-magdeburg.de> Content-Description: 'From Squeak 2.5 of August 6, 1999 on 22 September 1999 at 3:34:15 pm'! "Change Set: depthmenu-bf Date: 18 September 1999 Author: Bert Freudenberg Changes the 'set display depth...' menu to only offer supported display depths."! !DisplayScreen methodsFor: 'other' stamp: 'bf 9/18/1999 19:46'! supportedDisplayDepths "Return all pixel depths supported on the current host platform." ^#(1 2 4 8 16 32) select: [:d | self supportsDisplayDepth: d]! ! !HandMorph methodsFor: 'world menu commands' stamp: 'bf 9/18/1999 20:02'! setDisplayDepth "Let the user choose a new depth for the display. " | result oldDepth | oldDepth _ Display depth. (result _ (SelectionMenu selections: Display supportedDisplayDepths) startUpWithCaption: 'Choose a display depth (it is currently ' , oldDepth printString , ')') == nil ifFalse: [Display newDepth: result]. (World isMorph and: [(Display depth < 4) ~= (oldDepth < 4)]) ifTrue: ["Repaint windows since they look better all white in depth < 4" (SystemWindow windowsIn: World satisfying: [:w | true]) do: [:w | w updatePaneColors]]! ! !ScreenController methodsFor: 'menu messages' stamp: 'bf 9/18/1999 20:01'! setDisplayDepth "Let the user choose a new depth for the display. " | result | (result _ (SelectionMenu selections: Display supportedDisplayDepths) startUpWithCaption: 'Choose a display depth (it is currently ' , Display depth printString , ')') == nil ifFalse: [Display newDepth: result]! !

1 0

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

Jump to page: