November 2008 - Pharo-dev - lists.pharo.org

[Pharo-project] Exploring an event handling implementation
by Igor Stasenko Nov. 17, 2008

Nov. 17, 2008

Hello list, it is strikes me, how complex event handling in squeak. :) I want to make it less fuzzy, but it looks like there is too much to do for achieving that. In current state, it grew out from multiple evolutionary steps - old VM has no event queue, so at language side, it has to support two ways to fetch events from VM. A key primitive which feeds an events from VM is in EventSensor>>primGetNextEvent: , which fills a provided array with 8 indices. It looks like a good point to reuse same array for fetching events, to not create new instance for each single event, right? (in EventSensor>>fetchMoreEvents) eventBuffer := Array new: 8. [self primGetNextEvent: eventBuffer. type := eventBuffer at: 1. type = EventTypeNone] whileFalse: [self processEvent: eventBuffer]. But hey.. let's look further: EventSensor>>queueEvent: evt "Queue the given event in the event queue (if any). Note that the event buffer must be copied since it will be reused later on." eventQueue ifNil:[^self]. eventQueue nextPut: evt clone. so, its avoiding creating new instance in #primGetNextEvent:, but then creating a new one later (by cloning it), e.g. instead of using single primitive which creates new instance & fill it with values, we use two primitives. Well, this strategy would be valid, if we, instead of putting raw event buffers into queue, first, decode the event and put a nice XXXXEvent instances instead. But this not happens in EventSensor, and i really disappointed and asking, why? Instead, an EventSensor puts a raw event buffers (arrays with 8 values) in queue, and then gives them away! Which means that there is not a single place in image where you should deal with cryptic values returned by VM primitive. I think, that first & most important task of event handling should be get rid of this cryptic looking array of 8 values, by deciphering them and replacing with an appropriate instances of some event, which having a good protocol & easy to manipulate/work with. Consider an easy scheme, which can deal with deciphering event buffers into a nice events: First , we can associate each kind of event with a class. There is not much of them , defined in VM /* Event types. */ #define EventTypeNone 0 #define EventTypeMouse 1 #define EventTypeKeyboard 2 #define EventTypeDragDropFiles 3 #define EventTypeMenu 4 #define EventTypeWindow 5 So, all we need to do is to have an array of eventKinds , which contains appropriate classes for each event kind. eventKinds := Array new: 5. eventKinds at: 1 put: MouseEvent. eventKinds at: 2 put: KeyboardEvent. ... then, if we want to decode an event from event buffer, we can simply do: newEvent := (eventKinds at: (eventBuffer at: 1)) decodeFrom: eventBuffer. And voila, we can play with events as we like. e.g. instead doing something cryptic like: type := eventBuffer at: 1. type == 1 ifTrue: [ ... ] we can write code in more human friendly manner: event isMouseEvent ifTrue: [. ..] As you understand, this is only a tip of the iceberg. It is really scary piece of system, each time i'm looking at it, something tells me - hey pal, leave this stuff and never look at it again :) P.S. I'm understand, that event handling code is born from multiple waves and being modified by different developers. And i'm appreciate their efforts, because despite the design it works! -- Best regards, Igor Stasenko AKA sig.

6 17

[Pharo-project] How's closure support going?
by bryce＠kampjes.demon.co.uk Nov. 17, 2008

Nov. 17, 2008

Just curious. I'm a bit busy at the moment and my Squeak time is going towards fixing one of the remaining long standing bugs in Exupery. Once it's fixed, there may be some time to look at building a VM on either Windows or Mac. Bryce

2 1

[Pharo-project] [updates] 10150-10152
by Marcus Denker Nov. 16, 2008

Nov. 16, 2008

10150 ------ -> Issue 333: A fix for animated GIF harvested from Squeak -> Mantis 0006343: Process does not need to be a special object Change proposed by martin v. Loewis: When changing Process, I was warned that it is a special object and therefore it is dangerous to change its class definition. Process currently lives at: 28 of Smalltalk specialObjectsArray. In reviewing all references to the special objects array, I could not find any reference to that slot, neither in the Squeak 3.9 image nor in the VM. 10151 ------ -> Issue 146: ClassDescription>>copyUnobstrusevely ClassDescription>>copyUnobstrusevely and friends are only invoked by kedama which should be removed -> Issue 128: M5711: TextFieldMorph changes text position when emptied -> now really do Postscript: Smalltalk recreateSpecialObjectsArray. 10152 ----- -> Issue 276: candidate for core: Process-specific variables Martin von Loewis did a nice implementation of thread-specific variables: This project provides process-specific variables (called TLS - thread- local storage) in other environments. Two kinds of variables are provided: ProcessLocalVariable (similar to TLS), and DynamicVariables (akin LISP's dynamic scope) -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

3 5

[Pharo-project] Issue 333 fix ready for harvesting
by Torsten Bergmann Nov. 16, 2008

Nov. 16, 2008

Issue ID 333 is fixed [1]. The mcz with version 68 for the Graphics package in the pharo inbox can be harvested. If you want to try yourself load the GIF [2] before and after applying the fix. Thanks to Jerome Peace [3]. Bye Torsten [1] http://code.google.com/p/pharo/issues/detail?id=333 [2] http://www.mathconsult.ch/showroom/unipoly/anim24.gif [3] http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-November/132428… -- "Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ... Jetzt GMX ProMail testen: http://www.gmx.net/de/go/promail

2 2

[Pharo-project] [ANN] new update
by StÃ©phane Ducasse Nov. 15, 2008

Nov. 15, 2008

Hi all I continued to curved out etoy. If you want to follow my progress or participate http://code.google.com/p/pharo/wiki/CurrentlyWorkingOn?ts=1226697010&update… Now I stop for tonight since I get "nausea" after reading too funny much code. Stef

3 4

[Pharo-project] String and Symbol comparison
by Lukas Renggli Nov. 15, 2008

Nov. 15, 2008

I want to open this for discussion: In all Smalltalk dialects the following expressions evaluate to false: 'abc' = #abc --> false #abc = 'abc' --> false This means a String and a Symbol is never the same thing, even if they contain the same characters. In Squeak/Pharo this is different though (at least this is symmetrical, pre 3.9 this wasn't even symmetrical): 'abc' = #abc --> true #abc = 'abc' --> true Unfortunately this difference makes writing portable code that deals with symbols and strings a huge pain. And it is hard to test, debug and find those kind of problems. I wonder if it would be possible to change that behavior in Squeak to match the other Smalltalk implementations? I guess this would break some code, but at least this problem would then be gone forever. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

4 8

[Pharo-project] OldSocket removal
by Damien Cassou Nov. 13, 2008

Nov. 13, 2008

I've started working on OldSocket removal: http://code.google.com/p/pharo/issues/detail?id=275. I need someone to review my first changes. -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

4 27

[Pharo-project] MNU addMakeSiblingHandle:
by nicolas cellier Nov. 13, 2008

Nov. 13, 2008

The halo button brings me a debugger : Message not understood addMakeSiblingHandle: If that happens to you, just doIt: Preferences resetHaloSpecifications. Nicolas

2 1

[Pharo-project] Rio renamed to File/Directory
by Keith Hodges Nov. 13, 2008

Nov. 13, 2008

lets see how it goes Keith

1 0

Nov. 12, 2008

Hi all this is a call for features. Right now senders shows me even the method that defines the method I'm looking for just because it finds the name in the methods. It would be cool if somebody would enhance the senders to returns senders and not senders and implementors mixed together. Stef

5 7