Make Store::buildPaths return a Status with [[nodiscard]] rather than
throwing exceptions to signal failure. This is the beginning of a long
road to refactor the entire store API to be status/statusor based
instead of using exceptions.
Change-Id: I2e32371c95a25b87ad129987c217d49c6d6e0c85
Reviewed-on: https://cl.tvl.fyi/c/depot/+/1745
Tested-by: BuildkiteCI
Reviewed-by: kanepyork <rikingcoding@gmail.com>
We have decided that leaking memory is a better fate than random,
non-debuggable memory corruption. Future CLs will begin changing
various fields to std::unique_ptr and std::shared_ptr.
It turns out that disabling the GC does not have disasterous impact.
The Nix evaluator only runs on the client CLI, never in any long-
running process. Even the REPL does not leak too badly under this
change, because it uses one EvalState for the duration of the REPL.
Building an explicitly tracing garbage collector is likely in the
future of this project, but that giant amount of work cannot be
done under a nix evaluator that is constantly crashing. We need to
restore development velocity here, and this is the best way we've
figured out to do it.
Change-Id: I2fcda8fcee853c15a9a5e22eca7c5a784bc2bf76
Reviewed-on: https://cl.tvl.fyi/c/depot/+/1720
Reviewed-by: glittershark <grfn@gws.fyi>
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
the %l capture template field already has square brackets around it.
Change-Id: I1229dd3f4c9b0f414da2bdee9964d3c9837af818
Reviewed-on: https://cl.tvl.fyi/c/depot/+/1742
Reviewed-by: glittershark <grfn@gws.fyi>
Tested-by: BuildkiteCI
I have an encrypted drive, so this extra layer of security is pointless
Change-Id: Ifa523ee5ea545b5ee17536d34f60d7235e47f25c
Reviewed-on: https://cl.tvl.fyi/c/depot/+/1741
Tested-by: BuildkiteCI
Reviewed-by: glittershark <grfn@gws.fyi>
Today @tazjin told me about Emacs's built-in project.el library, which he
recommended that I extend to support monorepo-specific tooling. It worked like a
charm!
Now when I press "<leader>f", it will resolve to either the nearest file named
default.nix or directory name .git.
This gives better overall results and may also prevent drift, which
was an issue I've had previously.
See also this upstream commit for NSFV:
34003bd9ab
Change-Id: I45534cb60130755949cdbfbc39aed2478a249c72
Reviewed-on: https://cl.tvl.fyi/c/depot/+/1717
Tested-by: BuildkiteCI
Reviewed-by: glittershark <grfn@gws.fyi>
Use Nix and Briefcase to easily create Haskell executables.
I'd eventually like to support something like: briefcase.buildHaskell.project
that let me define a few top-level values (e.g. ghcExtensions) and would give me
a ghci environment with the proper `.ghci` settings so that my development
environment mirrored my build environment... baby steps, though.
Per the assignment's instructions, the `Shift n` operation should treat
the *entire keyboard* like a cycle and shift that. I was erroneously
treating *each row* like a cycle and shifting those one-by-one.
This change fixes that. In addition, it also:
- Updates README.md with expected inputs and outputs
- Updates test suite
- Adds `split` dependency to {default,shell}.nix
TL;DR:
- include a default.nix to allow users to build an named executable
- emphasize in the README that the user needs Nix to build this project
- pin nixpkgs to a specific commit and fetch it from GitHub
Per my take-home assignment's reviewer's comments, with which for the record I
agree, I should generate the character->coordinate table from my existing qwerty
keyboard definition.
The best part is: by doing this I found a bug: Notice how the original '0'
character was mapped to the Coordinate (0,0)... thus every subsequent digit
key (i.e. the first row) is off-by-one.
Adds the same entries that are also listed on the homepage itself to
the feed.
Change-Id: I6586dcb899d40536777ac5a5dfcac4bb1cc8cee5
Reviewed-on: https://cl.tvl.fyi/c/depot/+/1715
Tested-by: BuildkiteCI
Reviewed-by: kanepyork <rikingcoding@gmail.com>
This allows for adding feed entries which only have an alternate
representation (i.e. URL that points somewhere else).
These entries will still have a summary, in my use-case.
Change-Id: I149838c5f59c66e8169b97f35b378aefe9763a84
Reviewed-on: https://cl.tvl.fyi/c/depot/+/1714
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
To use cheddar for both the feed & web views, the rendering function
is extracted a level up - this prevents duplicate renderer calls.
Change-Id: I31812c5c3f905f2f84914c6a8ab7c14602227be1
Reviewed-on: https://cl.tvl.fyi/c/depot/+/1710
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
This only adds the feed generation functions, but does not yet wire it
up to the blog content.
This was implemented against
https://validator.w3.org/feed/docs/atom.html and I've validated some
generated example feeds with the W3 validator.
Change-Id: Ide3ea90d3fa935047506aa87169100c2ead21284
Reviewed-on: https://cl.tvl.fyi/c/depot/+/1709
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
The parser contained vectors, and the primary parser state, that
were not participating in GC tracing.
Change-Id: Ie198592cd7acffd390e3e2ae9595138b56416838
Reviewed-on: https://cl.tvl.fyi/c/depot/+/1706
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Reviewed-by: glittershark <grfn@gws.fyi>
Invocations of the MakeError macro that were not followed by a
semicolon messed up indentation in the next lines.
Change-Id: I03d7d1443f062a38af2c7da3da8928e0ed05e274
Reviewed-on: https://cl.tvl.fyi/c/depot/+/1708
Tested-by: BuildkiteCI
Reviewed-by: kanepyork <rikingcoding@gmail.com>
After burning a few hours wrestling with the type system, I decided to revert to
the simpler `Server API` type instead of the `ServantT` transformer type.
The problem is that I couldn't write a MonadError instance for `RIO Context`,
which is my `AppM` (i.e. application monad). Using `throwIO` in the server
handlers results in 500 errors, which is not what I wanted. I'm still pretty
fuzzy about what's happening; I now know that exception handling in Haskell is
pretty gnaryly. I may revisit this at a later time when my knowledge is more
extensive. For now: time to fry bigger fish.
An easier abstract is for me to pass `T.Context` into `server` as an argument,
which after all is what a Reader does.
TL;DR:
- Read server, client ports from .envrc
- Define a top-level Failure type (empty for now)
- Define a top-level Success type
- Define App as RIO Context (Either Failure Success)
Long story -> short: I'd like to access my App monad from within my Servant
handlers.
While this code type-checks, I'm not sure it's working as intended. Needing to
change throwError to throwIO fails the "smell test". I expect to refactor this
code, but I'm calling it a night for now.
I believe RIO stands for: "ReaderT <something-something> IO", which is a nod to
the top-level application data type:
```haskell
-- This is a simplification
newtype RIO env a = RIO { runRIO :: ReaderT env a () }
```
I read about RIO from an FP-Complete blog post a few months ago, and now I'm
excited to try it out for a real project. Bon voyage!
This reverts commit 3115113854.
Reason for revert: this is causing all issues to return a 404 - reverting until we can get it working.
Change-Id: I5f3c5ec3b24f245a1f7ef12645200d16ed0f1b35
Reviewed-on: https://cl.tvl.fyi/c/depot/+/1721
Tested-by: BuildkiteCI
Reviewed-by: edef <edef@edef.eu>
Aded a few test cases covering the scanForReferences function, which had
been accidentally broken in 976a36c (which is now partially-reverted).
As part of this, since the test needed to generate hashes for store
paths, the logic in MakeStorePath to compress a sha256 hash down to 20
bytes and convert it to base32 has been extracted to a member function
on the Hash class.
Fixes: #34
Change-Id: Ie2d914688a80f42d0234d351a7cc0714fd15709e
Reviewed-on: https://cl.tvl.fyi/c/depot/+/1698
Tested-by: BuildkiteCI
Reviewed-by: kanepyork <rikingcoding@gmail.com>
As the previous commit mentions, I'm attempting to build and deploy this project
with `nix-shell` and `nix-build` instead of `cabal` and `stack`.
I'm in the Hamburg airport right now, and my internet connection isn't stable
enough to test this, so I'm committing it until I can more robustly test it.
I'd like to see if I can avoid using `cabal` and `stack` and build and deploy
this application using `nix-shell` and `nix-build` only. Let's see how that
goes.
All of the miscellanious structs that make up a nix Value should inherit
from gc, as they contain pointers to GC'ed things as members
Fixes: #42
Change-Id: I057d8c9f7dafbee7de7644ff152c9cba1aa6bc03
Reviewed-on: https://cl.tvl.fyi/c/depot/+/1696
Tested-by: BuildkiteCI
Reviewed-by: kanepyork <rikingcoding@gmail.com>
Now that we've fully implemented the RPC-based store client, we can get
rid of the UDSRemoteStore, whose only use was connecting to the locally
running nix daemon. The RemoteStore still needs to be around to connect
to remote upstream nix stores over SSH.
Change-Id: I0699819803cbfe966b9a46786f2c927d8e4bf1a2
Reviewed-on: https://cl.tvl.fyi/c/depot/+/1693
Tested-by: BuildkiteCI
Reviewed-by: kanepyork <rikingcoding@gmail.com>
Implement all remaining RPC calls on the RpcSstore client, remove a few
stub methods we had added that weren't actually present in the old
RemoteStore implementation, and add one more RPC call for getBuildLog
that is present in the store API, but that we hadn't added as a
stub *or* to the proto.
Fixes: #29
Change-Id: Id827f51a393ece4bc7bbecaf38aee9eb4b329770
Reviewed-on: https://cl.tvl.fyi/c/depot/+/1692
Reviewed-by: kanepyork <rikingcoding@gmail.com>
Tested-by: BuildkiteCI
Factor out the shared utilities for interacting with protobufs/grpc from
libstore to a proto.hh header in libproto.
Change-Id: I1cb8d94867d5d4b63a9994be0b53f8f612eb8e3a
Reviewed-on: https://cl.tvl.fyi/c/depot/+/1691
Tested-by: BuildkiteCI
Reviewed-by: kanepyork <rikingcoding@gmail.com>
To aid in debugging RPC call failures, pass the name of the function
being called to the SuccessOrThrow util funcion in the RpcStore
Change-Id: I523dacfab896b85a3dbe6050c07ee6bd5906fa44
Reviewed-on: https://cl.tvl.fyi/c/depot/+/1690
Tested-by: BuildkiteCI
Reviewed-by: kanepyork <rikingcoding@gmail.com>
Wrap the BuildPaths and AddTextToStore RPC handlers in HandleExceptions.
These were missed in the original pass due to a merge.
Change-Id: Ie5be45e6098fba7a2b6b1c1be81578cb742c2880
Reviewed-on: https://cl.tvl.fyi/c/depot/+/1689
Tested-by: BuildkiteCI
Reviewed-by: kanepyork <rikingcoding@gmail.com>
