v1 and v2 will be deprecated on 2020-03-01. It is unclear if v2
will still be available afterward. According to
https://clubhouse.io/blog/api-v3/ it **should** be a drop in
replacement.
--
7f6c15aadc4d97e217dd446518dbb4fdc86b36a3 by Derek Mauro <dmauro@google.com>:
Upgrade GCC automated testing to use GCC 9.2 and Cmake 3.16.2
PiperOrigin-RevId: 288488783
--
a978cee848d3cf65b0826c981bfd81022fc36660 by Abseil Team <absl-team@google.com>:
Removing formatting traits that were only used internally. ON_CALL/EXPECT_CALL do a sufficient job here.
PiperOrigin-RevId: 288386509
--
fdec6f40293d5883220f1f0ea1261f7c5b60a66e by Derek Mauro <dmauro@google.com>:
Upgrade MacOS tests to use Bazel 2.0.0
PiperOrigin-RevId: 288373298
--
465865c4123e9481ab50ea0527e92b39519704dd by Derek Mauro <dmauro@google.com>:
Changes to support GCC 9
* Fix several -Wredundant-move warnings
* Remove FlatHashMap.Any test, which basically doesn't work on any platform
any more (see https://cplusplus.github.io/LWG/lwg-active.html#3121)
* Fix a constant sign-compare warning
* Conditionally compile out the PoisonHash test which doesn't build
PiperOrigin-RevId: 288360204
--
57c4bb07fc58e7dd2a04f3c45027aab5ecaccf25 by Andy Soffer <asoffer@google.com>:
Deflaking MockingBitGen test. Because MockingBitGen can return random values,
it is inherently flaky. For log-unifrom, 2040 is a common enough value that
tests failed unreasonably frequently. Replacing it with a significantly larger
value so as to be much less common. 50000 is a good choice because it is (tied for) the least likely to occur randomly from this distribution, but is still in the distribution.
PiperOrigin-RevId: 288360112
--
86f38e4109899d972de353b1c556c018cfe37956 by Matt Calabrese <calabrese@google.com>:
Remove construction tests for the internal `CompressedTuple<std::any>` instantiation. This was not guaranteed to work for the reasons that `std::tuple<std::any>` copy construction does not actually work by standard specification (some implementations introduce workarounds for this). In GCC9, `CompressedTuple<std::any>` and `std::tuple<std::any>` both fail for the same reasons, and a proper "fix" requires updating `std::any`, which is out of our control.
PiperOrigin-RevId: 288351977
GitOrigin-RevId: 7f6c15aadc4d97e217dd446518dbb4fdc86b36a3
Change-Id: I5d5c62bd297dc0ff1f2970ff076bb5cd088a7e4c
--
d3a10a071226497cd34be0f41cb55449193b7172 by Andy Soffer <asoffer@google.com>:
Removing formatting traits that were only used internally. ON_CALL/EXPECT_CALL do a sufficient job here.
PiperOrigin-RevId: 288342973
--
df8180038ea36a0876a84fdc163d1319a611f9db by Greg Falcon <gfalcon@google.com>:
Add CI testing for alternate options.h settings.
PiperOrigin-RevId: 288323951
GitOrigin-RevId: d3a10a071226497cd34be0f41cb55449193b7172
Change-Id: I26c75a1ededd52dd2c5a4c50e220d0b8a52d5c7c
After deciding to support the `C-s-` prefix for lispyville KBDs, I'm
re-introducing support for:
- `lispyville-drag-backward`
- `lispyville-drag-forward`
- `lispyville-end-of-defun`
- `lispyville-beginning-of-defun`
Previously my ERC setup just supported Google's internal IRC. Now I have
Freenode for things like #nixos, #emacs.
This complicated my KBDs for cycling through IRC channels since certain channels
only exist on certain servers. To remedy this, I introduced a temporary solution
that looks up the server given a particular channel. This isn't ideal, but it
works for now.
If you refer to the previous commit where I change shell-command usages to
start-process function calls, you'll see the rationale for why I prefer
start-process.
This commit introduces a more ergonomic API for start-process that fits most of
my current use-cases of it. This cleans up the code. I have introduced a bug in
the way that I'm tokenizing the COMMAND value. I've tracked that with a
TODO. For now it only affects the `xmodmap -e '<command-string>'` calls, which
isn't too disruptive.
Continuing the series of easy-win commits that increase the speed of commands
that I was previously using `shell-command` to run by using `start-process`
instead.
As promised in the previous commit, I'm refactoring usages of `shell-command` to
prefer the faster alternative `start-process`. So far, I'm pleased with the
results.
Without doing any benchmarking (break this naughty habit), I'm preferring to
call `start-process` instead of `shell-command` in my `wallpaper/set`
function. I noticed that the `shell-command` call was unnecessarily polluting my
`pstree` call when I debugging my randomly changing wallpaper bug.
I'm mostly likely going to change a few more `shell-command` calls to prefer
`start-process`.
While I first switched to EXWM warily and thinking it would only be temporary,
it seems like this switch is here to stay. It turns out that EXWM was exactly
the integration I've been looking for. How serendipitous it that I found it when
I did.
Thank you, @tazjin.
While this commit isn't much (i.e. notmuch), it represents one brave step
forward in the quest for supporting email in Emacs -- something I'm estimating
to be somewhere between a 1.5x and 2x workflow booster.
TL;DR:
Problem: I ran into a bug where my computer wallpaper was changing every five
seconds whenever my init.el file was open and I was typing in it.
Short-term solution: Disable flycheck.
Long-term solution: Disable flycheck just for Elisp or just for init.el in
Elisp.
Post Mortem:
Warning: If you have flycheck-emacs-lisp-initialize-packages set to auto or
really anything other than nil, than the emacs-lisp flycheck-checker will spin
up a new Emacs instance, and evaluate all of the Elisp in init.el.
Why does this matter? Well, if like me, you have code anywhere in your
init.el (and any files downstream from init.el), that code will get evaluated
not just twice. But countless times... tens, hundreds, w/e. So... while you
might think you have code that is just running at startup this code will be
called incessantly.
As a dramatic, contrived example, if you had something like...
```elisp
(bank/send :amount 100 :to "wpcarro@gmail.com")
```
...anywhere in that your init.el would evaluate, you may end up sending
wpcarro@gmail.com millions of dollars. To make debugging this problem a bit more
complicated is that because this runs in a separate Emacs instance, you can't do
something like...
```elisp
(defvar already-evaluated? nil)
(unless already-evaluated? (bank/send :amount 100 :to "wpcarro@gmail.com"))
(setq already-evaluated? t)
```
...since the `already-evaluated?` variable will be local to the Emacs
instance. So if you needed a mechanism to ensure code like this runs only once,
you would need a way to share this semaphore across Emacs instances --
e.g. writing to and reading from disk.
I'm sure that there is a fish package that supports git aliases or
abbreviations. This time, I'm preferring to write my own.
Side note: The more that I use fish's abbreviations, the less that I like them
-- at least for the way in which I'm using them.
I'm not actually sure if this is sensitive information, but I'm erring on the
side of caution and ignoring it in case it is.
squash! Ignore .gnupg/random_seed
This contains a little tool that can make requests to the Google Maps
API for distance matrix lookups from Fundu results to Schiphol Airport
and Amsterdam Centraal.
<3 edef!
Currently we just pick randomly between the cave and dungeon level
generators. There's a lot of bugs here, but it's *sorta* working, so I'm
leaving it as is.
This prevents them from being inlined. On gcc 9, this reduces the
stack size needed for
nix-instantiate '<nixpkgs>' -A texlive.combined.scheme-full --dry-run
from 12.9 MiB to 4.8 MiB.
(cherry picked from commit cb90e382b5b6e177ea902b3909fd1897643ae3cd)
If the user invokes nix with --trace-function-calls it means that they
want to see the trace.
(cherry picked from commit 619cc4af855fab7b0400586a4fd40745b23e72ad)
Add a data structure, based on the zipper comonad, which provides
support for multiple levels, each of which is its own entity map. The
current level is provided by coreturn, which the `entities` lens has
been updated to use. Nothing currently supports going up or down levels
yet - that's coming next.
This script rebuilds & activates system configuration based on the
hostname.
Currently since there is only one host this isn't particularly
interesting.
