diff --git a/content/posts/debuggers-really.md b/content/posts/debuggers-really.md new file mode 100644 index 0000000..2b84191 --- /dev/null +++ b/content/posts/debuggers-really.md @@ -0,0 +1,40 @@ ++++ +date = "2023-04-02" +draft = true +path = "/blog/debuggers-really" +tags = ["debugging"] +title = "Our debuggers are awful" ++++ + +* Working on otel for rust +* Have to vendor several things to get http request logs +* Why are browsers the only things that you can dump http request logs from +* Why can't I dump a http/2 protocol trace from h2 in rust? + +* This isn't a tracing problem + * Tracing is designed to not leak customer data + * Tracing is generally a metadata thing, *not* a data thing + * Tracing needs instrumentation and seeing the possibility of a problem + ahead of time +* What is a futuristic debugger, anyway? + * Integrate with rr + * Attach to a running system + * Has no overhead while not in use + * Can get information out of a system which has not yet been instrumented +* So thats just dtrace + * Yes kinda! But there's not enough instrumentation + * I can't dump the request logs into browser devtools (e.g. with a .har + file) + * Rust ecosystem does not really have deep dtrace integration +* Debugging a system is too important to disturb it + * Debugging a system is too important to care about module privacy +* Sidebar: "realness" + * When we build systems, we tend to treat the user . . . patronizingly, or + at least specially + * Database schemas with cursed tag-value schemas rather than dynamic + schemas + * Lowering things into a worse value representation that's different than + host-language objects + * Cannot introspect objects while ignoring module privacy, even though you + could exactly do this given ctf data + * RUSTC_BOOTSTRAP diff --git a/content/posts/nix-evaluation-blocking/index.md b/content/posts/nix-evaluation-blocking/index.md index fc813bc..07bf606 100644 --- a/content/posts/nix-evaluation-blocking/index.md +++ b/content/posts/nix-evaluation-blocking/index.md @@ -52,9 +52,12 @@ only take in things that are known statically; in Bazel it is thus common to check in generated build instructions. This property in category theory is illustrated in the type signatures of the operations of Monad and Applicative: -* `apply :: Applicative f => f (a -> b) -> a -> f b`
- which means that something *outside* the `f` box can be put into a - computation `a -> b` inside the box. +* `apply :: Applicative f => f (a -> b) -> f a -> f b`
+ which means that a value inside a box can be passed into a pure + computation `a -> b` inside a box. This is less powerful than `bind`, since + unlike `bind`, the function you provide cannot use the "a" it got to create + new operations involving boxes: this means that the build graph of an + Applicative build system is static. * `bind :: Monad m => m a -> (a -> m b) -> m b`
which means that if you have a value of type `a` in a `m` box, you can *get the `a` out of the box* and create a further computation in a box depending