On Mon, Aug 19, 2013 at 08:02:02AM -0400, Bob Arning wrote:
> This is just waaay too much.
> 

+1

> - 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 at 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

Class MorphicAlarm does not even *have* a comment. MorphicAlarmQueue
has a comment, but the comment only describes its internal implementation,
nothing about why it exists or what it is supposed to do. If Morphic
alarms are a good thing, then perhaps someone could (please?) take the
time to provide some class comments with a clear explanation of what
they are and how they are supposed to work.

Dave

> 
> 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.
> >
> >
> 

>