[TestEvents] Add a 'connected' state to include remote debugging.

[chaoren]

test/python_api/event/TestEvents.py

250

Update comment here?

257

Update comment here?

275

Perhaps we need another self.context.state value for this to ensure ordering (Bump everything after by 1).

278

s/pass/continue/?

288

We don't need this.

[sivachandra]

test/python_api/event/TestEvents.py

250

See my comment at 275.

257

See my comment at 275.

275

Should we be treating this as a state at all? The 'connected' event is just a notification of being connected and has nothing to do with the inferior state.

278

Re-reading, 'continue' seems correct. Let me know your opinion around other changes and will change this to continue along with them.

288

Perhaps. But whoever has put it, probably wanted to see a message when listener.WaitForEvent times out. That's my guess, which if correct should be have been under an else.

We could ofcourse remove this altogether as I think it was a debug print statement which the committer forgot to remove before committing.

[chaoren]

test/python_api/event/TestEvents.py

275

I think state describes this test (which event to expect next), and not the inferior. Regardless, It's still nice to ensure ordering.

288

Is it an error condition if all 6 attempts fail? Perhaps we should just remove this line and error out below.

292

Error here?

[sivachandra]

test/python_api/event/TestEvents.py

275

If ordering is a concern, how about this:

if match.group(1) == 'connected':
  self.assertTrue(self.context.state == 0)
  continue

If 'connected' is treated as a state, then there will be a different state machine (a different start state) for remote and non-remote platforms. It sounds unnecessarily complicated, but will do it if you really want it.

288

That makes it out of scope for this change. I am going to remove all my changes around this to avoid further mixup.

[chaoren]

test/python_api/event/TestEvents.py

275

Why not store the previous state as a string?

if match.group(1) == 'connected':
  self.assertTrue(self.context.state == None)
  self.context.state = 'connected'
  continue
elif match.group(1) == 'running':
  self.assertTrue(self.context.state == None or self.context.state == 'connected')
  self.context.state = 'running'
  continue
...

[sivachandra]

Reaching round my neck...

[chaoren]

LGTM

test/python_api/event/TestEvents.py

def do_add_listener_to_broadcaster(self):
                                  error)     # error
 
         # Create an empty event object.
         event = lldb.SBEvent()
         self.assertFalse(event, "Event should not be valid initially")
 
 
         # The finite state machine for our custom listening thread, with an
         # initail state of 0, which means a "running" event is expected.
         # It changes to 1 after "running" is received.
         # It cahnges to 2 after "stopped" is received.
         # 2 will be our final state and the test is complete.
         self.state = 0 
 
         # Create MyListeningThread to wait for state changed events.
         # By design, a "running" event is expected following by a "stopped" event.
         import threading
         class MyListeningThread(threading.Thread):
             def run(self):
                 #print "Running MyListeningThread:", self
 
                 # Regular expression pattern for the event description.
                 pattern = re.compile("data = {.*, state = (.*)}$")
 
                 # Let's only try at most 6 times to retrieve our events.
                 count = 0
                 while True:
                     if listener.WaitForEvent(5, event):
                         desc = lldbutil.get_description(event)
                         #print "Event description:", desc
                         match = pattern.search(desc)
                         if not match:
                             break;
-                        if self.context.state == 0 and match.group(1) == 'running':
+                        if match.group(1) == 'connected':
+                            # When debugging remote targets with lldb-server, we
+                            # first get the 'connected' event.
+                            pass
+                        elif self.context.state == 0 and match.group(1) == 'running':
                             self.context.state = 1
                             continue
                         elif self.context.state == 1 and match.group(1) == 'stopped':
                             # Whoopee, both events have been received!
                             self.context.state = 2
                             break
                         else:
                             break
+                    else:
                         print "Timeout: listener.WaitForEvent"
                     count = count + 1
                     if count > 6:
                         break
 
                 return
 
         # Use Python API to continue the process.  The listening thread should be
         # able to receive the state changed events.
         process.Continue()
 
         # Start the listening thread to receive the "running" followed by the