Squeak-dev September 1998

squeak-dev@lists.squeakfoundation.org

108 participants
197 discussions

Re: Scientific Computing
by stp＠limbo.create.ucsb.edu 02 Sep '98

02 Sep '98

Kyle is right that there are some limitations to the kinds of Smalltalk that the Sq-C translator can handle, but it's great for loops containing numerical operations (of the kind used in the scientific applications we're talking about). It's certainly not "limited" to translating VM code (look at the sound synthesis examples again). Since the translator is pretty simple, it uses whatever algorithm design you write in Smalltalk. It would be an interesting experiment to look at the difference between a simple look-up-based oscillator (like the one currently implemented) and a fancier table-free fast design such as James McCartney's (described in a letter in Computer Music Journal a year or so ago). I see no reason that the translated version should be much slower than the native C version. stp _ Stephen Travis Pope _ Center for Research in Electronic Art Technology (CREATE) _ Dept. of Music, Univ. of California, Santa Barbara (UCSB) _ stp(a)create.ucsb.edu, http://www.create.ucsb.edu/~stp/

1 0

RE: Polymorphism without protocol dilution
by David N. Smith 02 Sep '98

02 Sep '98

>At 9:01 -0400 9/2/98, Jarvis, Robert P. wrote: >There's something here I'm probably just not getting, but I don't >see the value (no pun intended) of having Dictionary>>at:ifAbsentPut: >work differently for blocks vs. other objects. Bob Arning suggests >that we should have > >d at: k ifAbsentPut: 0 "inserting (and returning) 0 if k is not a key in d" >d at: k ifAbsentPut: aBlock "inserting (and ^) the result of >evaluating <aBlock>" >d at: k ifAbsentPut: [aBlock] "inserting (and ^) aBlock" > >Why not just have Dictionary>>at:ifAbsentPut: add and return the 'ifAbsentPut' >object? If you want to shove a non-Block object in, fine. If you want to >put the >result of evaluating a Block into the dictionary then you'd write > > d at: k ifAbsentPut: aBlock value > >If you want to put a Block into a dictionary, then write > > d at: k ifAbsentPut: aBlock > >I don't understand why Dictionary>>at:ifAbsentPut: should be special-cased >for Blocks, as it doesn't seem necessary to me. The code: d at: k ifAbsentPut: aBlock has the advantage of not evaluating aBlock unless needed. The evaluation might involve some computation which you'd want to avoid unless necessary. >One other thing - I don't understand why the last two of Bob's examples >are different. It seems to me that what's being said is that > > aBlock := [ "do something" ] > d at: k ifAbsentPut: aBlock > >and > > d at: k ifAbsentPut: [ "do something" ] > >are somehow different. I don't see how the method would know >the difference. (I suspect that ten seconds after sending this >message I'll suddenly figure this out and be very embarassed :-). Me either. I think he must have something else in mind. 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.

1 0

Re: Polymorphism without protocol dilution
by Bob Arning 02 Sep '98

02 Sep '98

Dave, I'm not sure I parsed this as you intended: On Tue, 1 Sep 1998 16:55:11 -0400 "David N. Smith" <dnsmith(a)watson.ibm.com> wrote: >I don't think of this as a type issue, but an evaluation issue. When is the >parameter evaluated: when first passed, when about to insert it into the >collection (lazy evaluation), or never? I claim one needs all three. > > >#at:ifAbsentPut:, as implemented elsewhere, evaluates the parameter >expression before the message is sent. If it is a block then the block is >put into the collection. > Are you referring to actual implementations? I seem to recall from VSE work that if the second argument is a block, then it is #value'd if the key does not exist and the result is added. Perhaps this was a local implementation (I cannot recall at this point) - do different implementations exist? > >#at:ifAbsentPut:, as proposed, would allow a block and evaluate its >contents before putting the result into the collection. However, this >prevents actually putting a block into the collection without an ugly >contortion: > > dict at: aKey ifAbsentPut: [ [ blockCode ] ] > It seems to me that there is a limit to this criticism: sometimes we want to insert a simple value into the dictionary, sometimes we want to to insert a simple value resulting from evaluation of a block, or we might want to insert a block obtained from evaluating a block, such as: d at: key ifAbsentPut: [b ifTrue: [[:x | x doSomething]] ifFalse: [[:x | x doSomethingElse]]] or even deeper levels of nested evaluation. > >#at:ifAbsentPutValueOf: makes this explicit. One is not putting the block >into the collection, but the result of evaluating the block. > > >Note that, for consistancy, if the thrid example is considered wrong, one >should then make #at:put: have the same properties as #at:ifAbsentPut:. If >a block is passed it is evaluated before putting its value into the >collection. I think (for internal consistency, at least) that we need to consider other #xxx:ifXxx: protocols: e.g.: Collection>>detect:ifNone: evaluates the second argument only if no matching element is found. FWIW: Symbol allInstances select: [ :x | (x findString: ':if' startingAt: 1) > 0] returns 59 Symbols in my image, and a cursory check suggests that they only evaluate the ifXxx: argument only when needed. Personally, I would like to write: d at: k ifAbsentPut: 0 "inserting (and returning) 0 if k is not a key in d" d at: k ifAbsentPut: aBlock "inserting (and ^) the result of evaluating <aBlock>" d at: k ifAbsentPut: [aBlock] "inserting (and ^) aBlock" but I could easily live with: d at: k put: [0] "to insert and return 0" Cheers, Bob

2 1

#ifAbsentPut: - a summary
by Bob Arning 02 Sep '98

02 Sep '98

I think it will help me and perhaps others to see some of the examples that have been suggested listed together for comparison. If I haven't fairly stated your favorite, chime in. If I have, which one is it? I have ommitted other new methods that might be required to implement these proposals in order to focus more clearly on how one would write code to put the desired vales into a Dcitionary -------- 1. Which we might call the #ifAbsentPutValueOf: proposal d at: k ifAbsentPut: 7. "<- puts a value" d at: k ifAbsentPut: [7]. "<- puts a block" d at: k ifAbsentPutValueOf: 7. "<- is this allowed??" d at: k ifAbsentPutValueOf: [7]. "<- puts a value" -------- 2. Which we might call the simple #ifAbsentPut: proposal d at: k ifAbsentPut: 7. "<- puts a value" d at: k ifAbsentPut: [7]. "<- puts a value" d at: k ifAbsentPut: [[7]]. "<- puts a block" -------- 3. Which we might call the extended #ifAbsentPut: proposal. Rather than being a true proposal, I think this was an extension of #2 to provide greater consistency d at: k ifAbsentPut: 7. "<- puts a value" d at: k ifAbsentPut: [7]. "<- puts a value" d at: k ifAbsentPut: [[7]]. "<- puts a block" so far the same as #2, but now we require that d at: k put: 10 factorial "puts a 3628800" d at: k put: [10 factorial] "puts a 3628800" d at: k put: [ [10 factorial] ] "puts a block" the obvious conclusion being that this would break things left and right. ========= Cheers, Bob

1 0

Concerning #ifAbsentPut:
by Bob Arning 02 Sep '98

02 Sep '98

Hi Bob, I think it may prove useful to create a summary of the different proposals so we can compare them side-by-side. I'll try to put this together shortly. On Wed, 2 Sep 1998 09:01:06 -0400 "Jarvis, Robert P." <Jarvisb(a)timken.com> wrote: >There's something here I'm probably just not getting, but I don't >see the value (no pun intended) of having Dictionary>>at:ifAbsentPut: >work differently for blocks vs. other objects. Bob Arning suggests >that we should have > >d at: k ifAbsentPut: 0 "inserting (and returning) 0 if k is not a key in >d" >d at: k ifAbsentPut: aBlock "inserting (and ^) the result of evaluating ><aBlock>" >d at: k ifAbsentPut: [aBlock] "inserting (and ^) aBlock" > >Why not just have Dictionary>>at:ifAbsentPut: add and return the >'ifAbsentPut' >object? If you want to shove a non-Block object in, fine. If you want >to put the >result of evaluating a Block into the dictionary then you'd write > > d at: k ifAbsentPut: aBlock value > What I don't like about this is that you would always evaluate <aBlock> whether you needed the result or not. >If you want to put a Block into a dictionary, then write > > d at: k ifAbsentPut: aBlock > >I don't understand why Dictionary>>at:ifAbsentPut: should be >special-cased >for Blocks, as it doesn't seem necessary to me. > Depends on how you look at it: all the other #ifXxxx: protocols evaluate the argument if and only if certain conditions are met. From this perspective, the only "special case" is to allow objects other than blocks (such as integers, strings, etc) to understand #value. Some have complained that this dilutes the #value protocol, but I am comfortable with it. >One other thing - I don't understand why the last two of Bob's examples >are different. It seems to me that what's being said is that > > aBlock := [ "do something" ] > d at: k ifAbsentPut: aBlock > >and > > d at: k ifAbsentPut: [ "do something" ] > >are somehow different. I don't see how the method would know >the difference. (I suspect that ten seconds after sending this >message I'll suddenly figure this out and be very embarassed :-). If, by the last two, you mean: >d at: k ifAbsentPut: aBlock "inserting (and ^) the result of evaluating ><aBlock>" >d at: k ifAbsentPut: [aBlock] "inserting (and ^) aBlock" then, I might rewrite them as d at: k ifAbsentPut: [3+4] "inserts a SmallInteger 7" d at: k ifAbsentPut: [[3+4]] "inserts a block which, when later #value'd, will answer 7" which would be equivalent to: aBlock _ [3+4]. d at: k ifAbsentPut: aBlock. "inserts a SmallInteger 7" d at: k ifAbsentPut: [aBlock] . "inserts a block which, when later #value'd, will answer 7" Cheers, Bob

1 0

Re: Squeak VM 2.1 for HP/UX available
by Georg Gollmann 02 Sep '98

02 Sep '98

At 10:09 Uhr +0200 02.09.1998, Markus Kohler wrote: >I used egcs and the result seems to be pretty fast. The "gnuified" >interpreter is much faster than the non "gnuifed" one. >I get around 9000000 bytecodes/sec with egcs and only around 7000000 >bytecodes/sec with HP's ansi cc. >All that on a HP C180. I have used gcc and get about 2460000 bytecodes/sec on a E35 (65 MHz). Georg ---- Dipl.Ing. Georg Gollmann TU-Wien, EDV-Zentrum phon:(+43-1) 58801 - 5848 fax: (+43-1) 587 42 11 mail:gollmann@edvz.tuwien.ac.at http://macos.tuwien.ac.at/Gollmann.html

1 0

Squeak VM 2.1 for HP/UX available
by Georg Gollmann 02 Sep '98

02 Sep '98

Binaries for HP/UX 10.20 (with and without head) of the Squeak 2.1 VM compiled from Ian Piumarta´s distribution are available at http://macos.tuwien.ac.at/Squeak/HP%2FUX/ Georg ---- Dipl.Ing. Georg Gollmann TU-Wien, EDV-Zentrum phon:(+43-1) 58801 - 5848 fax: (+43-1) 587 42 11 mail:gollmann@edvz.tuwien.ac.at http://macos.tuwien.ac.at/Gollmann.html

1 0

Re: Base image
by m3rabb＠stono.com 02 Sep '98

02 Sep '98

At 12:34 PM 9/1/98, Tim Rowledge wrote: >I'm inclined to agree; weak pointer stuff would help a lot with releasing >external resources (like files and eventually windows etc) and external api >stuff would provide the door to the factoring of the VM that Travis >suggested. >The weak pointers probalby need to go into the base VM since it involves >detailed gc changes. I can't easily see them being a simple add-in. >Similarly, the external api stuff would probably need to be there in order >to load the external api stuff if it wasn't already there... Has anyone successfully recompiled the Mac VM to include WeakArrays and/or sqAPI yet? It would be great if this Squeak geek would make it and a virgin image available (ala STP). --Maurice --------------------------------------------------------------------------- Maurice Rabb 773.281.6003 Stono Technologies, LLC Chicago, USA

3 2

Re: Base image, Windows look
by Doug Way 02 Sep '98

02 Sep '98

> > However, while Tk (the widget set) isn't bad, Tcl is a pretty > limited language for UI development... Smalltalk is far superior. > Since Squeak is also free and very portable, it could potentially be a > much better alternative in this "market". It just needs some more > work in the Windows/Mac look & feel area, plus Morphic being > stabilized a bit more. > > On Tue, 1 Sep 1998, Markus Kohler wrote: > > I thought about that too. Tk has the advantage of being crossplatform. > What's unclear to me is the license for Tk. I looked on their web page > (www.scriptics.com) but didn't find any specific. > > There are other problems too. I think it would be pretty hard to make > native Morphic (based on Tk) and emulated Morphic compatible. Actually, I wasn't advocating getting Squeak to support Tk (my paragraph was a little misleading), I was just saying that if Squeak had a reasonable set of Windows-like emulated widgets (in Morphic or MVC), it could potentially be an alternative to the Tk family. Mostly because Squeak and Tk cover similar ground in terms of both being free and oriented towards developing portable UI's with a higher-level language. Squeak is obviously the more flexible/powerful of the two while Tk is more commercially robust & industry-standard-UI friendly. Creating a nice set of Windows-emulated widgets from scratch with Morphic or MVC is no small task, I admit, and it wouldn't have to be part of the base image. Adding Tk support for Squeak is an interesting idea, and might be easier than creating emulated widgets from scratch, but emulated widgets seems more like the "ultimate" solution which would work on *all* platforms... more in tune with the Squeak philosophy in that sense. On Tue, 1 Sep 1998, Georg Gollmann wrote: > Please note that Squeak has perfectly usable error handling already > (BlockContext>ifError:). Sorry about that... I brought up exceptions as an example without really knowing the details of how Squeak does error handling. I'm familiar with exception handling in other smalltalks, and had heard about an exception handling goodie for Squeak, and noticed that Squeak had no Exception or Signal classes, and kind of went from there... :-) - Doug Way dway(a)mat.net dway(a)transom.com http://www.transom.com

1 0

Polymorphism without protocol dilution
by m3rabb＠stono.com 02 Sep '98

02 Sep '98

I would appreciate any thought on the following: I though I would add the common method #at:ifAbsentPut: to Dictionary. As the convention varies between dialects, I though it would be useful for the 'ifAbsentPut: parameter' to accept either a value, or a block to be evaluated. My first iteration was: at: key ifAbsentPut: valueObject ^self at: keyObject ifAbsent: [self at: key put: valueObject value] For this to work would require that I add Object>>#value which I remember is a no-no, because it dilutes the BlockContext protocol as Object>>#do: diluted the Collection protocol. We replaced Object>>#do: with #in:, so with what do we replace Object>>#value? Two sets of solutions come immediately to mind: 1) BlockContext>>#selector1 ^self value Object>>#selector1 ^self at: key ifAbsentPut: valueObject ^self at: key ifAbsent: [self at: key put: valueObject selector1] selector1 could be one of the following: a) evaluate b) evaluated c) simplify d) simplified e) asValue f) asValueObject g) asEvaluated h) asEvaluatedObject i) asImmediate j) asImmediateObject 2) BlockContext>>#selector2 ^self Object>>#selector2 ^[self] at: key ifAbsentPut: valueObject ^self at: key ifAbsent: [self at: key put: valueObject selector2 value] selector2 could be one fo the following: a) asBlock b) asBlockContext c) asAction Of my suggestions I prefer set 1 over 2 because set 2 seems more circuitous. Of set 1 I prefer option e. Unfortunately, asValue is already used in other dialects to convert an Object to a ValueHolder/ValueModel. I wish they uses asValueModel (or stuck with ValueModel on: anObject) instead. As far as names go I often wish some of the more fundamental methods were better named so that I could use the name which they currently occupy for something more appropriate (IMHO). Which technique and selector name is recommended? --Maurice --------------------------------------------------------------------------- Maurice Rabb 773.281.6003 Stono Technologies, LLC Chicago, USA

4 5

Jump to page: