Squeak-dev December 2009

squeak-dev@lists.squeakfoundation.org

97 participants
553 discussions

Start a nNew thread

source.squeak.org - 502 bad gateway
by Michael Haupt 30 Jan '10

30 Jan '10

Hi, is this only me, or does the server have a problem? Best, Michael

9 16

generalizedYellowButtonMenu
by Elöd Kironský 14 Jan '10

14 Jan '10

Hi! Can someone please explain what is the preference "generalizedYellowButtonMenu" for? It is by default enabled in Squeak and it breaks the yellowButtonPressed event in mouseDown: methods. I've tried to Google it, but the only thing I found, that it makes problems in other packages too. Am I missing something? This was introduced somewhere in 3.9 I think, but I'm not sure where and why. Does someone know? Thanks in advance, Elod

4 8

Inbox: #future keyword for asynchronous message invocation
by Josh Gargus 06 Jan '10

06 Jan '10

I just uploaded 4 packages to the inbox: - Compiler-FUTURESjcg.106 - Kernel-FUTURESjcg.330 - Network-FUTURESjcg.44 - System-FUTURESjcg.198 It seems to be OK to load in that order for testing, but if we decide to include this in the trunk, I'll devise a bullet-proof load order (not to mention writing some unit tests). But hey, at least there are good class comments! What is this about? It's about convenient syntax for sending and obtaining results from asynchronous messages. The initial use-case in the trunk image is to have shorter code where we currently use #addDeferredUIMessage:; you can see a few such transformations in the Network and System packages. It probably doesn't pay it's way with this use-case alone, but the exciting future use-cases are to support more advanced concurrency constructs. This code originated in Croquet as a convenient syntax for sending messages to replicated objects over the internet. We continue to use (an evolved version of) it at Qwaq/Teleplace, and have also layered other concurrency constructs on top of it. Many more uses are possible. For example, it would be very useful in a Hydra system to send messages to objects residing in other object-memories. How does it work? This is an extension to the Compiler, plus a small amount of support code in Object and Project. Eliot left hooks for FutureNode in Compiler, so all we need to do is add FutureNode to the system (good, because I'm no compiler expert!). How do you use it? It's getting late, so I'll just paste the class comment from FutureNode. <class comment> Compile-time transformation of #future and #future: messages. Use is best described through examples: receiver future doSomething: arg1 withArgs: arg2. (receiver future: 2000) doSomethingElse The first means to immediately schedule #doSomething:withArgs: for asyncronous evaluation. The second means to wait 2000 milliseconds before scheduling #doSomethingElse for asynchronous evaluation. These are transformed into either #futureDo:at:args: or #futureSend:at:args:, depending on whether the result is used. Let's look at a few examples. [receiver future foo. 2+2] value. true ifTrue: [^receiver future foo]. arraySize := receiver future getArray wait size. In the first case, the result is never used, so the message #futureDo:at:args: is generated. In the second case, the result is answered from the current method. Since we don't do any cross-method analysis, we have to assume that the result is needed for a later computation. The result is provided in the form of a Promise, which will resolve to a value when the asynchronous evaluation has completed. Creating and resolving this Promise is the responsibility of #futureSend:at:args:, which is generated instead of #futureDo:at:args: when code-analysis indicates that the result of the message might be used. The third example is another one where #futureSend:at:args: is generated. See the default implementations of #futureDo:at:args: and #futureSend:at:args: in Object. Subclasses are free to override the default implementations to achieve specific effects. For example, this functionality originated in the Croquet class TFarRef. If you have a TFarRef to a replicated object, then sending 'aTFarRef future foo' results in a message being sent over the network to each replica of the object referenced by aTFarRef. We might also use far-refs, for example, to send a message to an object in another Hydra object-memory. </class comment> I should probably quit now, because I need my beauty-sleep. Hopefully this is enough to get a discussion going; I'll respond tomorrow. Cheers, Josh

6 25

Re: [squeak-dev] The Trunk: Collections-dtl.268.mcz
by David T. Lewis 04 Jan '10

04 Jan '10

Apologies - this was a cut and paste error on my part, and does not belong in trunk, please ignore. The Collections-ar.269 should supercede it in the update stream, so it should not cause problems. (FYI, I am trying to reconstruct some of historical SystemTracer implementations in order to put them into Monticello on SqueakSource, with the latest versions being able to trace current images to 64 bit format thanks to recent work by John McIntosh.) Dave On Thu, Dec 31, 2009 at 11:01:21PM +0000, commits(a)source.squeak.org wrote: > David T. Lewis uploaded a new version of Collections to project The Trunk: > http://source.squeak.org/trunk/Collections-dtl.268.mcz > > ==================== Summary ==================== > > Name: Collections-dtl.268 > Author: dtl > Time: 31 December 2009, 5:57:13 am > UUID: 70cf7086-91e9-4d1f-a078-eaf82e6208fb > Ancestors: Collections-ul.267 > > Add remaining portions of NewSystemTracer-ajh, with classes and methods recategoried to SystemTracing. > > > =============== Diff against Collections-ul.267 =============== > > Item was changed: > Stream subclass: #PositionableStream > instanceVariableNames: 'collection position readLimit' > + classVariableNames: 'IntBuffer' > - classVariableNames: '' > poolDictionaries: '' > category: 'Collections-Streams'! > > !PositionableStream commentStamp: '<historical>' prior: 0! > I represent an accessor for a sequence of objects (a collection) that are externally named by indices so that the point of access can be repositioned. I am abstract in that I do not implement the messages next and nextPut: which are inherited from my superclass Stream.! >

7 22

Re: [squeak-dev] The Trunk: Kernel-dtl.331.mcz
by Eliot Miranda 03 Jan '10

03 Jan '10

Hi David, Interesting! To my mind that definition is incorrect. I would expect the sender of a block to be the sender of the enclosing method, in which case the definition would arguably be BlockClosure methods for accessing sender ^self home sender A block activation's caller would be it's sender slot, so within a block you might refer to thisContext caller. But what is arguably a bug in my implementation is that within a block activation thisContext sender refers to the caller (the sender of value: to the activation's block) not to the sender of the enclosing method. I think I may have screwed up badly here and that the correct implementations should be *MethodContext methods for accessing* *caller* ^closureOrNil ifNil: [self error: 'this is a method activation and so has no caller'] ifNotNil: [sender] *sender* ^closureOrNil ifNil: [sender] ifNotNil: [closureOrNil outerContext sender] *BlockClosure methods for accessing* *sender* * ^outerContext sender* and either *BlockClosure methods for accessing* *caller* * "Since a BlockClosure is by definition not an activation it does not have a caller.* * It has a sender because it is always created within the context of a method."* ^nil or *BlockClosure methods for accessing* *caller* ^self error: 'this is an inactive block and so has no caller' I believe the pre-closure definitions are *ContextPart methods for accessing* *sender* ^sender *BlockContext methods for accessing* *caller* ^sender which to my mind is missing *BlockContext methods for accessing* *sender* ^home sender What do people think the right definitions should be? On Fri, Dec 18, 2009 at 8:36 PM, <commits(a)source.squeak.org> wrote: > David T. Lewis uploaded a new version of Kernel to project The Trunk: > http://source.squeak.org/trunk/Kernel-dtl.331.mcz > > ==================== Summary ==================== > > Name: Kernel-dtl.331 > Author: dtl > Time: 18 December 2009, 11:32:44 am > UUID: 20ffffda-86bc-47a7-8eae-cd11b55aa65e > Ancestors: Kernel-bs.330 > > Add BlockClosure>>sender required for MessageTally class>>tallySends: > > Harvested from Pharo (nice 4/14/2009 19:09). > > =============== Diff against Kernel-bs.330 =============== > > Item was added: > + ----- Method: BlockClosure>>sender (in category 'debugger access') ----- > + sender > + "Answer the context that sent the message that created the > receiver." > + > + ^outerContext sender! > > >

4 5

Mouseover on a touch screen
by Jim Rosenberg 01 Jan '10

01 Jan '10

For many years now I have created artistic content that makes intensive use of mouseovers. About a year ago I got a Nokia N810, and played a bit with Squeak on that device. I've still not recovered from the shock of realizing that on a touch screen, there is no such thing as mouseover!: you cannot get the mouse cursor to move without putting it down. What to do. I can think of two potential approaches to this problem. 1. Subclass or modify HandMorph to "do the right thing in the right circumstances". Clearly some work has to be done to clarify how this should behave. HandMorph seems quite complex -- I don't suppose someone has written a tutorial on it somewhere? 2. A new class which acts as a mouse event proxy. This could either be a "screen" -- something that would fit over an entire PasteUpMorph -- or a "sled" that would be carried around by a HandMorph. In any case, the obvious question is: how should it behave. I haven't really specified this yet, but a rough idea would be something like this: "it" absorbs mouseDown, and records what morph would receive mouseDown if it weren't there. If a mouseUp occurs that would have been given to the same morph then mouse events are replayed and sent to that morph. Otherwise, "it" has to relay mouse events to whatever underlying morph would have gotten them if it were not there. This may not be simple to achieve. Now I've only poked around a little, and it looks to me as though the code for deciding what morph should get an event is in HandMorph. So, if I'm serious about doing something, regardless of how I do this it looks like I will need to get deep into the workings of HandMorph. I've tended to want to do my custom stuff in Squeak by subclassing, and am inclined to do approach 2 above -- at this point I kind of like the idea of a "screen". Am I reinventing a wheel here? If someone knows of work I should look at, I'd appreciate any references. There's a major psychological difference between a mouseOver and a click. The click is a kind of commitment, which a mouseOver isn't. It would be a real shame to have to say that we just have to give up mouseOvers on touch screens. I'm not prepared to do that. -Thanks, Jim --- Jim Rosenberg http://www.well.com/user/jer/ Internet: jr(a)amanue.com

1 3

Trivial questions?
by Friedrich Dominicus 01 Jan '10

01 Jan '10

Dear Smalltalker, I'm trying to get into Smalltalk a bit more seriously. I'm especially currently trying to get into Seaside programmming and the persistence of Objects. I found GLASS, which seems to be remarkabel in that aspect. Now I wonder 1) How does one do versioning in Smalltalk. AFAIU it seems, one files out ChangeSets which then can be read in in another image. Am I wrong about that? 2) How does one Data Migration in Smalltalk? I just know it from Rails, where one has migrations, but how's that done in the Persistence layers of some Smalltalk. E.g what happens if I add or remove instance variables? There are somewhat related question but more about GLASS. I read teh gemstone soup up and down, and was able to install the Web Edition on my System also. It was a few days work but I learned a lot. However I found just a few videos about Gemstone, but not more "serious" use (with more database related stuff, scheme changes etc) Would you mind to share your experiences? Regards Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus

6 9

Daily Commit Log
by commits＠source.squeak.org 01 Jan '10

01 Jan '10

Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours: http://lists.squeakfoundation.org/pipermail/packages/2009-December/002231.h… Name: Traits-ar.253 Ancestors: Traits-ar.252 Install NanoTraits. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2009-December/002232.h… Name: Traits-ar.254 Ancestors: Traits-ar.253 Shipping NanoTraits part 2: Commit package back after NanoTraits install. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2009-December/002233.h… Name: Kernel-ar.350 Ancestors: Kernel-ar.349 Shipping NanoTraits part 2: Commit Kernel package back after NanoTraits install. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2009-December/002234.h… Name: Kernel-ar.351 Ancestors: Kernel-ar.350 Shipping NanoTraits part 3: A hand ful of small changes that pave the way for the (major) follow-on cleanup. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2009-December/002235.h… Name: Traits-ar.255 Ancestors: Traits-ar.254 Shipping NanoTraits part 3: A hand ful of small changes that pave the way for the (major) follow-on cleanup. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2009-December/002236.h… Name: Kernel-ar.352 Ancestors: Kernel-ar.351 Shipping NanoTraits part 4: Here comes the big clean up. Let's see if it's loadable :-) ============================================= http://lists.squeakfoundation.org/pipermail/packages/2009-December/002237.h… Name: Traits-ar.256 Ancestors: Traits-ar.255 Shipping NanoTraits part 4: Here comes the big clean up. Let's see if it's loadable :-) ============================================= http://lists.squeakfoundation.org/pipermail/packages/2009-December/002238.h… Name: Traits-ar.261 Ancestors: Traits-ar.259 Revert the use of ClassTrait being the class of Trait. It causes problems when modifying class Trait itself since the subclass machinery isn't present and ClassBuilder is not ready for supporting alternative metaclasses in this form. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2009-December/002239.h… Name: Traits-ar.263 Ancestors: Traits-ar.262 Prepare to push traitComposition into TraitOrganizer so that we don't need to duplicate it in three places (Class, Metaclass, TraitDescription). ============================================= http://lists.squeakfoundation.org/pipermail/packages/2009-December/002240.h… Name: Kernel-ar.353 Ancestors: Kernel-ar.352 Prepare to push the trait composition into TraitOrganizer to avoid duplication in three places (Class, Metaclass, TraitDescription). ============================================= http://lists.squeakfoundation.org/pipermail/packages/2009-December/002241.h… Name: Traits-ar.264 Ancestors: Traits-ar.263 Push traitsComposition into TraitOrganizer. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2009-December/002242.h… Name: Traits-ar.266 Ancestors: Traits-ar.265 Also remove Trait class>>initialize. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2009-December/002243.h… Name: Kernel-ar.356 Ancestors: Kernel-ar.355 Temporarily disable warning about class redefinition to remove unused ivars from traits. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2009-December/002244.h… Name: Kernel-ar.358 Ancestors: Kernel-ar.357 Some recategorization and removal of empty categories. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2009-December/002245.h… Name: Traits-ar.269 Ancestors: Traits-ar.268 More recategorization. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2009-December/002246.h… Name: Kernel-ar.359 Ancestors: Kernel-ar.358 Final cleanup touches: Avoid unused protocol, remove reclassification. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2009-December/002247.h… Name: Monticello-ar.348 Ancestors: Monticello-ar.347 Final trait cleanup touches: Avoid direct MC extensions of traits (rather have traits check for MC presence). This will allow unloading of traits without modifying the MC package. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2009-December/002248.h… Name: Traits-ar.270 Ancestors: Traits-ar.269 Final cleanup touches: Remove some unused or duplicate left-overs. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2009-December/002249.h… Name: ReleaseBuilder-ar.43 Ancestors: ReleaseBuilder-nice.42 Final trait cleanup touches: Avoid Undeclared references. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2009-December/002250.h… Name: ScriptLoader-ar.329 Ancestors: ScriptLoader-nice.328 Final trait cleanup touches: Avoid Undeclared references. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2009-December/002251.h… Name: Kernel-ar.360 Ancestors: Kernel-ar.359 Fix small typo in obsoletion - removeTraitUser: should be sent to the elements of the composition. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2009-December/002252.h… Name: Traits-ar.271 Ancestors: Traits-ar.270 Fix a few issues where we should operate on the elements of the trait transform instead of the transform itself. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2009-December/002253.h… Name: KernelTests-ar.127 Ancestors: KernelTests-nice.126 Correct a newly failing test which didn't account for eventual trait / classtrait instances. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2009-December/002254.h… Name: TraitsTests-ar.1 Ancestors: Put traits tests back as separate package. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2009-December/002255.h… Name: Kernel-ul.362 Ancestors: Kernel-ul.361 - speed up method trailer creation - speed up source fetching from source files ============================================= http://lists.squeakfoundation.org/pipermail/packages/2009-December/002256.h… Name: Collections-ar.268 Ancestors: Collections-ul.267 Enhancements to Collection>>do:displayingProgress:. The new version has two additional features: It allows the provision of a block argument for the label instead of a string, i.e., Smalltalk allClasses do:[:aClass| (Delay forMilliseconds: 1) wait] displayingProgress:[:aClass| 'Processing ', aClass name] The second addition is an update limit that ensures that we're not spending our time in display updates. When the update limit is zero, we will update every round through the iteration, see: (Smalltalk allClasses) do:[:aClass| (Delay forMilliseconds: 1) wait] displayingProgress:[:aClass| 'Processing ', aClass name] every: 0. whereas with non-zero argument we only do this every n msecs: (Smalltalk allClasses) do:[:aClass| (Delay forMilliseconds: 1) wait] displayingProgress:[:aClass| 'Processing ', aClass name] every: 200. The default update limit is 20ms which should be a pretty good general choice. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2009-December/002257.h… Name: Collections-ar.269 Ancestors: Collections-ar.268 Tidy up do:displayingProgress:every: a little. Make sure we update label before processing the element (may not be valid afterwards) and ensure that progress is always displayed for the first and the last element. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2009-December/002258.h… Name: Collections-dtl.268 Ancestors: Collections-ul.267 Add remaining portions of NewSystemTracer-ajh, with classes and methods recategoried to SystemTracing. =============================================

1 0

The Trunk: Collections-dtl.268.mcz
by commits＠source.squeak.org 01 Jan '10

01 Jan '10

David T. Lewis uploaded a new version of Collections to project The Trunk: http://source.squeak.org/trunk/Collections-dtl.268.mcz ==================== Summary ==================== Name: Collections-dtl.268 Author: dtl Time: 31 December 2009, 5:57:13 am UUID: 70cf7086-91e9-4d1f-a078-eaf82e6208fb Ancestors: Collections-ul.267 Add remaining portions of NewSystemTracer-ajh, with classes and methods recategoried to SystemTracing. =============== Diff against Collections-ul.267 =============== Item was changed: Stream subclass: #PositionableStream instanceVariableNames: 'collection position readLimit' + classVariableNames: 'IntBuffer' - classVariableNames: '' poolDictionaries: '' category: 'Collections-Streams'! !PositionableStream commentStamp: '<historical>' prior: 0! I represent an accessor for a sequence of objects (a collection) that are externally named by indices so that the point of access can be repositioned. I am abstract in that I do not implement the messages next and nextPut: which are inherited from my superclass Stream.!

1 0

The Trunk: Collections-ar.269.mcz
by commits＠source.squeak.org 31 Dec '09

31 Dec '09

Andreas Raab uploaded a new version of Collections to project The Trunk: http://source.squeak.org/trunk/Collections-ar.269.mcz ==================== Summary ==================== Name: Collections-ar.269 Author: ar Time: 31 December 2009, 8:35:06 am UUID: e0d39f0d-6a39-6243-a032-9d93d8364c82 Ancestors: Collections-ar.268 Tidy up do:displayingProgress:every: a little. Make sure we update label before processing the element (may not be valid afterwards) and ensure that progress is always displayed for the first and the last element. =============== Diff against Collections-ar.268 =============== Item was changed: ----- Method: Collection>>do:displayingProgress:every: (in category 'enumerating') ----- do: aBlock displayingProgress: aStringOrBlock every: msecs "Enumerate aBlock displaying progress information. If the argument is a string, use a static label for the process. If the argument is a block, evaluate it with the element to retrieve the label. The msecs argument ensures that updates happen at most every msecs. Example: Smalltalk allClasses do:[:aClass| (Delay forMilliseconds: 1) wait] displayingProgress:[:aClass| 'Processing ', aClass name] every: 0. Smalltalk allClasses do:[:aClass| (Delay forMilliseconds: 1) wait] displayingProgress:[:aClass| 'Processing ', aClass name] every: 100. " | count size labelBlock oldLabel newLabel lastUpdate | labelBlock := aStringOrBlock isString ifTrue:[[:item| aStringOrBlock]] ifFalse:[aStringOrBlock]. + oldLabel := nil. + count := lastUpdate := 0. - count := 0. size := self size. '' displayProgressAt: Sensor cursorPoint from: 0 to: size during:[:bar | self do:[:each| + "Special handling for first and last element" + (count = 0 or:[count+1 = size + or:[(Time millisecondsSince: lastUpdate) >= msecs]]) ifTrue:[ + bar value: count. + oldLabel = (newLabel := labelBlock value: each) ifFalse:[ - "Special handling for initial progress" - (count = 0 or:[count = size]) ifTrue:[ - bar value: count. - ProgressNotification signal: '' extra: (oldLabel := labelBlock value: each). - lastUpdate := Time millisecondClockValue. - ]. - aBlock value: each. - count := count + 1. - (Time millisecondsSince: lastUpdate) >= msecs ifTrue:[ - bar value: count. - oldLabel = (newLabel := labelBlock value: each) ifFalse:[ ProgressNotification signal: '' extra: (oldLabel := newLabel). ]. lastUpdate := Time millisecondClockValue. ]. + aBlock value: each. + count := count + 1. ]]!

1 0

Jump to page: