Add delay command #179

zats · 2016-12-11T16:45:39Z

This adds a delayed execution of commands for lldb

Reasoning

Often when debugging involved user interaction or interactive transitions in simulator, it takes some time to setup the interaction I need. Once setup, it is not unheard of that I can't switch away from simulator: if gesture-driven animation is in flight, switching away from simulator might interrupt it.

Usage

This is why I found it useful to do following:

$ zzz 3 "process interrupt" (== $ zzz 3)
$ zzz 3 pcomponents
etc…

This restarts execution, gives me 3 seconds to setup my interaction, and executes specified command afterwards.

My python is quite rusty, any feedback is highly appreciated!

zats · 2016-12-11T17:23:53Z

Oh and if there is a built-in way of doing this, let me know 😆

kastiglione · 2016-12-13T01:18:18Z

Looks legit, amazing name too. I want to give Chisel some aliasing features, in which case this could be aliased to delay as well. I have just a couple comments.

kastiglione · 2016-12-13T01:08:45Z

commands/FBDelay.py

+    return 'Executes specified lldb command after delay.'
+
+  def options(self):
+    return []


I think this can be left out.

kastiglione · 2016-12-13T01:11:15Z

commands/FBDelay.py

+
+  def run(self, arguments, options):
+    lldb.debugger.SetAsync(True)
+    lldb.debugger.HandleCommand('continue')


There is a Continue() function that can be called directly, but given the way Chisel is currently architected, doing it this way is cleaner. Wanna change this to 'process continue' to match the 'process interrupt' used below?

kastiglione · 2016-12-13T01:12:28Z

commands/FBDelay.py

+    ]
+
+  def run(self, arguments, options):
+    lldb.debugger.SetAsync(True)


Should this code save the current value of async and set it back after?

seems like I didn't understand the meaning of SetAsync().
From documentation I thought that it detaches execution of the following command (continue in this case) allowing function to be evaluated even after we continue the execution.
Did I misunderstand it? Or maybe I'm just missing the point of your comment

I think that's right, but I didn't think its affect was for only one command, I'm thinking it stays in async mode until something calls SetAsync(False). If that is the case this command should change it back to the original value after it's done.

I actually don't see it being used like that in other cases we either enable reset async conditionally or don't do it at all in FBFindCommands.py

I don't mind resetting if you are certain we should do it.
Sadly, no documentation, and I don't feel like lldb spelunking right now 😳

I spelunked last night, and the main thing is that the async setting decides whether Resume() or ResumeSynchronous() is called. I didn't write any code though which would really answer the question. I don't know if those other cases really confirm it either way.

Since it must work as is, we can leave this for another day 👍

kastiglione · 2016-12-13T01:20:33Z

Ideally it wouldn't be necessary to put the command in quotes, but that can be a fix for another day.

kastiglione · 2016-12-13T01:21:38Z

commands/FBDelay.py

+
+  def runDelayed(self, command):
+    lldb.debugger.HandleCommand('process interrupt')
+    lldb.debugger.HandleCommand(command)


Does lldb silently accept an empty command? I ask because the description says zzz 3 "process interrupt" is equivalent to just zzz 3, so I'm presuming this means lldb doesn't error on empty commands.

I actually set a default value on the command option, it probably got lost because I didn't break it at certain line length (is there a style guide you'd like to follow here?)
The default parameter is , default='process interrupt'
Should I add a check for an empty command and replace it with default value?

😎 I did overlook the default.

Given the declared default, don't feel strongly either way about handling an empty command.

kastiglione · 2016-12-13T01:25:18Z

An interesting addition to this command some day is give it a "breakpoint equivalent" (function, line number, etc) and then the given command is run either when the breakpoint is hit, or when the delay/timeout happens.

zats

Re name: I actually looked for aliasing support; and yes, zzz might be a bit cryptic. I don't mind renaming it into delay for clarity.
Re adding breakpoint functionality: I'm not sure I understood the use case?

zats · 2016-12-13T04:12:25Z

commands/FBDelay.py

+
+  def runDelayed(self, command):
+    lldb.debugger.HandleCommand('process interrupt')
+    lldb.debugger.HandleCommand(command)


I actually set a default value on the command option, it probably got lost because I didn't break it at certain line length (is there a style guide you'd like to follow here?)
The default parameter is , default='process interrupt'
Should I add a check for an empty command and replace it with default value?

zats · 2016-12-13T04:18:11Z

commands/FBDelay.py

+    ]
+
+  def run(self, arguments, options):
+    lldb.debugger.SetAsync(True)


seems like I didn't understand the meaning of SetAsync().
From documentation I thought that it detaches execution of the following command (continue in this case) allowing function to be evaluated even after we continue the execution.
Did I misunderstand it? Or maybe I'm just missing the point of your comment

kastiglione · 2016-12-13T15:19:28Z

Re the breakpoint idea, let me illustrate

delay "-[Foo didDoThing]" 3 pcomponents

Basically it's like a expiring breakpoint. Within the next three seconds, if the method is called, run pcomponents, otherwise call pcomponents when time runs out.

I guess the above is just three commands:

tbreak -[Foo didDoThing]
zzz 3 "break dis <bp>"
zzz 3 pcomponents

Which raises a question, can two or more zzz commands be run like that?

zats · 2016-12-14T03:40:43Z

Hmm that's an interesting idea, but I'd probably extract it into a separate command or as an option to the existing one. Regardless seems like a material for another pull request. I'll make sure to fix other comments in the meantime

kastiglione · 2016-12-16T05:23:03Z

Looks ready, you don't have any changes planned right?

zats · 2016-12-16T17:15:30Z

Oh sorry, lost track of this PR. I didn't plan anything unless I forgot to address any of your comments?

kastiglione · 2016-12-17T07:10:51Z

Thanks!

facebook-github-bot added the CLA Signed label Dec 11, 2016

zats force-pushed the delay branch from 464ec36 to b896c6d Compare December 11, 2016 17:14

kastiglione suggested changes Dec 13, 2016

View reviewed changes

kastiglione reviewed Dec 13, 2016

View reviewed changes

zats commented Dec 13, 2016

View reviewed changes

Add delay command

c4a9b05

zats force-pushed the delay branch from b896c6d to c4a9b05 Compare December 14, 2016 04:20

kastiglione approved these changes Dec 17, 2016

View reviewed changes

kastiglione merged commit f0a8402 into facebook:master Dec 17, 2016

zats deleted the delay branch December 17, 2016 15:24

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add delay command #179

Add delay command #179

zats commented Dec 11, 2016 •

edited

Loading

zats commented Dec 11, 2016

kastiglione commented Dec 13, 2016

kastiglione Dec 13, 2016

kastiglione Dec 13, 2016

kastiglione Dec 13, 2016

zats Dec 13, 2016

kastiglione Dec 13, 2016

zats Dec 14, 2016

kastiglione Dec 14, 2016

kastiglione commented Dec 13, 2016

kastiglione Dec 13, 2016

zats Dec 13, 2016

kastiglione Dec 13, 2016

kastiglione commented Dec 13, 2016

zats left a comment

zats Dec 13, 2016

zats Dec 13, 2016

kastiglione commented Dec 13, 2016 •

edited

Loading

zats commented Dec 14, 2016

kastiglione commented Dec 16, 2016

zats commented Dec 16, 2016

kastiglione commented Dec 17, 2016

Add delay command #179

Add delay command #179

Conversation

zats commented Dec 11, 2016 • edited Loading

Reasoning

Usage

zats commented Dec 11, 2016

kastiglione commented Dec 13, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kastiglione commented Dec 13, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kastiglione commented Dec 13, 2016

zats left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kastiglione commented Dec 13, 2016 • edited Loading

zats commented Dec 14, 2016

kastiglione commented Dec 16, 2016

zats commented Dec 16, 2016

kastiglione commented Dec 17, 2016

zats commented Dec 11, 2016 •

edited

Loading

kastiglione commented Dec 13, 2016 •

edited

Loading