<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <font face="Georgia">This is just waaay too much.<br>
      <br>
    </font>- 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.<br>
    <br>
    - 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.<br>
    <br>
    - 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:<br>
    <br>
    m _ (1 to: 10) collect: [ :i | Morph new position: (i@i*75);
    openInWorld]<br>
    <br>
    m do: [ :e | e flash]<br>
    <br>
    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! <br>
    <br>
    If you look at: WorldState&gt;&gt;triggerAlarmsBefore:, you see the
    claim:<br>
    <br>
    "Trigger all pending alarms that are to be executed before nowTime."<br>
    <br>
    when, in fact, it triggers one at most:<br>
    <br>
    &nbsp;&nbsp;&nbsp; triggered := OrderedCollection new.<br>
    &nbsp;&nbsp;&nbsp; self lockAlarmsDuring: [:pending |<br>
    &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; (pending isEmpty not and: [pending first scheduledTime &lt;
    nowTime])<br>
    &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; ifTrue: [triggered add: pending removeFirst]].<br>
    &nbsp;&nbsp;&nbsp; triggered do: [:alarm | alarm value: nowTime].<br>
    <br>
    makes me want to <br>
    <br>
    Smalltalk destroyAllComments ;-)<br>
    <br>
    Cheers,<br>
    Bob<br>
    <br>
    <div class="moz-cite-prefix">On 8/19/13 5:56 AM, Marcel Taeumel
      wrote:<br>
    </div>
    <blockquote cite="mid:1376906215671-4704116.post@n4.nabble.com"
      type="cite">
      <pre wrap="">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.
</pre>
    </blockquote>
    <div class="moz-cite-prefix">On 8/19/13 6:07 AM, Marcel Taeumel
      wrote:<br>
    </div>
    <blockquote cite="mid:1376906874146-4704117.post@n4.nabble.com"
      type="cite">
      <pre wrap="">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: <a class="moz-txt-link-freetext" href="http://forum.world.st/computers-too-fast-these-days-tp4704067p4704117.html">http://forum.world.st/computers-too-fast-these-days-tp4704067p4704117.html</a>
Sent from the Squeak - Dev mailing list archive at Nabble.com.


</pre>
    </blockquote>
    <br>
  </body>
</html>