Squeak-dev December 2004

squeak-dev@lists.squeakfoundation.org

194 participants
491 discussions

Object turnover.
by Ryan Zerby 03 Dec '04

03 Dec '04

Should I worry about having a program that makes a large number of temporary objects? I made a little "Solar system" that has planets going around a star (using polar coordinates, offset from the star).. so, each step, I do something like: planet position: (Point r: rho degree: theta) + self center. This creates a lot of points that get discarded on the next iteration of step. I can run several hundred planets before the slowdown becomes unbearable. However, If this were a morph that I planned on sharing, it might drain resources from other objects. Should I worry about this object turnover, or is the system designed to handle this high object turnover? Just trying to get my head around some of the issues of efficient squeak code..

6 7

Squeakmap down?
by Frank Shearar 03 Dec '04

03 Dec '04

map1.squeakfoundation.org gives a proxy error (502) when I browse to it; SqueakMap tells me that no master servers are available (this includes map.squeak.org and anakin.bluefish.se). frank ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent RNID policy. If you are not the intended recipient you are advised that any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. If you have received this email in error please notify the RNID Helpdesk by telephone on: +44 (0) 207 296 8282. The Royal National Institute for Deaf People Registered Office 19*23 Featherstone Street London EC1Y 8SL No. 454169 (England) Registered Charity No. 207720 ********************************************************************

3 2

Re: Object turnover.
by Chris Muller 03 Dec '04

03 Dec '04

> Should I worry about this object turnover, or is the system designed > to handle this high object turnover? Just trying to get my head > around some of the issues of efficient squeak code.. Hi Ryan, in my experience, turnover is not something to "worry" about as much as something to be "aware" of. While it is amazing how fast the garbage-collector can turn over objects, I've observed that reducing allocation *can* help when, for example, you have a performance-sensitive portion of your program. You may discover it is creating many thousands of objects where it could simply reuse one would probably show up in the profiler (i.e., TimeProfileBrowser). The author of the read that Andreas kindly shared also acknowledges allocation is not free; he was amazed when VW only took 1 second compared to 9 for C but then explained why; the allocation didn't happen. I do generally prefer to, "optimize later, as-needed." Cheers, Chris

1 0

Adding loop primitives/optimizations (was Making Set/Dictionaryetc. loops more robust)
by Joshua Scholar 03 Dec '04

03 Dec '04

You keep talking about the performance hit of locking the array... I don't know what Slang support for garbage collection has been written but all you need is something that should be free! All you want is to make sure that the array you're iterating over doesn't go away until after the iteration is done. One of these two things (some form of this is NECESSARY if you ever want run bytecodes in parallel with Slang code or call bytecodes from Slang code): 1. The ability to register some Slang/C variables with the garbage collector so that what they point at will not be collected and so that those variables will be updated if the object moves. or 2. The ability to register some variables Slang/C variables with the garbage collector so that what they point at will not be collected and to lock the object so that it will not be moved. This could be more expensive. Also, because of the become: problems you either want a restriction so that Slang/C variables are never replaced on become: (that might be good enough). Or you want to make become replacement optional on a per/varible basis. .... Why should keeping an object from being collected be expensive at all? ----- Original Message ----- From: "Tim Rowledge" <tim(a)sumeru.stanford.edu> To: <jscholar(a)access4less.net>; <squeak-dev(a)lists.squeakfoundation.org> Sent: Wed Dec 1 21:56:55 CET 2004 Subject: Re: Adding loop primitives/optimizations (was Making Set/Dictionaryetc. loops more robust) > >> > In message <034b01c4d7e1$e00d7bd0$3fe22641 at antssoftware.com> > "Joshua Scholar" <jscholar at access4less.net> wrote: > >> Your example would NOT see the new elements because >> SequenceableCollection>>do: is implemented as: >> >> do: aBlock >> "Refer to the comment in Collection|do:." >> 1 to: self size do: >> [:index | aBlock value: (self at: index)] >> >> See, end of the array was computed before the loop started. >> >> If you shortened the array, you would have an error pop up. > Ah, run the code and see what fun it causes. I guarantee you'll see new > elements, though they may not be ones you expect. Welcome to... The > Become Zone! That's silly. If you lengthen the array, it will have already have calculate the end point of the iteration before the first block invocation and will stop at the precalculated point. End of question. >> >> "become:" affecting an active iteration is wrong. Iterations can only be >> clean if they're over a snapshot not over a live collection anyway. Ok, we >> can't afford pure cleanness but there's no point in pushing the language >> toward an idiom that can't even be defined without contradictions. > I'm not championing anything here except realism about how much mess > one can trivially (and usually unexpectedly) get into when trying to > think of optimisations like this. As you say, to be 'safe' one has to > somehow lock the collection but I'm not convinced there is actually a > real way to do that. And the performance hit could be appalling. > > >> >> What if "become:" changes the type of array to a different type? >> >> You could argue that an array of a different size IS a different type. It >> is in many languages. >> >> No, THERE IS NOTHING WRONG locking down the array and iterating over it. >> If the code calls "become:" then continuting the iteration over the old >> array is no worse than trying to continue a loop over the new (I would say >> "wrong") object. > Err, using become: makes the new array into the original one - that's > the whole point of become:, after all. The whole idea of calling become: on an object with active methods is nutty. anObject is an isntance of class Foo and is running a method doSomething: onABlock, and that block makes anObject become: an instance of class Bar, then when it gets back to doSomething, suddenly it's in method of Foo with "self" refering to an instance of Bar. That's an illegal state of mind if I've ever heard of one. If you call become: on an object with a running method, you're lucky if you don't get a crash. Frankly I can imagine an argument that "self" shouldn't be replaceable - and that become should cause an error if there's an active "self" refering to the original. If you CAN replace self on a running method and get a sane result, THAT'S a f***ing miracle. >> >> In fact, finishing the iteration with the object you started with _is_ >> _cleaner_. >> >> If you don't agree with me on that, then maybe you'll decide that _it_ >> _doesn't_ matter_ _because_ _code_ _shouldn't_ _call_ _become_ _inside_ _of_ >> _and_ _iterator_ _on_ _that_ _object_. > Well of course I agree with that - but you cannot enforce it in any way > that I can think of that would be practical. You cannot restrict the > effects of code called during the iteration, nor code running in other > threads that might run during the iteration. I'm not still not seeing a problem with making a primitive iterator as long as we can guarantee that the source isn't garbage collected while the iterator is running. By the way I'm VERY used to multiprocessor multithreaded code. In my last job I spent a lot of time working out nonblocking algorithms for multiprocessor code. Joshua Scholar

7 15

Re: [UPDATES] 3.8 gamma and 1 update
by Hannes Hirzel 03 Dec '04

03 Dec '04

Yoshiki, Thank you for your long an detailed answer. Yoshiki Ohshima wrote: > Hannes, > >>>A code snippet like >> >>s _ FileDirectory default readOnlyFileNamed: 'utf8test.txt'. >>s converter: UTF8TextConverter new. >>s contents. >> >>doesn't seem to work. > > > Can you send me the utf8test.txt file? > Here is the complete test case. Writing the test file is fine. Reading it back gives a different MultiString. "================================================" " A: Writing an UFT8 file " " The following code works fine on 3.8g-6485 " "================================================" (FileDirectory default directoryExists: 'utf8-test') ifFalse: [FileDirectory default createDirectory: 'utf8-test'.]. myTestString := 'abc ', 945 asCharacter asString, "Greek alpha" 946 asCharacter asString, "Greek beta" 947 asCharacter asString. "Greek gamma". myTestString inspect. fileName := 'utf8-test',(FileDirectory pathNameDelimiter) asString, 'test1.txt'. file := FileStream fileNamed: fileName. file reset. file converter: UTF8TextConverter new. file nextPutAll: myTestString. file close. "====================================================================" " B: Reading back the test string does not give the correct result " "====================================================================" fileName := 'utf8-test',(FileDirectory pathNameDelimiter) asString, 'test1.txt'. s _ FileDirectory default readOnlyFileNamed: fileName. s converter: UTF8TextConverter new. myTestStringReadBack _ s contents. myTestStringReadBack inspect. myTestStringReadBack = myTestString "evaluates to false" "but should give true" "This is independent of any font question." > >>It is difficult to check as well as the default >>font does not show simple Unicode chars like Greek letters. > > > I thought having font only doesn't make too much sense, but I might > be wrong. For Greek and IPA just having the font as is (no diacritics and further rendering processing) would be useful already in quite some cases. > >>MultistringCharacters show up with their internal encoding as value (like >>1069548123). > > > I'm not sure what are MultistringCharacters, but if it means that > you inspect a MultiString and select one of slots, showing the value > is the expected behavior. Strings do that. > Sorry, I meant the Characters in a MultiString (which are actually SmallIntegers ). > >>The whole thing doesn't look like it is gamma... .... > At least, the Japanese stuff works if you load one "japanese package > (sar)". A little support code for other languages should make it > work for the language. That is a huge achievement in fact. It means that the latin1 oriented and the Japanese using Squeakers can now share a common code base. And I agree that this _is_ a milestone which deserves it's own version number. > Also, the Latin-1 part works ok. It doesn't make too much sense to > revert the change. That's fine. I didn't think reverting actually. Contrariwise: I just was thinking of adding further fixes so that some straightforward non-latin1 strings work. You added the symbol font with the fix 6477 which made that Squeak doesn't crash anymore when evaluating snippet (A). So this allows to write UFT8 strings in the example (A) above now. But of course in I would like to read them back as well ;-) I understand that you use a more elaborate encoding (a tag for the encoding plus the code). It seams that each character (besides ASCII) might have its own encoding. Perhaps there is an error in my understanding when writing code snippet (B). > >>Is the 3.8 image intended to be useful as is (and if so how) or is the >>idea that people should just switch to 3.9 anyhow? I understand that it is working for Japanese (non-UTF8 encoding) and this is enough of justification for having a 3.8 release given the fact that the other latin-1 things still work (which in fact meant quite som fixes for many people). > It is somewhat useful pretty as it is for certain languages. > > You have to be aware that "supporting Unicode" is very different > concept from "supporting language X". I am ware of this. However what I just would like to see is having the first 2000 Unicode characters (or even just the IPA and the Greek characters - I have the fonts from an earlier m17n package but cannot load them) in a default font (even if it is just one point size) with no additional rendering at all. This would be useful for my work. > Supporting a language doesn't > come for free. In any system, not only in the m17n Squeak, this is > the case and many people are spending time to build the upper layer on > the top of the foundation. Where is the current platform of exchange for these activities? In any case - even if I have to wait some more time still - thank you for your great contribution and patience. Regards Hannes

1 0

Re: Adding loop primitives/optimizations (was Making Set/Dictionaryetc. loops more robust)
by Richard A. O'Keefe 03 Dec '04

03 Dec '04

"Joshua Scholar" <jscholar(a)access4less.net> wrote: I was looking from this example from the Squeak Swiki |blocks| blocks := (1 to: 10) collect: [:each | [each]]. blocks first value. "you would expect this to be 1, but it is 10". They were claiming that with closures the value would be 1 not 10. For it to be 1, the environment for each loop would have to be distinct from the environment from the previous iteration, just as I said. There are *two* blocks in that loop. blocks := (1 to: 10) collect: [:each | [each]]. 1111111112222221 Let me define some ad hoc terminology. I can't remember the Smalltalk official vocabulary, and I'm not going to try. Block an object representing a [....] syntactic unit. Block instance a dynamically created object representing a block in a particular context. Block activation a dynamically created object containing the state of an invocation of a block instance. Now let's look at blocks := (1 to: 10) collect: [:each | [each]]. block.1 and block.2 are created by the compiler and stored in the method's literal pool. At run time, if closures were implemented properly, interval.instance := a new Interval instance from 1 to 10 block.1.instance := a new instance of block.1 in the context of its invoking method inside Interval>>collect: r := a new Array of size 10 for i from 1 to 10 do block.1.activation := a new invocation of block.1.instance with i as a parameter control passes to block.1.activation block.2.instance := a new instance of block.2 in the context of block.1.activation return block.2.instance from block.1.activation control returns from block.1.activation, which is now dead r[i] := block.2.instance end for The block closure stuff will in no way reduce the number of block instances or block activations created. You get a block activation for every #value... message sent to any block instance. What proper block closures will change is the way non-locals are handled. The current effect is |blocks each*| blocks := (1 to: 10) collect: [:t* | each* := t*. [each*]]. blocks first value. What they do in Scheme I'm not sure, but I have read papers (yes plural) on plenty of Scheme compilers, and most Scheme compilers analyse the code to see if they need a new environment (is any variable captured etc) and they don't bother to created a full environment unless it's needed. And I've written a Scheme compiler (NOT a good one, not at all). So whose is bigger, eh? The Scheme system I use on a day-to-day basis is an interpreter, for what it's worth. The point is that Scheme loops are defined in terms of recursive procedure calls. Their official semantics involves creating as many closures (= block instances) and activation records (= block activations) as Smalltalk loops, if not more. Yes, a Scheme compiler may take shortcuts where it provably doesn't matter. And so may a Smalltalk compiler. Both languages allow closures (= block instances) to be passed as arguments and stored in mutable objects, making the general iterator case difficult or impossible to optimise. In this repsect named-LET and DO are really Scheme's equivalent of #while{False,True}[:] rather than the equivalent of #do:. Let's take iteration over non-empty binary trees as an example. Object subclass: #BinaryTree BinaryTree subclass: #BinaryLeaf instanceVariableNames: 'datum' do: aBlock aBlock value: datum BinaryTree subclass: #BinaryNode instanceVariableNames: 'left right' do: aBlock left do: aBlock. right do: aBlock. ... aBinaryTree do: [:each | each congrobulate]. (define-structure binary-tree-leaf datum) (define-structure binary-tree-node left right) (define (for-each-leaf F Tree) (cond ((binary-tree-leaf? Tree) (F (binary-tree-leaf-datum Tree))) ((binary-tree-node? Tree) (for-each-leaf F (binary-tree-node-left Tree)) (for-each-leaf F (binary-tree-node-right Tree))) (else (error "Not a binary tree")))) ... (for-each-leaf (lambda (Each) (congrobulate Each)) A-Binary_Tree) How many (block instances | closures) are made in (Smalltalk | Scheme)? ONE. How many activations of that (block instance|closure)? ONE PER LEAF, irrespective of language. Is a Scheme compiler at all likely to be able to optimise those activations away? NO.

1 0

Two-handed ”fluency”
by DClarke＠fadal.com 03 Dec '04

03 Dec '04

# Darius 『両手インターフェイスと”fluency” ... don’t forget us left handeds. If you favor one side of the keyboard, we left handeds may have the mouse on the wrong side. Need 3 hands. http://www.blender3d.com emphasized two-handed for 3D content creation for artists for years. We could learn from them. Jef Raskin describes the cognitive advantage of two-hands in his book ”The Humane Interface”. Do you agree with Jef? Cheers』 # Darius 『Does Squeak need multi-select for copy, paste, morph creation?』 Cheers, Darius *********************************************************************************** This transmission contains information which may be legally privileged, proprietary in nature, or otherwise protected by law from disclosure, and is intended only for the use of the addressee(s) named above. If you are not the addressee, or the person responsible for delivering this to the addressee(s), you are hereby notified that reading, copying, or distributing this transmission is prohibited. If you have received this transmission in error, please telephone us immediately at 818-407-1400 and mail the transmission back to us at the above address. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ***********************************************************************************

1 0

Morphic Heirarchy.
by Ryan Zerby 02 Dec '04

02 Dec '04

Is there someway that I can set the origin of a morphs local coordinate system, so that all of it's submorphs use the local coordinate system, rather than the global system? Currently, I pass an offset down the tree every time I run 'step.' Changing the local coordinate system seems more object oriented to me (rather than having to know about the actual location of my parent, I should be able to just move relative to the parent). Thanks.

2 1

SqueakSource: Restarted, but with Problems
by Marcus Denker 02 Dec '04

02 Dec '04

Hi, Adrian just restarted SqueakSouce. It was in a very bad shape. The univeristy computer admins did some maintanance on the weekend, and it seems Squeak didn't got correctly shut down/restartet. So: We lost all Meta-data that was changed since 28. Nov 22:27. Thas means: All commit-information about new versions, changes to users, new users, new projects. But: The uploaded .mcz files are written to disc directly, so we have not lost any .mcz file, we can recover them if needed. So please check if all latests updates are there and add them from your local cache of needed. if somebody does not have a copy of the mcz, sent me a mail and I will sent you the flle for upload into SqueakSource. Sorry for that... Marcus

4 4

Re: Squeak-dev Digest, Vol 24, Issue 7
by Robert Pratte 02 Dec '04

02 Dec '04

> Message: 11 > Date: Thu, 02 Dec 2004 04:56:31 -0800 > From: Blake <blake(a)kingdomrpg.com> > Subject: Re: Perhaps naive question about the colon. > To: "The general-purpose Squeak developers list" > <squeak-dev(a)lists.squeakfoundation.org> > Message-ID: <opsidswhd1zb486t@wynorski> > Content-Type: text/plain; format=flowed; delsp=yes; > charset=iso-8859-15 > > On Thu, 2 Dec 2004 12:47:18 -0000, Frank Shearar > <Frank.Shearar(a)rnid.org.uk> wrote: > >>> Caveman find: flint gather: twigs light:fire. >> >> This actually sends the message #find:gather:light. If you mean to >> send >> #find: then #gather: then #light: you need disambiguate using >> brackets: > > Doh! Right. See, you can tell I haven't used them much lately. I'm the > same way with C. I'll start out writing > > C = C + 1; > D = C + 1; > > then: > > C++; > D = C; > > then > > D = C++; //or is it D = ++C; ? > Actually, the two are not the same. In the first example, you aren't setting D to C as you do in the latter, you are instead using the value of C. In a simple integer evaluation, it doesn't (always) make a difference, but when applying the concept to more complicated structures/objects/etc., it can be a problem. (BTW, the ++ operator changes the value of C, not just what it would be currently evaluated at. That is D = C++; versus D = C + 1; causes C to have a different value whereas that of D is the same). Anyway, one thing that I find really interesting about this conversation is that it illustrates the confusion that can arise over syntactical conventions and how this confusion can lead to errors, etc. I think that this is particularly important given the history of smalltalk and its aversion to such complexity. In other words, while implementation can devolve into splitting hairs, smalltalk is supposed to be (somewhat) intuitive and straightforward to grasp (note that this does not mean "simple" in terms of capability). The initial question is important because one method seems intuitive to (at least one) programmer, but the result may be unexpected. Therefore, why is this method intuitive and how do we prevent the language from following grammatical trends that would obscure the "best" way of writing something? > I always fall back on plain code but get more comfortable with the > idioms > for better (Smalltalk) or worse (C)<s>. And when one is changing code, the result may be unexpected. Again, there is a certain danger in this process. A bit of a ramble - sorry Robert Pratte

2 1

← Newer
1
...
42
43
44
45
46
47
48
49
50
Older →

Jump to page: