This is just waaay too much.

- It makes little sense to talk about a "public API" in Squeak. All methods are visible and executable from anywhere. To think that some subset of all methods have been vetted and will never do anything unpleasant is not supported by the facts.

- If you look at the senders of flash in the image, it pretty much all about , "I just asked a tool to do something and it could not. Oops!" No need for anything fancy here - just DTSTTCPW.

- The introduction of alarms made me nervous. I understand delays, but alarms are a gray area. How do they work? Will they do what I think they will? In this case, they do *not*. If we go back to my example:

m _ (1 to: 10) collect: [ :i | Morph new position: (i@i*75); openInWorld]

m do: [ :e | e flash]

Using the alarming version of #flash, we see the first morph flash ever so briefly. Each successive morph flashes for a longer time, until the last one stays inverted for 600 ms. Huh!

If you look at: WorldState>>triggerAlarmsBefore:, you see the claim:

"Trigger all pending alarms that are to be executed before nowTime."

when, in fact, it triggers one at most:

    triggered := OrderedCollection new.
    self lockAlarmsDuring: [:pending |
        (pending isEmpty not and: [pending first scheduledTime < nowTime])
            ifTrue: [triggered add: pending removeFirst]].
    triggered do: [:alarm | alarm value: nowTime].

makes me want to

Smalltalk destroyAllComments ;-)

Cheers,
Bob

On 8/19/13 5:56 AM, Marcel Taeumel wrote:

Hi! :)

One point against blocking the event loop: You never know who will call
#flash as it is public API. It is not guaranteed that the flashing morph is
"visible" at all and not occluded by some other morph. Then, strange short
image freezes will be noticed.

On 8/19/13 6:07 AM, Marcel Taeumel wrote:

Here a better version:

 (self valueOfProperty: #colorBeforeFlashing ifAbsent: [self color])
    in: [:c |
      self setProperty: #colorBeforeFlashing toValue: c.
      self color: ((c ifNil: [Color white]) alpha: 1) negated.
      ActiveWorld displayWorldSafely.
		
      self
        removeAlarm: #color:;
        removeAlarm: #removeProperty:.
      self
        addAlarm: #color: with: c after: 100;
        addAlarm: #removeProperty: with: #colorBeforeFlashing after: 100]. 

I am not exactly sure, why an explicit call to the render loop is needed...
But this way, it works without blocking the event loop. This "ActiveWorld
displayWorldSafely" is still annoying...

Best,
Marcel



--
View this message in context: http://forum.world.st/computers-too-fast-these-days-tp4704067p4704117.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.