This nginx does not currently log access correctly because for some
impenetrable reason (as is tradition), neither /dev/stdout nor
/dev/fd/1 exist for nginx at runtime. This is probably systemd's
doing, but I'll debug it later.
--
daa829a331a2316713681b5fe7630d1951e0fdec by Gennadiy Rozental <rogeeff@google.com>:
Eliminate Flag's destroy method.
The Abseil Flags are never destroyed. The only place where Destroy method was invoked was in some obscure place during flag registration, where we faces with duplicate retired flag registration. Regired Flag destruction is empty anyway. so we can just delete the duplicate object. The FLagImpl::Destroy is never invoked.
PiperOrigin-RevId: 294472413
--
3c159499ccde8ccdd6907b3a1ddb26be7d3f016f by Abseil Team <absl-team@google.com>:
Internal change.
PiperOrigin-RevId: 294401573
--
25910db425c50d9b9a8f8275af5a67c2935934fd by Shahriar Rouf <nafi@google.com>:
Optimize absl::string_view::compare.
Motivation: https://godbolt.org/z/Uz8DWV
PiperOrigin-RevId: 294286196
GitOrigin-RevId: daa829a331a2316713681b5fe7630d1951e0fdec
Change-Id: I818dad27ac5eb61bb7632e01224953cd882803bf
I was a bit weaker than I expected to be in my most recent interview using
TypeScript. To improve, I think I'd like to attempt solving some of the
InterviewCake.com questions using TypeScript.
If you've read the previous commits, the inspiration for `run` arose because I
need to call `npx ts-code <file>`, which is easy enough to remember, but I'd
still rather just call `run <file>`.
I'd like to be able to just call `run file.py` and have a program DWIM. I'm
working on run as a step in this direction. Define a simple configuration that
maps file extensions to template strings where "$file" is replaced with the
argv[1].
It basically works but there are outstanding TODOs. See the README and source
code for more information.
Supporting a function that resolves a file name checking for the nearest
occurrence of the file from the CWD until it traverses beyond the user's home
directory, after which point it checks in backupPaths.
Today when I opened my laptop, I wasn't sure if it was powered off or on because
the display was blank. Thankfully the volume was muted and the LED indicator was
on, which informed me that the laptop was powered on. This saved me from
unnecessarily rebooting.
What happened was that last night I was working from home and using my external
monitor. Usually I enable my external display and disable my laptop display. But
when I left for work this morning, I unplugged the HDMI cable from my laptop
without disabling the external display or enabling the laptop display.
I noticed a XF86 button on my laptop entitled XF86Display. I figured that this
could be a nice place to bind a key to toggle my laptop display on or off. At
the last minute, I had the idea to just cycle through all possible display
configurations that I use; there are only three anyways. When dealing with more
than two states, I realized I should use a cycle to model the configuration
states. Now I'm thinking that I should be using cycles to model toggles as well
- instead of just using a top-level variable that I `setq` over. I haven't
refactored existing toggles to be cycles, but I am excited about this new
keybinding.
This commit additionally:
- Moves keybindings out of display.el and into keybindings.el
- Conditionally sets KBDs if using work laptop
When I ran `pass show some/password`, gpg, which uses pinentry would start its
ncurses password prompt. For many this wouldn't be a problem but my current
vterm version cannot send the <return> key to ncurses, so once that prompt
appears, I cannot get rid of it without C-c and killing the shell. For a day or
more I just opened suffered through this.
Today I dug more into the issue and when I ran `pinentry --version` it warned
that it couldn't connect to DBUS. After searching for more information on this,
people with similar issues recommended starting their window managers with
`dbus-launch`. I previously started Emacs with `dbus-launch`, but only because
some i3 documentation told me to do so and I just copied them. Then I switched
to EXWM and copied that pattern over. A friend of mine uses EXWM and starts his
without calling `dbus-launch` but `exec emacs`. I mirrored this thinking that I
no longer needed `dbus-launch`. What I didn't know, however, was that this
friend was using a Nix-built Emacs (like me) except that his wrapped a native
Emacs installation while mine doesn't. His natively wrapped Emacs installation
has the proper variables set to interact with dbus and other important Linuxy
things that I don't fully understand. Since I'm using a Nix-built Emacs, some of
my variables are unset or set to different values than programs expect. This is
why when I try and start `gnome-terminal` or `terminator`, they refuse to start
and warn about many unset or incorrectly variables and not being able to bind to
sockets, etc.
This change reverts back to using `dbus-launch` until I have a better
understanding of Linux, Nix, etc.
--
803abc2dcad8b2354c988e9bf58dac4a17683832 by Gennadiy Rozental <rogeeff@google.com>:
Avoid warning when RTTI is not enabled.
PiperOrigin-RevId: 294247546
--
5a7b0b4d07d1d6e56fbb0b0ffbf4f8fcab772dbf by Derek Mauro <dmauro@google.com>:
Add a public Abseil FAQ
PiperOrigin-RevId: 294226960
--
6945c4a6df7d7679711fea31aacf4fba6ac7baa1 by Gennadiy Rozental <rogeeff@google.com>:
Re-enable type mismatch check, which works in all the cases including shared libraries.
We will use RTTI in case when our hand written approximation of it reports a type mismatch. This way we can ensure that if a flag is defined in one shared object and referenced in another we do not report spurious errors.
PiperOrigin-RevId: 293905563
GitOrigin-RevId: 803abc2dcad8b2354c988e9bf58dac4a17683832
Change-Id: I1a23776d227ed2734c2e7183323786b7a95c3cc7
Grouping entries by country and sorting according to Done -> Todo.
I should consider sorting the country groups alphabetically by the country name
and then each entry alphabetically by its city name.
Right now, however, this isn't a priority.
In 2013, I lived in Grenoble with a host family. During that time, I visited
Lyons, as well as a few other locations that aren't tracked by this document at
the time of this writing.
I spent two weeks on the Spanish islands of Ibiza and Formentera over the
summer.
I went to Hamburg twice to visit Mimi's family - once in the summer; once for
Christmas.
In the Fall, I went to Bordeaux with Mimi where we stayed at a charming Airbnb.
I spent New Years Eve in Amsterdam with Matty, Ryan, and Conor.
I may be missing a few other places that I visited in 2019; it was an active
year.
Without these KBDs, C-k kills buffers. As an evil-mode user, I expect C-k to
move upwards. As such, adding the `ivy-switch-buffer-map` to my existing ivy
KBDs that handle a similar use-case.
Note: I'm unsure why the KBDs in evil-collection didn't cover this.
- Move state "gen server" to the top of main/0
- Initialize it as empty
- Ensure that persistTokens/2 is called whenever the state changes
- Support setState/2 (similar in spirit to getState/0)
Problem:
When SIGINT signals we're sent to the token server, it would shut down without
completing the shutdown procedure. The shutdown procedure would persist the
application state (i.e. access and refresh tokens).
This is problematic for the following sequence of events:
t0. Access and refresh tokens retrieved from kv.json and used as app state.
t1. Tokens are refreshed but not persisted. (I'm still unsure how this
happens). Remember that this means the previous access and refresh tokens
from t0 are now invalid.
t2. User sends a SIGINT.
t3. Token server shuts down.
t4. Token server is restarted, kv.json is used as the app state even though its
tokens are now invalid.
t5. Tokens are attempted to refresh, Monzo API rejects the tokens because
they're invalid.
Now we need to provide the token server with valid access and refresh tokens
otherwise we will repeat the loop described above. This means going through the
client authorization flow again or copying and pasting the tokens logged from
the token server into kv.json. Either scenario is more manual than I'd prefer.
Solution:
Use a buffered channel to receive the os.Signal. I got this idea after reading
these docs: https://golang.org/pkg/os/signal/#Notify and I debugged this issue
shortly thereafter.
I also rearranged the order of operations in main/0 to ensure that
handleInterrupts/0, which registers the event listeners, occurs before
scheduleTokenRefresh/2 is called. This allows the token server to gracefully
shutdown even if it's in the middle of the scheduleTokenRefresh/2 call.
Consume the newly relocated auth package.
Additionally:
- Debugged error where JSON was properly decoding but not populating the
refreshTokenResponse struct, so my application was signaling false positive
messages about token refresh events.
- Logging more often and more data to help my troubleshooting
- Refreshing tokens as soon as the app starts just to be safe
- Clean up the code in general
Relocated the logic for authorizing clients into a separate package that the
tokens server now depends on. Moving this helped me separate concerns. I removed
a few top-level variables and tried to write more pure versions of the
authorization functions to avoid leaking Monzo-specific details.
I'm writing sensitive data here, so I'd like to ignore it instead of encrypting
it and publishing it. Perhaps later on, I can extend the key-value store to
handle encryption and decryption but that feels like overkill for now.
Attempting to read the persisted tokens from the key-value store when the server
begins. The server currently fails when those values are empty.
TODO
- Consider adding logic for knowing if the cached tokens are expired and prompt
the user to reauthorize the client using a web browser.
- Created a gopkgs directory and registered it with default.nix's readTree
- Moved monzo_ynab/utils -> gopkgs
- Consumed utils.go in main.go
- Renamed monzo_ynab -> job
In order to persist my access and refresh tokens, I needed a store. I think
using a database like SQLite may have been fine for this but was heavier weight
than what I wanted.
I decided to write a simple key-value store when the state is encoded and JSON
in a file called kv.json.
TODO:
- Support field nesting
- Support better error handling
- Support parameterizing the store path (i.e. ./kv.json)