Squeak-dev September 1998

squeak-dev@lists.squeakfoundation.org

108 participants
197 discussions

#at:ifAbsent... (was: Polymorphism without protocol dilution)
by m3rabb＠stono.com 03 Sep '98

03 Sep '98

At 8:13 PM 9/1/98, Bob Arning wrote: >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. >> Correct me if I am wrong, but I think you misunderstood what Dave is saying. If we use the proposed methods: The parameter is evaluated when it is first passed: dict at: '200!' ifAbsentPut: (200 factorial). "<- puts a value" The parameter is evaluate when it about to be inserted: dict at: '55!' ifAbsentPutValueOf: [55 factorial] "<- puts a value" The parameter is never evaluated. (It is just inserted): dict at: '10! calculation' ifAbsentPut: [10 factorial]. "<- puts a block" dict at: '10!' ifAbsentPut: 3628800 "<- puts a value" At no point is he suggesting that the ifAbsent: or ifAbsentValueOf: parameter be used or evaluated inside the method unless the #at: fails to find the key. He is _not_ suggesting that we break from the consistent behavior of all the other ifXxxx: protocols. >>#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. >> Again this is what he means: anInteger _ dict at: '22!' ifAbsentPut: (22 factorial) ^ "evaluates the parameter expression before the message is sent" ---| aBlock _ dict at: 'bobs example' ifAbsent: (aBoolean ifTrue: [ [:x | x doSomething] ] ifFalse: [ [:x | x doSomethingElse] ]) ^ "evaluates the parameter expression before the message is sent" ---| >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? > Yes, unfortunately different dialects of Smalltalk implement #at:ifAbsentPut: with different semantics. Some insert the second parameter whether it is a block or a simple object (as we propose). Others insert either a simple value, or the value of a block if it is a block. [munch] >>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. To restate the above: If #at:ifAbsentPut: behaves such that it accepts either a simple value or a block, using the value of the block if it is a block, then #at:put: should behave the same. Thus: dict at: 1 put: 10 factorial "puts a 3628800" dict at: 2 put: [10 factorial] "puts a 3628800" dict at: 3 put: [ [10 factorial] ] "puts a block" IMHO, these semantics are not just ugly, but "astonishing"! I vote for Dave's. Dave, please correct me if I got this all wrong. --Maurice --------------------------------------------------------------------------- Maurice Rabb 773.281.6003 Stono Technologies, LLC Chicago, USA

5 5

Re: Scientific Computing
by m3rabb＠stono.com 03 Sep '98

03 Sep '98

At 10:41 AM 9/2/98, Dan Ingalls wrote: >P.S. For various reasons that have been discussed on this list before >(notably sound and image processing), it is likely that we will soon add >some Float array operations to Squeak. It may be that we will do this by >using a general API, but we have not yet sorted out all the portability vs >VM size issues. > At 4:32 PM 6/12/98, Andreas Raab wrote: >Hans-Martin, > >> I would propose to go further than that and change the format of Floats >> as well, to make all float-containing objects be usable from the >> platform without special macros. > >I agree. There are only a few locations where the order of Floats is >important and those could be changed to use selectors like #highWord and >#lowWord instead of #basicAt: > >> However, this opens another, more difficult, question: >> Since doubles on some platforms have to be 8-byte aligned, objects (at >> least those potentially containing doubles) should probably be aligned >> on 8-byte minus 4. > >The alternative would be using single precision floats in the FloatArrays. >Actually, I was investigating this since the storage overhead of double >precision floats outweighs the improved precision in a number of >applications (say in 3D graphics where you have literally millions of >them). > >Bye, > Andreas Dan-- I hope that the Float arrays will be single precision. Beyond 8-byte alignment and extra storage issues, there is a compelling performance issue as well. The PPC supports a pipelined multiply-accumulate instruction for single precision numbers. When methods for image/signal processing applications are translated to C it would be nice for the C-compiler to be able to make use of the mult-accum hardware. Has there ever be discussion of making Squeak use intrinsic 30-bit SmallFloats like it uses SmallInteger? Are both object pointer tag bits already used? --Maurice --------------------------------------------------------------------------- Maurice Rabb 773.281.6003 Stono Technologies, LLC Chicago, USA

2 1

TextAttributes
by Gerardo Richarte (CORE-SDI) 02 Sep '98

02 Sep '98

Hi! Is anybody using TextAttributes at all? It was not working properly in Morphic, has anybody noticed this? We (in Mathematical Squeak Project) are using it a lot, and found some problems when trying to use it inside Morphic, as we are currently moving everything into morphic they are very important to us. There is a new version of TextAttributes that works in Morphic. It also includes a Preference setting to avoid answering if you want the method saved with style every time. As usual it includes TextPrintIt attribute and multiple selections. Attributted Bye! Richie++ PS: You can get it from http://www.sugarweb.com, the right file to get is TextAttr2.zip (http://www.sugarweb.com/Miniatures/files/TextAttr2.zip) TextAttr.zip is for Squeak v1.32

1 0

Re: Polymorphism without protocol dilution
by stp＠limbo.create.ucsb.edu 02 Sep '98

02 Sep '98

I'd like to speak for the camp of programmers who think that protocol dilution is a good thing. Having written my own inspectors, I'm happy that Object implements at:put:. I'm also known for putting a value method in Object (^self) and have even implemented value: (^self -> argument). The Smoke music representation language (part of Siren) "pollutes" Object with coercion methods such as sec, hz, beat, dB, etc., and also adds about 10 testing methods (isEvent, isTreeAccessor, isMusicMagnitude). Having value implemented in Object makes all sorts of block tricks possible, and enables the dynamic value framework (Kernel-Values category) that I put in the STP12 goodies. There is indeed a point where Object get overloaded, but I especially feel that having every object have value behaviors is quite useful (in the flavor of functional languages--whi differentiate between immediate and computed values, or eager or lazy evaluation...). 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/

2 1

Question about MessageTally>>spyOn:
by m3rabb＠stono.com 02 Sep '98

02 Sep '98

The **Tree** part of the result is the percentage of time spent in any section of the running code. The **Leaves** part is the percentage of time spent in each leave. What does it consider a leave? Also what does the "- <some-number> tallies." at the top mean? --Maurice --------------------------------------------------------------------------- Maurice Rabb 773.281.6003 Stono Technologies, LLC Chicago, USA

2 1

Re: Smalltalk is a tidier functional language than Scheme
by Ken Dickey 02 Sep '98

02 Sep '98

>I'll tell you why. The "better" or more definitive solutions just aren't >profitable. If anybody could get their work done easily and cheaply, who >could sell a working force for the kind of money this industry is >manipulating? There is another reason. If you are building applications in a dynamic language, you have a competative advantage in that you can feature evolve faster than your competition which uses C/C++/<whatever>. On the other hand, if you tell people that "this app was written in Scheme/Lisp/Smalltalk/<dynamic>", people question the choice of language rather than really looking at the application. So most of the real success stories never get told. A basic problem I find is that many people assume a sw technology solution as opposed to understanding the design space and doing the cost/benefit for particular projects which shows which development technology to use. Having the marketing VP dictate choice of implementation technology is kind of like being an engineer designing a bridge and being questioned on why you are choosing a particular kind of steel and concrete. The thing to do is be an engineer and talk about functional requirements like carrying capacity and geology of support structures, etc. For some projects C/C++/machine-language is the best solution. But trying to scale up device-driver technology to use in major projects is like trying to scall up wood from building small dams to build Hoover scale dams--the implementation technology works well in the small but does not always scale. Sense of scale, knowing technology match to design and business requirements, and cost/benefit are the ways to convince upper management that particular technology choices make sense. [Aside: I find it interesting that the trend to open source software (GNU, Linux, Squeak, &c) are catching on in the business world]. Cheers, -KenD

1 0

Re: Scientific Computing
by Kyle Pierce on SNI 02 Sep '98

02 Sep '98

-----Original Message----- From: Stephen Travis Pope <stp(a)limbo.create.ucsb.edu> To: squeak(a)cs.uiuc.edu <squeak(a)cs.uiuc.edu> Date: Wednesday, September 02, 1998 9:55 AM Subject: Re: Scientific Computing > >Let's not forget the Smalltalk-to-C translator in Squeak. In fact, this is >the perfect medium between performance and malleability. High-level >algorithms for any domain can be debugged in Smalltalk and then translated >and batch compiled (and optimized) by your favorite C compiler. This is >preferable to optimizing single floating-point math operations. > >There are examples of this in John Maloney's sound synthesis classes and in >the FFT class. I'm working on a bunch more for Siren; it's great! (and it's >something that Java just can't do!) I had the impression that the Smalltalk-to-C translator in Squeak is limited in terms of the breadth of possible Smalltalk functions that it can translate. That is, it does a great job of translating the essential Squeak VM into C, but was never intended for much more than that. I thought I would have to write extensions in C in order to get that kind of performance improvement in any kind of app-specific code. Can anyone identify what the practical limits are to this translation facility? (I posted the same question awhile back, but got no responses). Thanks, Kyle Pierce

2 1

RE: #ifAbsentPut: - a summary
by m3rabb＠stono.com 02 Sep '98

02 Sep '98

Hmmm, Perehps the sharp division on the prefered behavior of #at:ifAbsent: is a good reason not to include it in the base system. ;-) --Maurice --------------------------------------------------------------------------- Maurice Rabb 773.281.6003 Stono Technologies, LLC Chicago, USA

1 0

Re: Scientific Computing
by m3rabb＠stono.com 02 Sep '98

02 Sep '98

> >I had the impression that the Smalltalk-to-C translator in Squeak is limited >in terms of the breadth of possible Smalltalk functions that it can >translate. That is, it does a great job of translating the essential Squeak >VM into C, but was never intended for much more than that. I thought I >would have to write extensions in C in order to get that kind of performance >improvement in any kind of app-specific code. Can anyone identify what the >practical limits are to this translation facility? (I posted the same >question awhile back, but got no responses). > >Thanks, > >Kyle Pierce Right now the ST->C translator seems to be only good for method by method translation. It doesn't appear to be straight forward to use on whole classes because it doesn't handle self at all. You may have noticed that methods that have been turned into primitives must pass self as an explicit parameter. For example: bitmap compress: bitmap toByteArray: byteArray. --Maurice --------------------------------------------------------------------------- Maurice Rabb 773.281.6003 Stono Technologies, LLC Chicago, USA

1 0

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

02 Sep '98

Let's not forget the Smalltalk-to-C translator in Squeak. In fact, this is the perfect medium between performance and malleability. High-level algorithms for any domain can be debugged in Smalltalk and then translated and batch compiled (and optimized) by your favorite C compiler. This is preferable to optimizing single floating-point math operations. There are examples of this in John Maloney's sound synthesis classes and in the FFT class. I'm working on a bunch more for Siren; it's great! (and it's something that Java just can't do!) 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/

2 1

Jump to page: