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 |
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..). 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 <[hidden email]> 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 > |
On 5 June 2013 17:19, Chris Muller <[hidden email]> 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 <[hidden email]> 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 >> > |
In reply to this post by Chris Muller-3
Hi all -
Are there files available that will fix the blocks in pre-Cog images to that they will run on Cog? I'm reviving some old images and it would be nice to run them on Cog. Thanks - Dan |
On 2013-06-08, at 19:45, Daniel Ingalls <[hidden email]> wrote: > Hi all - > > Are there files available that will fix the blocks in pre-Cog images to that they will run on Cog? > > I'm reviving some old images and it would be nice to run them on Cog. > > Thanks > > - Dan http://www.mirandabanda.org/files/Cog/Closures0811/Bootstrap/ - Bert - |
Quoting Bert Freudenberg <[hidden email]>:
> > On 2013-06-08, at 19:45, Daniel Ingalls <[hidden email]> wrote: > >> Hi all - >> >> Are there files available that will fix the blocks in pre-Cog >> images to that they will run on Cog? >> >> I'm reviving some old images and it would be nice to run them on Cog. >> >> Thanks >> >> - Dan > > > http://www.mirandabanda.org/files/Cog/Closures0811/Bootstrap/ > > - Bert - > > > > Hi Dan, Eliot's original bootstrap is a bit tricky to use on other images than the ones he built it for (Croquet.1.0.18, Squeak3.9-final-7067 and Qwaq), because he's tweaking the compiler while it is being used to file in the code. While trying to adapt it for Cuis I broke my image too many times to count them! I suggest using the sequence of changesets I prepared for Cuis. The idea is to prepare and test the new compiler without hooking it to the system yet, until it is good enough. Then, in one step, swap compilers, recompile everything, and only then remove the old compiler. Although I believe I'm the only other person, besides Eliot, who successfully updated a different image to use Closures, my approach should be easy to adapt to any other image. Get the Cuis update stream from https://github.com/jvuletich/Cuis/raw/master/PreviousUpdates/CuisUpdatesUpTo1511.zip . The relevant change set are 339 to 392. BTW, if possible, please keep up posted. It is always a pleasure to follow your work! Cheers, Juan Vuletich |
Free forum by Nabble | Edit this page |