- 09 Jan, 2017 1 commit
-
-
Todd Volkert authored
This ensures that accidental usages of dart:io's file API don't creep in over time.
-
- 17 Nov, 2016 1 commit
-
-
Todd Volkert authored
* Allow for application-specific log readers. When running with prebuilt application binaries, those applications aren't guaranteed to be named "Runner" (as it is when we build the app locally in Flutter tools)
-
- 14 Nov, 2016 2 commits
-
-
Dan Rubel authored
* Remove the workaround that pinned args to v0.13.6 This reverts most of the changes in commit 6331b6c8 * throw exception if exit code is not an integer * rework command infrastructure to throw ToolExit when non-zero exitCode * convert commands to return Future<Null> * cleanup remaining commands to use throwToolExit for non-zero exit code * remove isUnusual exception message * add type annotations for updated args package
-
Dan Rubel authored
* convert pubGet to throw ToolExit on non-zero exit code * convert commandValidator to throw ToolExit for non-zero exit code * convert flutter commands to throw ToolExit for non-zero exit code * use convenience method throwToolExit * only show "if this problem persists" for unusual exceptions
-
- 16 Sep, 2016 1 commit
-
-
Dan Rubel authored
* refactor _run to runCmd * replace requiresProjectRoot getter with call to commandValidator * replace requiresDevice getter with call to findTargetDevice * trace command requires a debug connection, not a device * inline androidOnly getter * rename command methods to verifyTheRunCmd and runCmd * move common verification into BuildSubCommand * rename deviceForCommand to device * rename methods to verifyThenRunCommand and runCommand
-
- 14 Jun, 2016 1 commit
-
-
Ian Hickson authored
This prevents multiple simultaneous runs of the analyzer from stomping over each other (e.g. multiple runs of 'update-packages'). Certain long-lived commands (like analyze, run, logs) are exempted once they've done enough work to be safe from most stomping action. This still doesn't make us entirely safe from craziness, e.g. if you're half way through an 'update-packages' run and you call 'git pull', who knows what state you'll end up in. But there's only so much one can do. Fixes https://github.com/flutter/flutter/issues/2762
-
- 27 Apr, 2016 1 commit
-
-
Devon Carew authored
* rework flutter run * fix npe with --debug-port * connect to obs and exit when that conneciton closes * update todos
-
- 21 Mar, 2016 1 commit
-
-
Devon Carew authored
-
- 14 Mar, 2016 2 commits
-
-
Hixie authored
-
Ian Hickson authored
-
- 11 Mar, 2016 1 commit
-
-
Devon Carew authored
-
- 09 Mar, 2016 1 commit
-
-
Devon Carew authored
-
- 08 Mar, 2016 1 commit
-
-
John McCutchan authored
-
- 24 Feb, 2016 1 commit
-
-
Devon Carew authored
-
- 21 Feb, 2016 1 commit
-
-
Devon Carew authored
-
- 17 Feb, 2016 1 commit
-
-
Devon Carew authored
-
- 15 Feb, 2016 1 commit
-
-
Devon Carew authored
-
- 10 Feb, 2016 2 commits
-
-
Devon Carew authored
-
Devon Carew authored
-
- 01 Feb, 2016 1 commit
-
-
Devon Carew authored
-
- 20 Jan, 2016 1 commit
-
-
Devon Carew authored
-
- 29 Nov, 2015 1 commit
-
-
Adam Barth authored
1) Moved basic utility code into base/ directory to make it clear which code doesn't depend on Flutter-specific knowldge. 2) Move the CommandRunner subclasses into a runner/ directory because these aren't commands themselves.
-
- 25 Nov, 2015 1 commit
-
-
Devon Carew authored
-
- 16 Nov, 2015 1 commit
-
-
Collin Jackson authored
-
- 10 Nov, 2015 1 commit
-
-
Adam Barth authored
-
- 29 Oct, 2015 1 commit
-
-
Devon Carew authored
remove an unused import review comments rename st --> stack
-
- 28 Oct, 2015 1 commit
-
-
Devon Carew authored
-
- 17 Oct, 2015 1 commit
-
-
Devon Carew authored
-
- 12 Oct, 2015 2 commits
-
-
Adam Barth authored
This patch makes `flutter start` work without a clone of the engine git repository. Making this work pulled a relatively large refactor of how the commands interact with application packages and devices. Now commands that want to interact with application packages or devices inherit from a common base class that holds stores of those objects as members. In production, the commands download and connect to devices based on the build configuration stored on the FlutterCommandRunner. In testing, these fields are used to mock out the real application package and devices.
-
Ian Fischer authored
Also fixes some minor bugs with iOS and Android interactions.
-
- 10 Oct, 2015 1 commit
-
-
Adam Barth authored
I'm trying to get a feel for the code by writing some simple cleanup patches.
-
- 08 Oct, 2015 1 commit
-
-
Ian Fischer authored
-
- 06 Oct, 2015 1 commit
-
-
Devon Carew authored
-
- 29 Sep, 2015 1 commit
-
-
Ian Fischer authored
-