I decided to start writing go code for scripts instead of python. I think this
will be a learning opportunity for me and should increase the integrity of my
scripts by adding some static type checking.
--
0b924fe4e9871200792617329d32beb8356daa9b by Derek Mauro <dmauro@google.com>:
Use less threads in the GetTID() test to avoid test timeouts
PiperOrigin-RevId: 292566826
--
0b519c4fd48d61b7c4ea94ed6a6be6e981b9c51a by Abseil Team <absl-team@google.com>:
Internal change.
PiperOrigin-RevId: 292563778
--
3204f6e07bcc2b5e9098d45f1a20998f25ab808e by Abseil Team <absl-team@google.com>:
Internal change.
PiperOrigin-RevId: 292550551
--
09fbbe73833478d3f26f3e33c8291b991fd3be51 by Derek Mauro <dmauro@google.com>:
Add a debug bounds-check to absl::string_view::operator[]
string_view accesses that are out-of-bounds are undefined behavior:
https://en.cppreference.com/w/cpp/string/basic_string_view/operator_at
This change causes code to abort in debug mode, indicating a bug and
possibly a security issue like a buffer overflow. Code broken by this
change should be investigated.
PiperOrigin-RevId: 292544735
--
bf2c19cb45682628f963d4067c0cd6deed7e656d by Derek Mauro <dmauro@google.com>:
Add debug assertions to absl::string_view::front and absl::string_view::back
Calling front() or back() on an empty string_view is undefined behavior. This
assertion is to help catch broken code.
https://en.cppreference.com/w/cpp/string/basic_string_view/fronthttps://en.cppreference.com/w/cpp/string/basic_string_view/back
PiperOrigin-RevId: 292453255
--
47f573679b322f8c0fd2cb037cc87e7bc822ac6b by Xiaoyi Zhang <zhangxy@google.com>:
Release functional/CMakeList.txt.
PiperOrigin-RevId: 292417025
GitOrigin-RevId: 0b924fe4e9871200792617329d32beb8356daa9b
Change-Id: Ie6980fb1ac351d72a2ce4468f25bd31db396f88a
I think the name deploy is more representative of the purpose of this directory
since docker is just one of a few tools that I'm using to deploy software.
Renaming my mono-repo briefcase.
I first introduced this commit in master, but it introduced a bug where one of
two things would happen:
1. Emacs wouldn't start and would crash X.
2. Emacs would start but my keyboard wouldn't work.
I learned some valuable debugging skills in the process. Here are some of them:
When my keyboard was broken, I wanted to control my computer using my
laptop. Thankfully this is possible by using `x2x`, which forward X events from
the SSH client to the SSH host.
```shell
> # I'm unsure if this is the *exact* command
> ssh -X desktop x2x -west :0.0
```
Git commit-local bisecting. I didn't need to do a `git bisect` because I knew
which commit introduced the bug; it was HEAD, master. But -- as you can see from
the size of this commit -- there are many changes involved. I wanted to binary
search through the changes, so I did the following workflow using `magit`:
- git reset --soft HEAD^
- git stash 1/2 of the files changed
- re-run `nix-env -f ~/briefcase/emacs -i`
- restart X session
- If the problem persists, the bug exists in the non-stashed files. Repeat the
process until you find the bug.
In my case, the bug was pretty benign. Calling `(exwm/switch "Dotfiles")` at the
bottom of `window-manager.el` was failing because "Dotfiles" is the name of a
non-existent workspace; it should've been `(exwm/switch "Briefcase")`.
There may have been more problems. I changed a few other things along the way,
including exposing the env vars BRIEFCASE to `wpcarros-emacs` inside of
`emacs/default.nix`.
The important part is that this was a valuable learning opportunity, and I'm
glad that I'm walking away from the two days of "lost productivity" feeling
actually productive.
I'm using a Makefile until I can remember the command:
```shell
> nix-env -f . -i
```
This will install (i.e. `-i`) any derivations instantiated from the Nix
expression resolvable by `-f`. Ideally the incantation will look something like
this:
```shell
> nix-env -f '<universe>' -iA emacs
```
Informing `nix-env` to install all of the derivations created by the expression
at attribute `emacs` in my `<universe>` repository. For now two things are
preventing this:
1. `emacs` isn't an attribute in my top-level expression defined in the
`default.nix`.
2. If I do add `emacs` as an attribute and call the above command, my usage of
`readTree` results in `pkgs` missing `.lib` and a few other stdlib commands
that are available in `(import <nixpkgs> {})`.
A fix for both of these should be forthcoming.
At the moment, all of the Nix repositories that I'm consuming exist in ~. To
keep things consistent, I ran:
```shell
> hub clone nixos/nixpkgs ~/nixpkgs
```
When I first moved to London, I created common.txt to store the address of my
office, my temporary housing, my new phone number, and other information. It
serverd its purpose, but I no longer need it anymore.
bookmarks.txt started out as a dmenu/rofi -> google-chrome integration. This
predates EXWM, which has replaced this with a google-chrome.el module (or
something similarly named).
Manually merging:
- README.md: I added the description from universe/README.md into the heading of
dotfiles/README.md.
- .envrc: dotfiles/.envrc was a superset of universe/.envrc
- .gitignore: Adding some of the ignored patterns from universe/.gitignore to
dotfiles/.gitignore
Everything else here should be a simple rename.
I've been using Fish consistently for about a month now, and I don't see myself
switching back to ZSH. Some of the code from this commit should be published. I
may get around to that one day. Before I did that, I would need to clean it up
and document it, which I won't be doing today.
Thank you, ZSH, for your service.
I recently changed my hostname for my desktop and laptop from
wpcarro.lon.corp.google.com -> zeno.lon.corp.google.com
wpcarro2 -> seneca
If you're curious, the names Zeno and Seneca come from famous Stoic
philosophers. As you can see from this commit, my configuration depends on the
values of these hostnames.
Immediately impacted:
- .profile
- device.el
Not immediately impacted:
- configs/install
- configs/uninstall
- .ssh/config
- .zshrc*
* As a side note, I should stop supporting ZSH.
Using an .envrc file helps me DRY up some of my configuration. Ideally I should
only need to make changes to the .envrc file and then expect everything to work
as expected. Let's see how that goes.
The fact that this works is just an implementation-specific detail. In
theory, 'eq' will only compare object instance equality and not value.
Thanks to /u/patrec from HN for pointing this out.
--
8bdb2020150ed0fd4a4e520e454dc5f54e33f776 by Eric Fiselier <ericwf@google.com>:
Workaround bug in GCC 9.2 and after.
PiperOrigin-RevId: 291982551
--
47ff4820e595f96c082a90d733725f6882d83e3b by Abseil Team <absl-team@google.com>:
Improve ABSL_ATTRIBUTE_PACKED documentation
Recommend to apply ABSL_ATTRIBUTE_PACKED to structure members instead of to an entire structure because applying this attribute to an entire structure may cause the compiler to generate suboptimal code. It reduces the alignment of the data structure from a value larger than one to one. When applied to a structure, ABSL_ATTRIBUTE_PACKED reduces the alignment of a structure (alignof()) to 1. As a result, the compiler can no longer assume that e.g. uint32 members are aligned on a four byte boundary and hence is forced to use single-byte load and store instructions on CPU architectures that do not support non-aligned loads or stores.
PiperOrigin-RevId: 291977920
--
902b7a86f860da699d3a2e5c738be5ef73ede3b4 by Mark Barolak <mbar@google.com>:
Internal change
PiperOrigin-RevId: 291963048
--
bb3bd3247e376d53a3080b105f13ec7566d3ae50 by Abseil Team <absl-team@google.com>:
Support the C++17 insert_or_assign() API in btree_map.
PiperOrigin-RevId: 291945474
--
ff3b3cfcbbc64f086f95501f48d49426bcde356f by Gennadiy Rozental <rogeeff@google.com>:
Import of CCTZ from GitHub.
PiperOrigin-RevId: 291861110
--
fd465cd9cbbacd3962f67a7346d6462edaddd809 by Derek Mauro <dmauro@google.com>:
Add flaky=1 to beta_distribution_test.
PiperOrigin-RevId: 291757364
--
3603adfb59c4128c542b670952cce250d59e1f67 by Derek Mauro <dmauro@google.com>:
Separate the initialization of NumCPUs() and NominalCPUFrequency()
The OSS version of Abseil never needs to call NominalCPUFrequency().
In some configurations, initializing NominalCPUFrequency() requires
spending at least 3ms measuring the CPU frequency. By separating the
initialization from NumCPUs(), which is called in most configurations,
we can save at least 3ms of program startup time.
PiperOrigin-RevId: 291737273
--
bea9e4a6bff5a0351d340deab966641867e08c4d by Abseil Team <absl-team@google.com>:
Change the cmake library names not to have a redundant `absl_` prefix.
PiperOrigin-RevId: 291640501
--
501b602ef260cd7c8c527342581ceffb3c5b6d4c by Gennadiy Rozental <rogeeff@google.com>:
Introducing benchmark for absl::GetFlag.
PiperOrigin-RevId: 291433394
--
4eeaddc788da4b91c272a8adca77ca6dbbbc1d44 by Xiaoyi Zhang <zhangxy@google.com>:
fix: Add support for more ARM processors detection
Import of https://github.com/abseil/abseil-cpp/pull/608
PiperOrigin-RevId: 291420397
--
a3087a8e883c5d71de7d9bd4ec8f4db5142dfcf5 by Derek Mauro <dmauro@google.com>:
Removes the flaky raw_hash_set prefetch test
PiperOrigin-RevId: 291197079
--
aad6c2121c102ac36216e771c83227cf3e3bfd66 by Andy Soffer <asoffer@google.com>:
Enable building Abseil as a DLL.
This is currently experimental and unsupported.
This CL does a few things:
1. Adds the ABSL_DLL macro to any class holding a static data member, or to global constants in headers.
2. Adds a whitelist of all files in the DLL and all the build targets that are conglomerated into the DLL.
3. When BUILD_SHARED_LIBS is specified, any build target that would be in the DLL still exists, but we swap out all of it's dependencies so it just depends on abseil_dll
PiperOrigin-RevId: 291192055
--
5e888cd6f2a7722805d41f872108a03a84e421c7 by Mark Barolak <mbar@google.com>:
Move absl/strings/internal/escaping.{cc,h} into internal build targets.
This puts absl/strings/internal/escaping.h behind a whitelist and it also resolves https://github.com/abseil/abseil-cpp/issues/604.
PiperOrigin-RevId: 291173320
--
166836d24970da87587c1728036f53f05a28f0af by Eric Fiselier <ericwf@google.com>:
Internal Change.
PiperOrigin-RevId: 291012718
--
996ddb3dffda02440fa93f30ca5d71b14b688875 by Abseil Team <absl-team@google.com>:
Fix shared libraries log spam for built-in types in absl::GetFlag
PiperOrigin-RevId: 290772743
GitOrigin-RevId: 8bdb2020150ed0fd4a4e520e454dc5f54e33f776
Change-Id: I8bf2265dd14ebbace220a1b6b982bb5040ad2a26
Adding a README including my current method for deploying. See the README for
more details. All of this is quite virgin and as such is subject to change.
Using <depot>'s gemma project with `dockerTools.buildLayeredImage` because I
need access to a nix-packaged server and gemma is the first thing that comes to
mind.
I'm attempting to setup my blog using the following:
- Google Cloud Run: I whitelist a docker image that packages my application and
then Google runs it "statelessly" (i.e. without persistence). The stateless part
should be fine for the time being.
- Nix: Using `<nixpkgs>.dockerTools.buildLayeredImage` to output docker images
from Nix expressions.
- Docker: Upload the output image from the Nix expressions and upload it to
Google Container Registry from which it can be run from Google Cloud Run.
Some helpful commands:
```shell
> sudo gcloud auth login
> nix-build ./docker/cloud_run.nix
> sudo docker image import ./result
> sudo docker tag <name> gcr.io/<google-cloud-project-id>/<name>:<tag>
> sudo docker push gcr.io/<google-cloud-project-id>/<name>:<tag>
```
I'm unsure if Google Cloud Run is my desired end goal, but it may help me
publish a blog faster than setting up a Kubernetes cluster, which is what I'd
ultimately like to do. Cloud Run should be cheaper financially and time-wise.
A Poem:
I wanted to try out this package...
30 minutes later after a dozen failed attempts at packaging it...
I no longer want to try this package...
for now.
Update code that depends on my mono-repo being named "mono". I've renamed it to
"universe", which explains the changes in this commit.
TODO: Merge dotfiles into universe.
I'm having trouble debugging why `pgrep emacs` returns two PIDs instead of just
one. Additionally when I call `emacsclient .` on the command line, I see a
message...
"Waiting for Emacs..."
...but when I cycle through all of my workspaces, I don't see any active
buffers. This commit is part of a larger debugging effort to get this working as
expected.
The end goal is to have some functions that help me manage my Monzo and YNAB
accounts. YNAB (i.e. youneedabudget.com) doesn't support Monzo
integrations. However, both services offer APIs. Here I'm sketching ideas for
what the API integrations might look like. Coming soon: monzo.el.
Not adding it as a top-level dependency since maybe.el depends on on
prelude.el. This shouldn't be a circular dependency when the requirement happens
in the function's scope though.
Remove `dbus-launch` and prefer simply `exec emacs`. Add `--no-site-file` and
`--no-site-lisp` flags.
Temporarily disable `google-stuff.el` because it's unavailable with the
`--no-site-lisp` flag.
This should all be fixed when I fully nixify my Emacs.
Why?
- `company-mode` is too noisy in IRC buffers.
- `auto-fill-mode` inserts newline characters that end up each being their own
message, which means that I make more noise than I should in IRC.
Wrapping the `nix eval` incantation in a fish function for two reasons:
1. Document that this is how to evaluate Nix from a file.
2. Provide a more ergonomic way of evaluating Nix from a file.
This takes care of my outstanding TODO of understanding why something ivy was
being used and other times it wasn't. It turns out that there is a generic
`completing-read` function that many Emacs packages consume. `ivy-mode` ensures
that when that function is called it is used instead of the default Emacs
completing package.
I'm still unsure of the difference between ivy and counsel. My best guess
currently is that counsel is the narrowing framework and ivy is the integration
of the narrowing framework with `completing-read`. Swiper must be the
integration with incremental {forward,backward} search.
