Going forward, all documentation should be placed in the Documentation
directory in the root of the project. This switch allows maintainers to
approve updates to documentation before they are committed, as opposed
to the pre-existing wiki which anybody could modify.
Currently the Documentation directory includes docs on building, usage,
and minimal docs around the API. This is just the initial commit, and
documentation will continue to improve over time.
Some changes have been made (and will continue to be made) to `cmd/dlv` to
ensure we can auto-generate documentation for all commands from the
newly provided script `scripts/gen-usage-docs.go`, which can be invoked
via `go run scripts/gen-usage-docs.go`.
Additionally, version has been split into its own package. This was a
bit of housekeeping related to the changes made the `cmd/dlv`.
This patch allows certain commands (`debug`, `test`, and `trace`) to
take an argument specifying a package name. This allows a user to
specify a package other than that of the current package in the working
directory.
If a package name is not specified, the behavior remains the same, as in
Delve will look in the current working directory for a `main` package to
compile.
Fixes#423
This change addresses a Windows-specifc issue with the 'test' command. On
Windows, 'go test' generate executables with a '.exe' filename extention,
but the current implementation attaches to a filename without the
extention.
The 'source' command reads the file specified as argument and executes
it as a list of delve commands.
Additionally a flag '--init' can be passed to delve specifying a file
containing a list of commands to execute on startup.
Issue #96
This renaming avoids confusion with the 'run' subcommand in the go tool.
The 'run' subcommand in Delve is now deprecated. It is still there,
however simply prints a deprecation notice and exits.
Instead of maintaining two separate client / server implementations,
maintain only the more lightweight JSON-RPC service. The reasoning
behind the merging of the original HTTP service was ease of tooling, in
other words low barrier of entry for external clients (editor
integrations, etc...).
I believe the JSON-RPC solution still satisfies that constraint while
have the advantage of being a more lightweight solution. HTTP, while
highly supported in most modern languages, carries with it too many
features we would never take advantage of. The RPC architecture seems
a more natural approach.
The infrastructure set up during the initial HTTP service implementation
was leveraged in the JSON-RPC implementation, so if any of those
original authors are reading this commit message: thank you for that
work, it was not in vain even if though the original HTTP service is not
being removed.
Refactor to introduce client/server separation, including a typed
client API and a HTTP REST server implementation.
Refactor the terminal to be an API consumer.
