Only show the chords that we can fit on the piano.
TODO: Debug occasional instance where we render chords that do not fit. I am
unsure how to reproduce these states at the moment.
While I did change a lot of functionality, I also ran `elm-format` across the
codebase, which makes these changes a bit noisy.
Here is the TL;DR:
- Properly support chord inversions
- Ensure that the piano styling changes dynamically when I change the variables
like `naturalWidth`
- Add start and end notes to define the size of the piano and which chords we
create
- Support elm-format and run it across entire project
- Debug Misc.comesBefore
- Introduce a ChordInspector and debugger
TODO: Ensure that we only generate chords where all of the notes can be rendered
on the displayed keys.
TODO: Add preferences panel, so that I can do things like "Practice blues chords
in C and E with chord substitutions."
Remodel application to support the scientific pitch notation for notes. Instead
of supporting simply "C", support "C4". This change created cascading
changes. After refactoring for around an hour, I restored the app to a working
state. The current state is not desirable, but it compiles. More changes on the
way.
Define two functions for attempting to return an element in a list that precedes
or succeeds another element.
I prefer having something like Utils.List. Perhaps I will refactor.
Using BPM as the unit for tempo.
TODO: Consider a higher-fidelity way to calculate BPM, although I'm not sure
this is critical functionality; an interesting problem is just seducing me, and
this app would be better off resisting the temptation.
Elm reminds me of Haskell. In fact, I'm using `haskell-mode` (for now) in Emacs
to write my Elm code, and it works reliably. I'm not writing a Haskell app, but
if I were, I would define my application Model with the following Haskell code:
```haskell
data Model = Model { whitelistedChords :: [Theory.Chord]
, selectedChord :: Theory.Chord
, isPaused :: Bool
, tempo :: Int
}
```
When I first modelled my application state, I did something similar. After
reading more Elm examples of SPAs, I see that people prefer using type aliases
to define records. As far as I know, you cannot do this in Haskell; I believe
all types are "tagged" (something about "nominal typing" comes to mind). Anyhow,
Elm isn't Haskell; Haskell has cool features like type classes; Elm has cool
features like human-readable error messages and exhaustiveness checking for
cases. I love Haskell, and I love Elm, and you didn't ask.
Anyhow, this commit refactors my records as type aliases instead of types. I
think the resulting code is more readable and ergonomic.
--
1eb20c4802ccaa316ecebc237877210b77ac84f7 by Abseil Team <absl-team@google.com>:
Use constraint_values to detect windows.
This resolves ambiguous copts when cross compiling with LLVM on Windows.
PiperOrigin-RevId: 305935379
--
47c96948132a577b14642ad4c910052768c41d62 by Abseil Team <absl-team@google.com>:
Add StrSplit conversion tests for the swisstable containers.
PiperOrigin-RevId: 305747160
--
0daea0f78b50d49520bd6e67d093cd87d057bb86 by Abseil Team <absl-team@google.com>:
Typo fix: Removes duplicate word.
PiperOrigin-RevId: 305502962
GitOrigin-RevId: 1eb20c4802ccaa316ecebc237877210b77ac84f7
Change-Id: I1bfa0beda0260027a22bc671344cc8b74315b77a
Create a more convincing representation of the piano.
I would like to compute the left-offset based on the naturalWidth. That change
is probably forthcoming.
First of all, Elm's purity is beautiful. I think every language should model
their error messages and develop experience after Elm. If I didn't have to
download packages, I don't think I would need an internet connection to
troubleshoot my program's errors. This is how helpful I find the compiler.
Now that that's out of the way, here's what I've changed since we've last
corresponded:
- Use Elm's Browser.element to create a reactive application with state
- Write a function to generate all of the chords about which CDS knows
- Move some code out of Main.elm into other modules
- Depend on List.Extra, Random, Random.Extra
What's left:
- Lots of work
- Instead of clicking a button to show a new chord, use a timer
- Add mobile-first styling (probably add TailwindCSS)
- Persist settings in LocalStorage (and then eventually create user accounts)
- Allow users to curate the list of chords they're interested in practicing
- Deploy the website and dogfood it
Unknowns:
- How can I handle tempo? I don't expect setInterval to be enough (maybe it
is)...
I think that glyphs look nice, but they subtley confuse Emacs's UI. In the case
of a two-character glyph condensing into one character's width, the fill-width
indicator -- correctly -- highlights the 81st character as red, but it looks
like it's erroneously highlighting the 80th.
Also when I want to create an anonymous function I type (), which condenses into
the unit character, and it's difficult to delete either the opening or the
closing parenthesis.
Overall I think glyphs are cute, but they're not worth the trouble.
Initialize an Elm application to build a MVP for the Chord Drill Sergeant
application. There isn't much to see at the moment. I'm just sketching
ideas. More forthcoming...
See the README for more context on typo-po.
I drank a strong cup of coffee this morning, and I cannot quiet the activity in
my head. I'm attempting to use READMEs in my //website/sandbox to track ideas
that I would typically track using my phone's notes application. Creating a
README forces me to write more than I may have written in my phone's
notes. Also, since this repository is available at https://git.wpcarro.dev, I
can share these ideas with friends by sending them a URL! So much for "stealth
mode"... Well I guess this stress-tests my theory that ideas are less important
than execution.
The install-multi-user script uses blue, green, and red colors, as
well as bold and underline, to add helpful formatting that helps
structure its rather voluminous output.
Unfortunately, the terminal escape sequences it uses are not quite
well-formed. The relevant information is all there, just obscured
by some extra noise, a leading parameter `38`. Empirically, the
result is:
* On macOS, in both Terminal.app and iTerm2, the spurious `38` is
ignored, the rest of the escape sequence is applied, and the colors
show up as intended.
* On Linux, in at least gnome-terminal and xterm, the spurious `38`
and the next parameter after it are ignored, and what's left is
applied. So in the sequence `38;4;32`, the 4 (underline) is
ignored but the 32 (green) takes effect; in a more typical sequence
like `38;34`, the 34 (blue) is ignored and nothing happens.
These codes are all unchanged since this script's origins as a
Darwin-only script -- so the fact that they work fine in common macOS
terminals goes some way to explain how the bug arose.
Happily, we can make the colors work as intended by just deleting the
extra `38;`. Tested in all four terminals mentioned above; the new
codes work correctly on all of them, and on the two macOS terminals
they work exactly the same as before.
---
In a bit more technical detail -- perhaps more than anyone, me
included, ever wanted to know, but now that I've gone and learned it
I'll write it down anyway :) -- here's what's happening in these codes:
An ECMA-48 "control sequence" begins with `\033[` aka "CSI", contains
any number of parameters as semicolon-separated decimal numbers (plus
sometimes other wrinkles), and ends with a byte from 0x40..0x7e. In
our case, with `m` aka "SGR", "Select Graphic Rendition".
An SGR control sequence `\033[...m` sets colors, fonts, text styles,
etc. In particular a parameter `31` means red, `32` green, `34` blue,
`4` underline, and `0` means reset to normal. Those are all we use.
There is also a `38`. This is used for setting colors too... but it
needs arguments. `38;5;nn` is color nn from a 256-color palette, and
`38;2;rr;gg;bb` has the given RGB values.
There is no meaning defined for `38;1` or `38;34` etc. On seeing a
parameter `38` followed by an unrecognized argument for it, apparently
some implementations (as seen on macOS) discard only the `38` and
others (as seen on Linux) discard the argument too before resuming.
(cherry picked from commit 7313aa267b5be1e5264e4577e7bc3daec2fef282)
The ssh client is lazily started by the first worker thread, that
requires a ssh connection. To avoid the ssh client to be killed, when
the worker process is stopped, do not set PR_SET_PDEATHSIG.
(cherry picked from commit 3e347220c82d1537723f49aa03a93a6f9d294417)
If the `throw` is reached, this means that execvp into `ssh` wasn’t
successful. We can hint at a usual problem, which is a missing `ssh`
executable.
Test with:
```
env PATH= ./result/bin/nix-copy-closure --builders '' unusedhost
```
and the bash version with
```
env PATH= ./result/bin/nix-copy-closure --builders '' localhost
```
(cherry picked from commit 38b29fb72ca4a07afbec1fd5067f59ca7d7f0fab)
Includes the expression of the condition in the assertion message if
the assertion failed, making assertions much easier to debug. eg.
error: assertion (withPython -> (python2Packages != null)) failed at pkgs/tools/security/nmap/default.nix:11:1
(cherry picked from commit 307bcb9a8e7a16bfc451e055a620b766df9d3f7d)
Signed-off-by: Domen Kožar <domen@dev.si>
When encountering an unsupported protocol, there's no need to retry.
Chances are, it won't suddenly be supported between retry attempts;
error instead. Otherwise, you see something like the following:
$ nix-env -i -f git://git@github.com/foo/bar
warning: unable to download 'git://git@github.com/foo/bar': Unsupported protocol (1); retrying in 335 ms
warning: unable to download 'git://git@github.com/foo/bar': Unsupported protocol (1); retrying in 604 ms
warning: unable to download 'git://git@github.com/foo/bar': Unsupported protocol (1); retrying in 1340 ms
warning: unable to download 'git://git@github.com/foo/bar': Unsupported protocol (1); retrying in 2685 ms
With this change, you now see:
$ nix-env -i -f git://git@github.com/foo/bar
error: unable to download 'git://git@github.com/foo/bar': Unsupported protocol (1)
(cherry picked from commit c976cb0b8ab5d0f2c4ab8c9826fc7db56e2f1b3e)
Signed-off-by: Domen Kožar <domen@dev.si>
--
c162645dba4de6f5f1c8b6e8a29a8da9f9e0aa52 by Derek Mauro <dmauro@google.com>:
Update linux_clang-latest container to one based on Ubuntu 18.04, which has libstdc++-8.
PiperOrigin-RevId: 305287658
GitOrigin-RevId: c162645dba4de6f5f1c8b6e8a29a8da9f9e0aa52
Change-Id: I3f31daf0d8c445008c78f0e10ae6af753cea756b
--
87cdfd6aa40941e116cd79ef70f9a7a8271db163 by Abseil Team <absl-team@google.com>:
Fix a typo in random.h API documentation.
PiperOrigin-RevId: 305176308
--
8a38e1df49a18a954daca3ce617fd69045ff4c19 by Derek Mauro <dmauro@google.com>:
Import GitHub #647: Allow external add_subdirectory for using GoogleTest
PiperOrigin-RevId: 305156797
--
b1a2441536d4964fbe4e2329e74c322e6c41a4e6 by Gennadiy Rozental <rogeeff@google.com>:
temporary roll back.
PiperOrigin-RevId: 305149619
--
c78767577264348d2f881893f9407aadfe73ab75 by CJ Johnson <johnsoncj@google.com>:
Rollback update to linux_clang-latest container while investigating
a compiler bug.
PiperOrigin-RevId: 304897689
--
3c6fd38f53d2e982569fdba4043f75271c7b5de4 by Derek Mauro <dmauro@google.com>:
Update linux_clang-latest container to one based on Ubuntu 18.04,
which has libstdc++-8.
PiperOrigin-RevId: 304885120
GitOrigin-RevId: 87cdfd6aa40941e116cd79ef70f9a7a8271db163
Change-Id: Iefa6efee93907ec0eecb8add804c5cc2f052b64d
After binary searching through my git history to restore my keyboard
functionality, I discovered the issue: I deleted the "Terminal" workspace, but I
did not remove the call to `(exwm/switch "Terminal")`, which silently prevented
EXWM from initializing.
I wish errors like this were noisier.
I created a google-stuff.el module months ago, but I have not needed to
use it much. Removing the google-stuff.el module and all of my
dependencies on it.
This value defaults to localhost:3000, which works, but then Gitea
renders "http://localhost:3000/wpcarro/briefcase" as the URL to clone my
briefcase repository.
