Getting some practice with Python's heapq module (which I'm unsure if I used
correctly) to do a priority-first-traversal of a graph: known as Dijkstra's
algorithm.
Solves the InterviewCake.com problem that asks us to write a function that
returns the number, y, that occurs twice in a list, xs, where xs is an unsorted
list of integers from 1..n with a length of n + 1.
This is just a small org table that I created to help me
Fun fact: In Emacs, you can insert literal TAB character by pressing `C-q
TAB`. For creating tables, using TAB characters feels perfectly
acceptable. Perhaps the TAB name comes from TABle.
Solves an InterviewCake.com problem that returns the index of the element in a
list that should be the first element in that list. It's an exercise that's
useful for seeing other applications of a binary search.
Solves an InterviewCake.com problem that returns all of the permutations of a
string input. The problem states that it's acceptable to assume that your input
string will not have repeated characters, which is why using a Set is
acceptable. I like this solution because it builds a permutations tree and then
assembles all of the permutations by doing a DFT over that tree.
This removes the ASDF system definition for Gemma and switches the
code over to buildLisp.
The program builds (including some terrifying hacks to get the
frontend to work), but there are some bizarre runtime issues that I
need to debug.
--
c42a234e2c186bf697ce8d77e85628601fa514a6 by Abseil Team <absl-team@google.com>:
Enable the assertion in the iterator's operator++
PiperOrigin-RevId: 290134813
--
f8c53ba8e9c5bb16bbcc1e412a5c2519c912c83e by Abseil Team <absl-team@google.com>:
Define operator== and operator!= for absl::{weak,strong}_equality and
absl::{partial,weak,strong}_ordering types themselves.
PiperOrigin-RevId: 290111564
--
36bc574090cefad74a451719ce2761982647a51d by Tom Manshreck <shreck@google.com>:
Specify Time library flag formats
PiperOrigin-RevId: 289928010
--
26dd40281add260baab2b60fec05dfb9c5304aaa by Mark Barolak <mbar@google.com>:
Delete an extraneous forward declaration of absl::Cord.
PiperOrigin-RevId: 289708481
--
e60aea7f33554ff66d7699bb70e7af1d26323f1d by Abseil Team <absl-team@google.com>:
Release b-tree benchmarks.
PiperOrigin-RevId: 289654429
--
660aa83fa000d4bae072b2d1c790f81d0939bc7e by Greg Falcon <gfalcon@google.com>:
Use https links.
Import of https://github.com/abseil/abseil-cpp/pull/586
PiperOrigin-RevId: 289479559
--
0611ea4482dcf23d6b0a0389fe041eeb9052449a by Derek Mauro <dmauro@google.com>:
Removes the static initializer for LookupTables<absl::uint128>::kVmaxOverBase
Uses template specialization to hard code the resulting array.
Static initializers are problematic for a number of reasons. Not only
are they responsible for the static initialization order fiasco, but
they are in the critical path during program startup. For these
reasons, the Google C++ style guide strongly discourages them (and
forbids them when they are not trivially destructible), and Chromium
even has a test forbidding them.
https://google.github.io/styleguide/cppguide.html#Static_and_Global_Variableshttps://chromium.googlesource.com/chromium/src.git/+/master/docs/static_initializers.mdhttp://neugierig.org/software/chromium/notes/2011/08/static-initializers.html
PiperOrigin-RevId: 289458677
--
c869362f6bb7a872314f74750d38d81bdaa73f95 by Greg Falcon <gfalcon@google.com>:
Step 2 of 2 to fix our CCTZ fork to respect inline namespaces.
Re-import of CCTZ from GitHub, applying new changes to honor Abseil's optional inline namespace in MSVC.
PiperOrigin-RevId: 289454407
--
fdb3474d76c2ee0371ccdf7593a78137c03a3f58 by Greg Falcon <gfalcon@google.com>:
Step 1 of 2 to fix our CCTZ fork to respect inline namespaces.
CCTZ uses a linker flag to simulate weak symbol support in MSVC. This takes the form of a #pragma that includes the mangled names of two types: the symbol to treat as weak, and the symbol to use as its default value if no override is provided.
When Abseil is configured to use inline namespaces, the mangled names of these symbols change, and the pragma should change to reflect that. Fortunately for us, MSVC name mangling is simple enough that we can generate the needed string literals in the preprocessor.
This CL introduces the new macros; the uses will be introduced in a follow-up CL.
PiperOrigin-RevId: 289435599
--
5f152cc36f008acb9ab78f30b5efa40ebaf2754b by Matt Kulukundis <kfm@google.com>:
Improve documentation for lazy_emplace
PiperOrigin-RevId: 289333112
GitOrigin-RevId: c42a234e2c186bf697ce8d77e85628601fa514a6
Change-Id: I139ce6c7044a70d083af53e428bcb987f0fd88c6
This was a bit of an oversight initially - we should be storing the
positions that the character has seen *on the level*, rather than on the
entire game state, for obvious reasons. This introduces a GameLevel
record, which has this field, the entities, and also the up staircase
position, which we can *also* use to position the character after going
down to a level we've already visited.
New levels need to go at the *end* of the list of levels, not the
beginning - otherwise we jump to the proper position on the new level
but the current level stays the same (oops).
Cheddar now needs to be passed the --about-filter flag to toggle the
behaviour for rendering Markdown into HTML.
By default Markdown will be highlighted like normal source code (i.e.
cgit source-filtering is the default behaviour).
Per https://github.com/noinia/hgeometry/issues/28, occasionally
DelaunayTriangulation.DivideAndConquer loops infinitely - in this case,
I was able to consistently use the seed 127624940715530481, to generate
a dungeon which had the following room centroids:
[ Point2 [38.5,3.5] :+ 0
, Point2 [67.0,33.0] :+ 1
, Point2 [46.0,45.5] :+ 2
, Point2 [55.5,42.0] :+ 3
, Point2 [36.0,25.0] :+ 4
, Point2 [76.5,12.0] :+ 5
, Point2 [29.0,26.5] :+ 6
, Point2 [55.0,10.5] :+ 7
]
and cause delaunay triangulation to loop indefinitely (or at least
longer than I cared to wait for). Given the size of our graphs switching
to naive generation should be fine performance-wise, and avoids the
infinite loop.
This advice is potentially defined before the autoloads for telega
have run, which means that the macro-expansion fails and
`telega-ins-fmt` is looked up as a function.
With this setup the initialisation works as expected.
Some more pains of weening off of Dropbox is that my Emacs initialization is
sensitive to dependencies and missing require statements. I'm still debugging
everything.
Some modules called `exwm-input-set-key` before the `window-manager` module
loaded, which itself requires EXWM. This broke initialization. To get around
this I could've called `(require 'exwm)` in each of those modules. I chose to
define a `keybindings.el` module to whitelist some of my EXWM keybindings. I'm
not sure if this is the best way forward, but it is *some* way forward.
Since the tokenizing isn't working as expected, my keyboard.el function
keyboard/swap-caps-lock-and-escape was silenting failing.
I'm adding a prelude/refute in that function to make the failures noisy until
the tokenizing is properly supported.
