[Chandler-dev] Re: Fwd: Build failed on molokini-osx

[Robin Dunn]

I can duplicate the error on my Tiger box.  It also happens if I go back 
to the previous wx tarball, so it appears to not be related to the new 
wx.  I've tried a similar workaround as I used in the DV case, but it 
still only successfully runs that test case about 50% of the time.

Running a similar sequence by hand always succeeds, so I wonder if it 
possible to introduce a short delay at certain points in the execution 
of the recorded scripts?  If we an more fully simulate the user's 
actions I think that this can succeed as is.

Robin



D John Anderson wrote:
> Hi Robin:
> 
> I looked into the failure you note below. Here's what appears to be 
> happening:
> 
> We made a new collection
> 
> added a new item and displayed it in the all view.
> 
> changed it to later
> 
> double clicked in the title field in the summary view
> 
> typed "L" which replaced "Untitled" with "L"
> 
> next typed "a".
> 
> We should see "La", be instead we see "a". It's as if the entire field 
> was selected after the "L" was typed. There are other failures where we 
> get further before failing, e.g. typed "La", then "t" and get "t" 
> instead of "Lat" or "Lat" then "e" and get "e" instead of "Late". All 
> these failures only seem to be happening on molokini-osx.
> 
> Here's what I'd do to track down the problem: First try to see if you 
> can reproduce it locally. If not, I'd try temporarily backing out the wx 
> change to see if all the tinderboxes run green. This test 
> "TestTriageSectioningActions" was added shortly before the wx change and 
> we didn't get that much time to run it on all the different 
> configurations, so it would be useful to make sure it runs green without 
> the wx change.
> 
> I could also list the selection range along with the other information 
> printed in the error message to help narrow down the problem. 
> 
> I'm also seeing other failures on another Tiger machine: 
> p_osx in TestTriageSectioningActions:
> 
>           Traceback (most recent call last):            File "/Users/osafuser/tinderbuild/chandler/tools/cats/framework/run_recorded.py", line 96, in run_test_by_name              test_modules[name].run()            File "/Users/osafuser/tinderbuild/chandler/tools/cats/recorded_scripts/TestTriageSectioningActions.py", line 203, in run              (158, wx.MouseEvent, {´eventType´:wx.EVT_LEFT_UP, ´sentTo´:u´DashboardSummaryViewGridWindow´}, {´m_x´:19, ´m_y´:46}),            File "/Users/osafuser/tinderbuild/chandler/application/Application.py", line 1372, in RunRecordedScript              self.ProcessPlaybackEvent()            File "/Users/osafuser/tinderbuild/chandler/application/Application.py", line 1379, in ProcessPlaybackEvent              ProcessEvent (*self.events [eventsIndex])            File "/Users/osafuser/tinderbuild/chandler/parcels/osaf/framework/script_recording/script_lib.py", line 98, in ProcessEvent              id = sentToWidget.GetId()
> 
> 
> It would also be interesting to see if this goes away with the old wx. I 
> will and some more information to the error help narrow it down.
> 
> Unfortunately, all the failures besides the chronically flakey TestMulti 
> and CertStore (which we should have removed or fixed long ago) seem to 
> be happening on Tiger and that's the only OS I don't have easy access to.
> 
> John
> 
> On Dec 7, 2007, at 11:39 PM, Robin Dunn wrote:
> 
>> D John Anderson wrote:
>>> Hi Robin:
>>> It looks like the tests are still failing on Tiger -- but in 
>>> different ways. Some of them look like a selection in a TextCtrl is 
>>> getting lost or set incorrectly. Do you think wx is still responsible 
>>> for these failures?
>>
>> This one I'm not sure about.  It only happens in the debug build, 
>> which is why I didn't see it before.  It's a text ctrl in the table 
>> widget, so it won't have been affected by my earlier change.  It's in 
>> the process of typing "Later" but either the "a" or the "t" replaces 
>> what had already been typed.  On the other hand, it looks like the 
>> exact same thing was done successfully with "Done" in the previous 
>> part of the test...  I'll spend a little time on it tomorrow and see 
>> if I can figure something out.  Here's the exception from the log file 
>> in case you haven't seen it yet since you don't have Tiger:
>>
>>
>> 2007-12-07 23:28:39,808 recorded_test_framework ERROR: Test 
>> "TestTriageSectioningActi
>> ons" has failed
>> Traceback (most recent call last):
>>  File 
>> "/work/projects/osaf/chandler/tools/cats/framework/run_recorded.py", 
>> line 96,
>> in run_test_by_name
>>    test_modules[name].run()
>>  File 
>> "/work/projects/osaf/chandler/tools/cats/recorded_scripts/TestTriageSectioning
>> Actions.py", line 203, in run
>>    (158, wx.MouseEvent, {'eventType':wx.EVT_LEFT_UP, 
>> 'sentTo':u'DashboardSummaryView
>> GridWindow'}, {'m_x':19, 'm_y':46}),
>>  File "/work/projects/osaf/chandler/application/Application.py", line 
>> 1372, in RunRe
>> cordedScript
>>    self.ProcessPlaybackEvent()
>>  File "/work/projects/osaf/chandler/application/Application.py", line 
>> 1379, in Proce
>> ssPlaybackEvent
>>    ProcessEvent (*self.events [eventsIndex])
>>  File 
>> "/work/projects/osaf/chandler/parcels/osaf/framework/script_recording/script_l
>> ib.py", line 178, in ProcessEvent
>>    % (eventNumber, ProcessEvent.lastSentTo, value, lastWidgetValue)
>> AssertionError: event 72 -- widget DashboardSummaryViewAttributeEditor 
>> value, "a" doe
>> sn't match the value when the script was recorded: "La"
>>
>>
>>
>> -- 
>> Robin Dunn
>> Software Craftsman
>> http://wxPython.org  Java give you jitters?  Relax with wxPython!
>>
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "chandler-dev" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/chandler-dev
> 
> 
> ------------------------------------------------------------------------
> 
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> 
> Open Source Applications Foundation "chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chandler-dev