I've subtly been implementing breadth-first traversals in graphs
incorrectly. The change is subtle, but updating `seen` needs to happen
immediately after queuing an item.
The results will remain the same, but the runtimes will differ dramatically. I
didn't notice this until I attempted to complete LeetCode's "count islands"
challenge, and LeetCode rejected my solution because it could not finish before
timing out. After looking at other candidates' solutions and comparing them to
mine, I couldn't see any difference... except for this subtle difference.
This SO answer provides a helpful explanation:
https://stackoverflow.com/questions/45623722/marking-node-as-visited-on-bfs-when-dequeuing
The take-away lesson here is to always call `seen.add(..)` immediately after
enqueuing.
This adds my standard inputrc to my home-manager configuration, via the
latter's readline module, and adds nix-shell detection to my bash prompt
string.
Additionally, nix-shell is wrapped in a shell function, so that entering
a nix-shell environment automatically runs bash as a subprocess where
appropriate, as the default environment spawned by nix-shell is not to
my liking.
Change-Id: Id5b1b9415a185ad9920f268c66de32d6ccc0b452
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2146
Reviewed-by: multi <depot@in-addr.xyz>
Tested-by: BuildkiteCI
This was only done to get an upgraded version, which is no longer
necessary with the nixpkgs bump but was also causing incompatibilities
with opengl
Change-Id: Ic398b4ac6caf24a1d40b7a4917b5053fba12d97a
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2145
Reviewed-by: glittershark <grfn@gws.fyi>
Tested-by: BuildkiteCI
... still not that interesting, but at this point slightly divergent
from the book:
The book embraces mutability for interpreter state, initially for
tracking whether an error condition has occured.
I avoid this by instead defining an error type and collecting the
error values, to be handled later on.
Notes: So far nothing special, but this is just the beginning of the
book. I like the style it is written in and it has pointed to some
interesting resources, such as a 1965 paper titled "The Next 700
Languages".
Change-Id: I030b38438fec9eb55372bf547af225138908230a
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2144
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
... as well as a Nix derivation, because why not.
Change-Id: Iaf2591ab72676fe0732c3f807b3aa0cff13fb4ef
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2143
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
This is going to be the first of two interpreters from "Crafting
Interpreters".
Change-Id: I354ddd2357444648d0245f35d92176dd176525d8
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2142
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
This is passed by some third-party tools, notably home-manager. At some
point we should fully revamp argument parsing and log verbosity setting,
but for now this gets us to more of a working state
Fixes: b/78
Change-Id: I4134b17315e30145fd43d3659f407d7121ce8876
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2136
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
It seems like the amount of logging is causing things to move a little
slower - even if that's not really the case, it gets in the way of
debugging things.
Refs: b/76
Change-Id: I9ea99a3b16e3307a0b0371bad22d03b0e2175af6
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2134
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Mugwump is too unstable for such an important internet service
Change-Id: Ic714200ce5ce51f366777f538b4a6f443f010960
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2124
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
To aid in both debugging and (eventually) printing stacktraces, add a
Pos member to a few more Expr variants.
Change-Id: Ic1d2a056fc7e6c07bc3e79fa38845cb4a5da5ca5
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2133
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Add the depot.nix module and a depot config option to all nixos system
derivations that're build through the `bin/rebuild-system` machinery.
I can't imagine a scenario where we wouldn't want this level of
integration.
Change-Id: Ieeb98db2eee23919256adb4654bc45d540e055ec
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2128
Tested-by: BuildkiteCI
Reviewed-by: lukegb <lukegb@tvl.fyi>
Prefix all IRC notifications from panettone with a unicode
zero-width-space so that they don't get picked up by other IRC
bots (notably bslsk05).
Change-Id: I350fd1b6d2145e496c22a8f56ba3530fc9f1a978
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2127
Tested-by: BuildkiteCI
Reviewed-by: lukegb <lukegb@tvl.fyi>
Reviewed-by: tazjin <mail@tazj.in>
Send an irc notification when issues are marked closed, in a similar
format to the notifications sent when new issues are created.
Change-Id: I2fdde33f0dedc223a5c2265eed778161938f8e9a
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2126
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
I previously removed my local package set from my HM config while the
latter was being made readTree compatible. Now that both the HM config
and the local package set can be built with readTree, I can re-enable
the locally-overridden htop package.
Change-Id: I77e20248c010bc7027e0b0a3164ec48d6ec29f31
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2132
Tested-by: BuildkiteCI
Reviewed-by: multi <depot@in-addr.xyz>
This adds readTree configuration for accessing my local package set,
and also adds these packages to the CI configuration.
Change-Id: Icd2d16e85859343902e73a466f3c6ba8d781537f
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2131
Tested-by: BuildkiteCI
Reviewed-by: multi <depot@in-addr.xyz>
This reverts 1478317d149539d74fa4bad8414658fb7119ea07.
Using depot.depotPath in my home-manager configuration results in my
NIX_PATH and home-manager config file path being pointed at a copy of
the depot in the nix store, which makes building from my local depot
checkout a bit cumbersome.
Change-Id: Ib687d3e8147cb32df071d3c19a5300294ea62c0c
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2130
Tested-by: BuildkiteCI
Reviewed-by: multi <depot@in-addr.xyz>
Add a new home-manager-compatible configuration file which loads the
common config attrset used by the readTree machinery into a structure
which the home-manager command line tool understands.
Garbage-collect the old home-manager configuration file used on whitby,
and update the HOME_MANAGER_CONFIG path to point at the new shim config.
Instead of having a per-environment HM configuration (not that I have
more than one environment), there's now a single configuration which
evaluates to an attrset of configurations, which can be loaded and built
using "home-manager build -A $attr".
Change-Id: Id8b35dc89aabffedf1a4dadfa0d3d4b914e4e2e7
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2129
Tested-by: BuildkiteCI
Reviewed-by: multi <depot@in-addr.xyz>
My home-manager config is not currently readTree compatible, which means
that it's not built by CI. This constructs a house of cards around
home-manager to make this buildable in CI.
Change-Id: I80480f24ff47347f46d708edbbf34d59fa76adac
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2123
Tested-by: BuildkiteCI
Reviewed-by: multi <depot@in-addr.xyz>
The depot knows where it is, not because it knows where it isn't, but
because it does an "import ./." at the top level and then makes this
path value available in the attrset passed to the rest of the tree.
My home-manager config on whitby previously involved manual
specification of the depot checkout location on whitby, however this
isn't necessary when the depot can already magically tell us where it
is.
Change-Id: I68577c8ef2cda6ba5bc46cf8f4821aac021c8066
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2122
Tested-by: BuildkiteCI
Reviewed-by: multi <depot@in-addr.xyz>
This reverts commit e1067b1497.
The original issue here was misusing ISSUE-ID instead of ID, but also
the associated username for the message should've been CN instead of DN
Change-Id: I1629c0cb7597ff2ee2867f27870378eecdafe126
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2125
Tested-by: BuildkiteCI
Reviewed-by: eta <eta@theta.eu.org>
"let pkgs = import <nixpkgs> {}; in pkgs.home-manager.src" evaluates to
the source derivation for home-manager, however home-manager's configuration
machinery expects to be passed the store path of this derivation instead of the
derivation object itself.
Change-Id: I6b0ba3efaff9d080900349529576443192b058e9
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2121
Reviewed-by: multi <depot@in-addr.xyz>
Tested-by: BuildkiteCI
Included fixes for random breakage:
* 3p/awscli: pick from the stable channel; it is broken on unstable
* 3p/googletest: bumped version & removed patches that nixpkgs applies
* 3p/lisp/cffi: bumped library version for SBCL compat
* 3p/nix: fix libsystemd attribute
* 3p/nix: reformatted (clang-format handling of ternaries changed)
* glittershark/home: Use home-manager from nixkpgs
* glittershark/kernel: bumped linux-ck patch hash
* glittershark/kernel: removed "patch patch"
* multi/whitby: Use home-manager from nixpkgs
* tazjin/frog: drop Sourcetrail (it doesn't build currently)
Note that in addition to these changes, some previous CLs updated the
versions of git and cgit which was necessary for this channel bump,
but which could not be done in the same commit due to the nature of
the subtree merges.
Change-Id: If2563e8a68e2750c4b913a976ff7b93b42e8b7f3
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2110
Tested-by: BuildkiteCI
Reviewed-by: multi <depot@in-addr.xyz>
Reviewed-by: glittershark <grfn@gws.fyi>
Previously changed kernel versions would not cachebust the patch
download, because it would still be using the same SHA hash.
Forcing a different store path (by adding the version to the name)
also forces a redownload of the patch (and in turn cause the hash to
mismatch), avoiding this as a silent cause of failures in channel
updates.
Change-Id: I81a136ee2401126795cf042b0aadf2a1e7a707b4
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2114
Tested-by: BuildkiteCI
Reviewed-by: glittershark <grfn@gws.fyi>
This also bumps the stable nixpkgs to 20.09 as of 2020-11-21, because
there is some breakage in the git build related to the netrc
credentials helper which someone has taken care of in nixpkgs.
The stable channel is not used for anything other than git, so this
should be fine.
Change-Id: I3575a19dab09e1e9556cf8231d717de9890484fb
The space cost is O(n). The runtime cost of enqueue is O(1); the runtime cost of
dequeue is O(n). Using the "accounting method", the cost of an item in the
system is O(1). Here's why:
+------------+----------------------------+------+
| enqueue | push onto lhs | O(1) |
+------------+----------------------------+------+
| lhs -> rhs | pop off lhs; push onto rhs | O(1) |
+------------+----------------------------+------+
| dequeue | pop off rhs | O(1) |
+------------+----------------------------+------+
... notably, this includes Abseil's own StatusOr type, which
conflicted with our implementation (that was taken from TensorFlow).
Change-Id: Ie7d6764b64055caaeb8dc7b6b9d066291e6b538f
The bottom-up solution run in O(n) time instead of O(2^n) time, which the
recursive solution runs as:
```
def fib(n):
return fib(n - 2) + fib(n - 1)
```
Remember that exponential algorithms are usually recursive algorithms with
multiple sibling calls to itself.
Write a predicate for checking if a linked-list contains a cycle. For additional
practice, I also implemented a function that accepts a linked-list containing a
cycle and returns the first element of that cycle.
The Abseil version of `StatusOr` does not come with the status macros
or the `Consume*` family of functions.
This change modifies the existing code to use the common denominator
of the API that is available between Abseil's own implementation of
`StatusOr` and the one from Tensorflow that we are currently using.
Change-Id: I5c37f68636a1fd54d153f95d7303ab8644abb774
I believe the previous solution is invalid. This solution works and it should be
more time and space efficient.
Space-wise our stack grows proportionate to the depth of our tree, which for a
"balanced" BST should be log(n). Doing a BFT on a BST results in memory usage of
n because when we encounter the leaf nodes at the final level in the tree, they
will be 1/2 * n for a balanced BST.
InterviewCake.com has a section on Facebook's interview, so I'm attempting to
solve all of the problems on there even if that means I'm resolving
problems. The more practice, the better. Right?
URL: interviewcake.com/facebook-interview-questions
This is the mother of dynamic programming algorithms in my opinion. It computes
the minimal "edit distance" between two input strings where an edit is
considered one of:
- inserting a character into `a`
- deleting a character from `a`
- substituting a character in `a` with a character from `b`
It took me awhile to grok the algorithm, but I implemented this from my
understanding of something that I read ~3 nights prior, so I must've understood
what I read. Good news!
This morning, I attended the "Interview Club" and was asked this question by the
interviewer in front of ~20 FTEs. While I struggled to fully solve it during the
abridged (i.e. 20 minute) timeslot, I completed the problem afterwards.
Here is my solution.
Create a suffix tree from an input string. This implementation uses a stack to
control the flow of the program.
I expected this attempt to be easier than my first attempt, but surprisingly, it
was similarly difficult. It took me ~30-45 minutes to successfully implement
this function, and I'm still not pleased with the final result.
While it took me awhile to implement, this exercise was definitely worth
doing. I think there should be a more elegant way to construct the tree using
maybe a stack, but I couldn't find it.
All of this was part of a larger effort to search a string for a variety of
patterns. The solution is to compile the string into a suffix tree and then
search the suffix tree for each of the patterns.
I'm glad I didn't gloss over this exercise.
Passing a string directly to add_paths like this causes the proto class
to take ownership over the string, meaning when it is destructed it
will *explicitly* free the string. When the string's actual owner (the
derivation struct) then goes out of scope it'll get freed again, causing
a double-free. This fixes that to instead use the copy constructor to
assign to a pointer to a new path, and covers the whole to_proto method
with a rapidcheck test.
Fixes: b/64
Change-Id: I84235bed9104ff430a0acf686d4a96f1e2e9a897
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2106
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
This was accidentally using the proto arena API to assign the derivation
field of a BuildDerivationRequest. We *thought* this was causing a
double free, but even with this change that's still happening. That
said, this change is probably still a good idea since it's using the
proto API as intended.
References: b/64
Change-Id: I950a4eafb214e9113639ea54d2dfd4659b7be931
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2104
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
This reverts commit 2e2bdf9c6c.
Reason for revert: this is not working, and is resulting in newly created issues just showing a blank page (b/74)
Change-Id: I3f06afc52d6c5289269402fc75bb32ad9c376bf4
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2082
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
- htop has moved upstreams, which has been producing new releases, so
update the derivation to pull from the new repository on GitHub.
- All of the patches I have locally have been merged upstream, so drop
them from the depot.
- Pull from a reasonably recent git commit instead of from a numbered
release, as the ZFS ARC stats and CPU meter columnation patches
haven't made it into a release yet.
Change-Id: I66ad4c035df07709abf4f75a9d4e1486920091d0
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2105
Reviewed-by: multi <depot@in-addr.xyz>
Tested-by: BuildkiteCI
