Jeremy Schlatter
Jeremy Schlatter
I was [packaging up sandboxfs](https://github.com/NixOS/nixpkgs/pull/99353) to make it available through the nix package manager, and stumbled on the lack of a checked-in Cargo.lock. Checking in Cargo.lock seems to be the...
In typical cases, this gives the same result as the existing logic. On my system, "go env" gives the correct answer and the existing logic does not. I use the...
godebug's current procedure for running instrumented code for a package `x` is: - make a temp directory - make a subdirectory `$TMP/src/x` containing instrumented versions of the source files for...
I am debugging a program that has a dependency on package `foo`, and I want to step into function calls in `foo`. So I run: `$ godebug run -instrument=foo myProg.go`...
Given this directory structure: ``` a $ tree . ├── a.go └── b ├── b.go └── c └── c.go 2 directories, 3 files ``` ``` a $ cat a.go package...
After a loop reaches a break statement, godebug unnecessarily prints the loop statement again. ``` $ cat min.go package main func main() { _ = "breakpoint" for i := 1;...
godebug currently invokes `go build` [twice](https://github.com/mailgun/godebug/blob/5c173f56b398bc13fd4175bc828cb1b6bfa9e47e/cmd.go#L192-L196) as a workaround for how the go tool handles GOPATHs with multiple directories. In Go 1.5, [this should be fixed](https://github.com/golang/go/issues/10509).
Inserting debugging calls at every line definitely slows the program down. But by how much? Some benchmarks would be nice.
Chime interprets code really slowly right now. I have two optimizations planned: 1. Implement the entire standard library natively in Haskell. 2. Represent numbers, lists, variable bindings, and other Bel...