Update sky_server:
- update its help string to admit that it wants the package path as well.
- be quiet by default, since it makes the build chatty.
- have a -v for verbose mode, for people who like it chatty.
- have a default port of 8000, since that's what everyone used.
- have a -p option to set the port, for people who don't use the default.
- remove its mapping for gen/, since a TODO told me to.
- remove the dependency on the build configuration, since it's no longer used.
- teach it about .dart files.
- rename sky_server/README to README.md, for consistency with other READMEs.
Update shelldb to speak the new sky_server protocol.
Update tests/services/iframe-embed-vmc.sky since the sky_server change broke the hack it was using.
Update skyserver.py to speak the new sky_server protocol.
Make webkitpy use SkyServer instead of spawning sky_server itself, since a TODO told me to.
Teach webkitpy about dart files.
Teach test_perf about dart files. (untested)
Teach sky_tool about main.dart, main.sky is deprecated. (untested)
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/1200993002.
Dart actually expects package: to work. This CL makes package:foo
map to /packages/foo, similar to how Dartium or bin/dart would expect.
This also means overlaying the /gen directory over the actual package
outputs (as consumers of an SDK would expect) as well as adding
an additional /lib indirection for the actual package source as
the Dart pub tool will expect.
This is far from perfect, but it unlocks us actually producing a
sky SDK.
I expect there may be some fallout from this change as I'm sure I
missed some package: uses. We also don't have a general solution
for all /foo/bar/baz includes which randomly included parts
of mojo's source directory. Those will need to be updated to use
a package: and deploy_sdk.py taught how to build a package for them.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/990493002
This is basically skydb v2, except only for android.
I revisited some of the architecture decisions I made
in writing skydb. I also separated skyserver.py from
dependency on skypy/paths.py since it wasn't really adding
any value.
We could make this way fancier, but this should at least
make working with SkyDemo.apk easier for now.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/960233007
This only barely works. We pull down system libraries
once before we attach. The libraries we pull from
the device do not have debug symbols, but have enough
that we have decent callstacks. We launch a background
process to repeatedly update a cache directory with
symlinks into our build directory corresponding to the cache
names used on the device, however gdb doesn't watch
the solib-search-path directories to notice the links
as we add them.
Better solutions would be to add support for pulling
down full android symboled system images and using those
instead of pulling libraries off the device as well as
figure out how to get android binaries to support
build-id so that we can present a directory of build-id
associated libraries to gdb on boot and have it to build-id
based lookups of libraries instead of our current broken
watch-logs-and-add-symlinks approach.
If you know what you're doing with this you can actually
make debugging work on the device. It's not particularly
user friendly yet, but we'll work on it.
I added a build_dir member to skypy.paths.Paths
as a temporary measure before we move off of skypy's
paths and onto mopy's paths. This helped eliminate
problems with using a relative path in args.build_dir
as is common.
R=abarth@chromium.org, ojan@chromium.org, qsr@chromium.org
BUG=
Review URL: https://codereview.chromium.org/855663003
This fixes 3 little bugs in skydb:
1. Adds a logcat command to make it easy to see android logs
2. Fixes using relative build dirs in skydb start
3. Stops sending /quit to debugger.cc since mojo shutdown
doesn't actually work (crashes).
--gdb is still broken, but I'll fix that in a second change.
R=ojan@chromium.org
Review URL: https://codereview.chromium.org/852483002
This makes it much easier to work with a device where we
don't expect a persistent commandline session. Prompt no longer
actually makes a prompt but rather just runs an http server.
This is just a v1 patch. It doesn't work with android yet
and it isn't smart enough to allow you to run more than one
copy of prompt.cc at the same time (since you can't control
the port it listens on). If you have a second copy of
prompt runnning (or anything else bound to port 7777) it will
just crash.
We could make this a lot better, including splitting out the
pid-file tracking for sky_server into sky_server instead of
having skydb manage it.
R=ojan@chromium.org, abarth@chromium.org
BUG=
Review URL: https://codereview.chromium.org/840973002
This is a proof of concept for replacing ui/views
code with Sky instead. erg says this will allow him
to delete 10s of thousands of LOC from mojo.
Mojo does not yet expose the current binary's URL:
https://docs.google.com/a/chromium.org/document/d/1AQ2y6ekzvbdaMF5WrUQmneyXJnke-MnYYL4Gz1AKDos
So I've worked around that by passing the url
of the binary via the helper script.
I discovered several bugs in the wm_flow code
including that it doesn't handle view resizes
(during embiggen). Related, I discovered that
every time a new window is made it drops the
connections to the embedded.cc app from the
previous window, since the ViewManagerDelegate
is incorrectly implemented as part of the
ApplicationDelegate on both app.cc and embedded.cc.
We'd need to split out a separate per-view object
in both of those apps to handle the
ViewManagerDelegate calls.
There are some changes to logging during loading
as well as the CopyToFile helper to have better
error reporting. I hit several issues early on trying
to get mojo to load the http: urls correctly, including
eventually running out of disk space on my /tmp
and mojo then silently failing to launch the app
(due to mojo never clearing its caches crbug.com/446302).
I had to re-write the mojo_demo.sh script in python
as well as split the sky_server handling code out of
skydb into a separate python module in order to cleanly
launch sky_server. We could use a separate server
if we wanted to but the primary benefit of sky_server
is that it sets up the proper url->disk mappings into
the generated file directories, etc.
BUG=443439
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/817573003
This CL teaches test_perf how to walk the benchmarks directory to find the
benchmarks and how to actually run them. We're still not uploading results to
the server yet, however.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/710133002
This script isn't quite working, but it's valuable to checkpoint the work at
this point. I'm coordinating with the chromeperf.appspot.com folks to get the
server to accept the data.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/702603005
