dkish was an idea to quickly create REPLs for all sorts of languages like
Haskell, Elixir, Clojure. I haven't used these, and if I started wanting these
with my newfound comfort with Nix, I think I'd reach for that instead.
I'm in the midst of transitioning onto a few new tools.
My previous workflow just used `nix-env` to install *some* packages. I didn't
have a prescribed methodology for which packages I would install using `nix-env`
and which ones I would install using `sudo apt-get install`. Sometimes if a
package would be available in my aptitude repositories, I'd use that; other
times when it wasn't available I'd use `nix-env`. One complication about being
on gLinux intead of NixOS is that some packages (e.g. nixpkgs.terminator) is
available via `nix-env -iA nixpkgs.terminator`, but the installation won't
actually run on my gLinux. In these instances, I would install terminator from
the aptitude repositories.
Then @tazjin introduced me to his Emacs configuration that he builds using
Nix. What appealed to me about his built Emacs is that it worked as expected on
either a NixOS machine and on gLinux (and presumably on other non-NixOS machines
as well).
A setup towards which I'm working is to own one or a few NixOS machines whose
configurations are entirely managed with Nix. On devices like my work machines,
which cannot run NixOS, I can build as much of the software that I need using
Nix and attempt to minimize the ad hoc configuration either with shell scripts,
python, golang, or more Nix code... it's clear that I still don't have a clear
idea of how that part will work.
For now, I'm adopting nix, nix-env, lorri, direnv, and weening off of aptitude
as much as I can. Things are a bit messy, but my general trend feels
positive. Stay tuned for more updates.
From what I currently understand, lorri is a tool (sponsored by Target) that
uses nix and direnv to build and switch between environments quickly and
easily.
When you run `lorri init` inside of a directory, lorri creates a shell.nix and
an .envrc file. The .envrc file calls `eval "$(lorri direnv)"` and the shell.nix
calls `<nixpkgs>.mkShell`, which creates a shell environment exposing
dependencies on $PATH and environment variables. lorri uses direnv to ensure
that $PATH and the environment variables are available depending on your CWD.
lorri becomes especially powerful because of Emacs's `direnv-mode`, which
ensures that Emacs buffers can access anything exposed by direnv as well.
I still need to learn more about how lorri works and how it will affect my
workflow, but I'm enjoying what I've seen thus far, and I'm optimistic about the
road ahead.
actors.go is my attempt to better understand golang's channels. I'm mapping my
understanding of concurrency from my experience with Elixir / Erlang and actors
onto golang until I have more opinions.
Since I did not pass my one-site interview with DM, but I have been invited to
attempt again, I decided to partition this directory into two parts:
1. part_one: Hosting the exercises that I completed before my first attempt at
earning the job.
2. part_two: Hosting the exercise that I will complete before my second attempt
at earning the job.
After some toil and lots of learning, monzo_ynab is receiving access and refresh
tokens from Monzo. I can now use these tokens to fetch my transactions from the
past 24 hours and then forward them along to YNAB.
If YNAB's API requires OAuth 2.0 login flow for authorization, I should be able
to set that up in about an hour, which would be much faster than it took me to
setup the login flow for Monzo. Learning can be a powerful thing.
See the TODOs scattered around for a general idea of some (but not all) of the
work that remains.
TL;DR
- Package monzo_ynab with buildGo
- Move some utility functions to sibling packages
- Add a README with a project overview, installation instructions, and a brief
note about my ideas for deployment
Note: I have some outstanding questions about how to manage state in Go. Should
I use channels? Should I use a library? Are top-level variables enough? Answers
to some or all of these questions and more coming soon...
I discovered direnv's convenient `source_up` function today. I needed it to
inherit the values defined in ~/briefcase/.envrc, and it's working exactly as I
expected it would. What a fine piece of software direnv is.
--
dea3e4f33f16bdb1d89cad1f8055b81c0c0cb554 by Andy Getzendanner <durandal@google.com>:
Validate in log_severity_test that flags of type absl::LogSeverity are lock-free.
PiperOrigin-RevId: 293454285
--
2a0cd2d8dc193a0cbff4ffa6c5c7037745507419 by Derek Mauro <dmauro@google.com>:
Update the testing instructions in CONTRIBUTING.md
PiperOrigin-RevId: 293436013
--
cec91c3f635b0b4c8a60955e5926dba4ed980898 by Gennadiy Rozental <rogeeff@google.com>:
Introduce struct to represent storage for flag value and normalize naming of internal structs in Flag implementation.
There is no semantic changes in this CL. All the internal structs are now named as Flag... We also stop using flags_internal:: qualifications for most of them since the names are unique enough by themselves.
PiperOrigin-RevId: 293251467
GitOrigin-RevId: dea3e4f33f16bdb1d89cad1f8055b81c0c0cb554
Change-Id: I161aecc9509edae3e4b77eead02df684b2ce7087
I'm now pulling the authorization code off of Monzo's request to my redirect
URI. I intend to use exchange that code for an access and refresh token. Once I
have these two items, I should be able to interact with Monzo's API much more
easily.
- Prefer goimports to gofmt. goimports calls gofmt; it also adds and removes
dependencies.
- Assert the presence of goimports, godoc, godef
- KBD godef to M-.
- Support the M-x compile command for calling `go build -v`
Support a Mercurial alias for listing the files that have changed on a
particular branch.
This commit is particularly noisy because I reformatted the above aliases to
align with the new width.
What's done:
- Basic support of the client authorization grant stage of the OAuth login
flow:
- Open Google Chrome to point the user to Monzo's client authorization page.
- Created a web server to retrieve the authorization code from Monzo.
What's left:
- Pulling the authorization grant (i.e. code) from Monzo's request and
exchanging it for an access token and a refresh token, which can be used to
make subsequent requests.
Unanswered question:
- Assuming this is a stateless app, where should I store the access token and
refresh token to avoid the authorization flow. I'd like to avoid the client
authorization flow because ideally I could run this app as a job that runs
periodically throughout the day without requiring my interactions with it.
Some interesting notes:
- Notice how in the .envrc file, it's possible to make calls to `pass`. This
allows me to check in the .envrc files without obscuring their content. It
also allows me to consume these values in my app by using
`os.Getenv("client_secret")`, which I find straightforward. Overall, I'm quite
pleased to have stumbled upon this pattern - assuming that it's secure.
--
1bc4d36e13fb9175ea8cdaa00213aa9d4417c669 by Andy Getzendanner <durandal@google.com>:
Fix pointer format specifier in documentation
Import of https://github.com/abseil/abseil-cpp/pull/614
PiperOrigin-RevId: 293227540
--
c7b43b30493c4fb5f2ec3264672b08bfe1ea3709 by Abseil Team <absl-team@google.com>:
Internal change.
PiperOrigin-RevId: 293160245
--
64439365e2b4a0b5e51ae0a7dafdb15912402dfd by Shahriar Rouf <nafi@google.com>:
Add benchmarks for string_view: BM_CompareFirstOneLess and BM_CompareSecondOneLess.
PiperOrigin-RevId: 293031676
--
b273b420cab24a6e3f487430987e09f4eb1caec4 by Greg Falcon <gfalcon@google.com>:
Remove an unreachable line from charconv.cc.
Fixes github issue #613.
PiperOrigin-RevId: 292980167
--
70babb5f7a3d9fdd00a2b3085c3c2b9fe0265c79 by Gennadiy Rozental <rogeeff@google.com>:
Move GetFlag implementation into FlagImpl.
This change will allow us to hide details of GetFlag overloads inside implementation detais. Eventually we'll migrate to a different implementation. No semantic changes in this CL.
PiperOrigin-RevId: 292930847
--
94bee7b7cc31e0167ee4b953281c1e78c96a574a by Abseil Team <absl-team@google.com>:
Clarification in absl::Exponential documentation.
PiperOrigin-RevId: 292912672
--
d6916d30c5c1d3ee9ae46d69ec0a166a760c99c7 by Derek Mauro <dmauro@google.com>:
Make AtomicHook constant-initializable on Clang for Windows.
Only mark AtomicHook as constant-initializable on platforms where it
is actually constant-initializable.
PiperOrigin-RevId: 292655939
GitOrigin-RevId: 1bc4d36e13fb9175ea8cdaa00213aa9d4417c669
Change-Id: I090b231a0ca0d92868e494ab5b3fa86c902889d5
I mistakenly mapped one of my dual-function keys on my Ergodox to send Shift+CMD
instead of CMD. When some of my Emacs keybindings weren't firing, I noticed that
the key event they received was some like `C-S-s-<char>` instead of say
`C-s-<char>`. As a quick fix, I duplicated each of my keybindings that relied on
the CMD key to support Shift+CMD as well until I remapped the key on my
Ergodox. This morning, I remapped the Shift+CMD key to CMD, so I'm bidding adieu
to this code.
Today I learned that you can email your Kindle files to read them using the
paperwhite display. I'm attempting to read RFCs, so after reading 1/4 of the way
through RFC6479 (on OAuth2.0), I realized that it might be easier to read on my
Kindle instead of on my computer screen. Out of this, rfcToKindle.go was born.
I'm not sure if I'd like to publish this or not.
Press `<M-escape.` to display a list of buffers hosting X applications. Use
`completing-read` to select and focus one of these.
See the function docs and TODOs for more information.
Currently, after I connect my monitor to my laptop, I run `display/enable-4k`,
which will use `xrandr` to enable the display. The scaling of the enabled
display is not what I expect. So I've habituated re-running the same function,
`display/enable-4k`, which scales the display and meets my expectations.
What's strange is that if instead of running `display/enable-4k` the first time
from Emacs, I call `xrandr ...` from a terminal, this enables the display and
scales it properly on the first invocation.
I'm unsure how to explain this behavior. It's possible that a environment
variable is set properly in the terminal that isn't set in my Emacs, but this is
just a guess.
I'm going to using a different invocation in display.el that explicitly passes
the monitors dimensions. Let's see if that works.
I'm currently quite unfamiliar with golang. As an exercise to help me onboard
onto golang, and as a proof-of-concept to see if golang is a viable substitute
for Python as a scripting language, I decided to port my delete_dotfile_symlinks
to golang.
In the process, renamed ./python -> ./scripts, which is a more accommodating
name for a directory.
* exwm-systemtray.el (exwm-systemtray-background-color): New user
option for configuring systemtray background color.
(exwm-systemtray--init): Configure background color for systemtray.
* exwm-core.el (exwm--color->pixel): New function for converting color
to TrueColor pixel.
* exwm-floating.el (exwm-floating--border-pixel)
(exwm-floating--border-colormap, exwm-floating--init-border): Removed.
(exwm-floating-border-color, exwm-floating--set-floating): Use
`exwm--color->pixel' and only support TrueColor.
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.
