Skip to content
This repository has been archived by the owner on Jan 17, 2019. It is now read-only.

Support target names in --only option #2

Closed
plu opened this issue Nov 29, 2016 · 2 comments
Closed

Support target names in --only option #2

plu opened this issue Nov 29, 2016 · 2 comments

Comments

@plu
Copy link
Owner

plu commented Nov 29, 2016

  • Change --only to VaradicOption
  • Support TARGET[:Class/case[,Class2/case2]]
@plu
Copy link
Owner Author

plu commented Nov 29, 2016

This will make pxctest best friends with xcknife

@plu
Copy link
Owner Author

plu commented Dec 1, 2016

Fixed via c97fd9a

@plu plu closed this as completed Dec 1, 2016
plu pushed a commit that referenced this issue Dec 1, 2016
plu pushed a commit that referenced this issue Dec 1, 2016
Summary:
As I've been working on the e2e cli test suite, I've seen that there are issues with the way that the CLI Parses compound commands, which means that the parsing can terminate early and not parse the entire string.

I think this highlights the folly in 'implicit' chaining of compound commands. For example,

```
list boot listen --http 1000 shutdown
```

Should result in the same parsed command as with dash-separated compound commands:

```
list -- boot -- listen --http 1000 -- shutdown
```

But it does not, as the dash separated style will bail out in parsing halfway through and provided a half-parsed result.

I want to correct the existing behaviour, then remove 'implicit' parsing:

1) Introduce tests (and fixes) for dash-separated compound commands
2) Make parsing of compound commands 'strict'. This means that `list -- boot ThisIsABadArgument` should fail to parse instead of just parsing `list` and then continuing. This is important as this can result in very surprising behaviour otherwise.
3) Update any documentation and dependencies to use the new dash-separation of compound commands.
4) Remove the behaviour for implicit chaining of compound commands. Iinvert the tests so that dash-separation succeeds to parse, implicit chaining fails.

This diff does #1 and #2 in unison, since only doing #1 without #2 results in a very confusing parser.

Reviewed By: asm89

Differential Revision: D3592485

fbshipit-source-id: 00d3164c921082638d65076329b117c19ee57bf8
plu pushed a commit that referenced this issue Dec 1, 2016
Summary:
There is one very subtle case that will cause the 'unclaimed' (read Xcode-launched) Application fetching will fail:
1) Boot a Simulator via conventional means like via Xcode or an alias to the `Simulator.app`
2) Boot another Simulator.app via `fbsimctl`
3) `fbsimctl shutdown` will properly kill the sim from #1 but not #2

This is because the booting of #2 overwrites the `NSUserDefaults` from #1 so the 'unclaimed' simulator container app doesn't correlate. The check for the UDID in the `NSUserDefaults` is unecessary since we can reasonably assume if there is one more Simulator app that is unclaimed this must be the sole remaining Simulator.app for the `launchd_sim`.

Reviewed By: marekcirkos

Differential Revision: D3811248

fbshipit-source-id: e9f0fb97c8370f5966f191eebbd246f61ec722b5
plu pushed a commit that referenced this issue Dec 1, 2016
Summary:
There's a class cluster and protocol for providing configurations of Scale Sizes. It's currently used in two places that I eventually plan on making orthogonal:
1) Setting the scale override when launching via the `Simulator.app`
2) Downscaling the Framebuffer before rendering.

By making this public, this minimizes the changes required for #2

Reviewed By: marekcirkos

Differential Revision: D3849170

fbshipit-source-id: 698ea5fe8d7e8b9612bafb3626e00542d558a75c
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant