On 5 June 2013 17:19, Chris Muller <asqueaker at gmail.com> wrote:
> Why was a future send introduced?  Timing issues are some of the most
> maddeningly difficult to track down, especially when one _expects_ the
> basic *list-widget* to WORK.  (Sorry, I feel my temperature going up
> even as I type that sentence..).

It's not a "timing issue" per se. Well, when you say "timing issue" I
hear "race condition". That's not what this is. This is selecting a
list item immediately, and letting the (potentially long-running)
action associated with that selection happen later. Concretely, that
lets Tim see that he's selected Morphic _now_ rather than waiting for
Monticello has to fetch the entire thing and save the world before
highlighting the item.

The problem from a testing perspective is that the list item is
_never_ immediately selected.

I suspect what we actually want is a Promise that, when fulfilled,
completes the highlighting of the item. That means that you might know
that item 5 is selected, but when you say "give me that item" you
actually get an unresolved promise. We might only want to use promises
in some tools. Asking people to swallow _always_ having to work with
promises might be a bit much.

frank

> I find it hard to believe that, with Morphic stepping and all the
> other flexible power we have, that we require this timing-issue
> compromise of using of a future send to do the progress bar...?
>
> On Wed, Jun 5, 2013 at 6:49 AM, Frank Shearar <frank.shearar at gmail.com> wrote:
>> Now that we have a #future: send in PluggableListMorph >>
>> #changeModelSelection:, we have a number of tests that fail because we
>> check the state of such a list too quickly. For instance,
>> MorphicToolBuilderTest >> #testSetListIndex says
>>
>> testSetListIndex
>>     self makeList.
>>     queries := IdentitySet new.
>>     self changeListWidget.
>>     self assert: (queries includes: #setListIndex).
>>
>> and the #assert: happens long before the future triggers.
>>
>> Now a completely stupid way of "fixing" this would be to add a Delay
>> after the call to #changeListWidget. That would also smash the test
>> run times, which are bad enough already.
>>
>> How can we write tests that run at full speed? One possible way might
>> be to use a new SUnitProject whose #future:do:at:args: and
>> #future:send:at:args: immediately trigger the #future: instead of
>> delaying. That sound like it might bring its own problems.
>>
>> Other suggestions?
>>
>> frank
>>
>