Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Post-run commands #62

Open
hoang-tran opened this issue Jul 13, 2016 · 8 comments
Open

Post-run commands #62

hoang-tran opened this issue Jul 13, 2016 · 8 comments

Comments

@hoang-tran
Copy link

I know this plugin does a great job as a wrapper over xcodebuild. But do we have any approach on peaking at the runtime log while the app is running in the simulator?

@keith
Copy link
Contributor

keith commented Jul 13, 2016

I've been thinking about this lately as well. Based on this answer (which seems to be accurate), the logs are currently in ~/Library/Logs/CoreSimulator/<simulator-hash>/system.log

Based on the run script we already have the UDID for the simulator. So we could probably do something smart, especially with tmux, to spawn a new pane/window running a tail -f to this log.

@hoang-tran
Copy link
Author

Maybe the Xrun command should also print out the path to ~/Library/Logs/CoreSimulator/<simulator-hash>/system.log so we can tail it into any terminal pane of our choice

@gfontenot
Copy link
Owner

gfontenot commented Jul 13, 2016

@keith and I have been talking about using hooks for things like this and possibly LLDB access. I wonder if something like this would work:

let g:xcode_post_run_command = "tail ~/Library/Logs/CoreSimulator/{sim-hash}/system.log"

That could be the default, but you could override it with whatever you want. We'd then just send that command to the already-defined runner command.

For now we could simply pass the sim hash, but it's possible that we could get more intricate with multiple tokens ({pid}, {sim-hash}, {bundle-id}, ???). This would also mean moving the run commands to be internal instead of being sent to the runner command (because otherwise we'd have no way to know when the run command completed successfully). I'm OK with that.

@keith
Copy link
Contributor

keith commented Jul 13, 2016

I think if we were to do something like this we'd actually need to make it an array of commands, or an array of functions. Because now we have at least 2 use cases for this that you would ideally use simultaneously

@gfontenot
Copy link
Owner

seems reasonable

@gfontenot gfontenot changed the title Runtime log for debugging purpose? Post-run commands Jul 15, 2016
@gfontenot
Copy link
Owner

Updating the name to track what we actually want out of this.

I'm a little worried that #69 actually complicates this a bit. Since we're now building & running, it's going to be hard to know when the run command has completed, and so it'll be hard to get the pid/simulator uuid/etc.

@gfontenot
Copy link
Owner

I'd like to try expanding on this as outlined in here, but for now, I've opened a PR (#76) to tail the logs by default after running.

@keith
Copy link
Contributor

keith commented Oct 11, 2016

So now with os log you can use a command with simctl in order to get live logs from the simulator. I think this is something we should just advice people to do in a separate pane, as it can be left open between runs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants