.plan

TIL: Google Chrome sync does not natively support setting different default fonts for different OSes!

What if you want to use different default fonts on Mac OS and Windows with the same account?

You have two options:

1. Inject custom JavaScript / CSS into each and every page, and override typography rules to match your taste
2. Switch from _full_ to _custom_ sync, and opt out of "Settings" sync (that's what I ended up doing)

I initially toyed with (1) for a bit, but I soon realize things will get unwieldy pretty easily; on top of that, if you add that I would need to find a way to sync this script across my browsers, I figured I might as easily get the job done by opting for (2) instead.

For posterity, this is the [Violentmonkey](https://violentmonkey.github.io/) user-script that Claude Sonnet helped me put together; it kinda works, except:

- It fails to override CSS rules like: `font-family: serif`; it will render using the browser defined Serif font, and not the override of my like
- If fails to override CSS rules like: `font-family: initial`; again, it will render using the browser fonts, and not the custom overrides

Anyways, there you go...

TIL: [Kamal](https://kamal-deploy.org/) "Assets Bridging", or "Old assets -> New container / New assets -> Old container"

- When deploying a new version of the app, there will be a small window of time in which both the old and the new version of the app will be running at the same time, and the app proxy might forward requests to either one, randomly
- What if the old version receives a request for a new asset or vice-versa?  Clients will see a bunch of 404s!
- The solution: copy the old assets and the new assets in a local directory, and then volume-mount that into the app container

References:

- [Donal McBreen - Kamal 2.0: Deploy web apps anywhere - Rails World 2024](https://www.youtube.com/watch?v=rne8OoabiC8)
- [Kamal > Configuration > Asset path](https://kamal-deploy.org/docs/configuration/overview/#asset-path)

  > ## The Problem with Threads
  >
  > ### Key Points:
  > - **Threads** (specifically shared-state multithreading) complicate local reasoning, which is essential for correct software development.
  > - **Local reasoning** allows understanding a routine's behavior by examining it in isolation, but threads require considering every possible execution order, increasing complexity exponentially.
  >
  > ### The Issue with Local Reasoning:
  > - Nonconcurrent systems allow imagining state changes straightforwardly.
  > - Concurrent systems, especially with threads, require understanding interactions with all possible callers and shared states.
  >
  > ### Arguments Against Threads:
  > - **Combinatorial Complexity**: Threads create an exponential increase in complexity due to potential interleaving of instructions.
  > - **Error-prone**: It’s challenging to track where shared state may lead to bugs.
  > - **Cognitive Load**: Human minds can handle limited concurrent interactions, making thread management even harder.
  >
  > ### Common Counterarguments:
  > - **Mutexes**: While mutexes can help, they introduce their own complexities and don't eliminate the fundamental issues.
  > - **Practicality**: Despite the theoretical problems, threads can work in practice due to other simplifications in real-world scenarios.
  >
  > ## Alternatives to Threads
  >
  > ### Suggested Approaches:
  > 1. **Straight Callbacks**: Twisted’s IProtocol, JavaScript’s on<foo> idiom.
  > 2. **Managed Callbacks/Futures**: Twisted’s Deferred, JavaScript’s Promises/A[+].
  > 3. **Explicit Coroutines**: Twisted’s @inlineCallbacks, C#’s async/await.
  > 4. **Implicit Coroutines (Not Recommended)**: Green threads, eventlet, gevent.
  >
  > ### Advantages of Explicit Coroutines:
  > - **Visibility**: Explicit yield points in the code make concurrency visible and manageable.
  > - **Local Reasoning**: Easier to reason about concurrency as potential yield points are clear.
  > - **Easier Debugging**: Knowing where a routine might yield helps in understanding and debugging the code.
  >
  > ## Real-World Examples
  >
  > ### Twisted Reality:
  > - A bug involving a mechanical cockroach in a multithreaded game highlighted the difficulties of tracking concurrency issues.
  > - Rewriting the system using an event-driven approach (Twisted) eliminated the bug, demonstrating the practical benefits.
  >
  > ### Theoretical Example:
  > - **Transfer Function**: Demonstrates the potential concurrency issues in a simple payment transfer routine.
  > - **Explicit Concurrency Management**: Using `yield from` in coroutines helps in managing concurrency and makes potential issues visible.
  >
  > ## Conclusion
  >
  > ### Main Takeaways:
  > - **Threads vs. Microthreads**: Both suffer from similar problems regarding concurrency, making them challenging to manage.
  > - **Explicit Concurrency**: Emphasizes the importance of visible and manageable concurrency through explicit coroutines.
  > - **No Shortcuts**: Achieving correct concurrent behavior is inherently difficult and requires careful management, not just better threading models.
  >
  > ### Final Thought:
  > - **Supple Code**: Like the reed bending in the storm, programs should yield gracefully under concurrency pressures to avoid breaking like the rigid oak.

  > ## Overview
  > This blog post, part of a series on concurrency, parallelism, and asynchronous programming in Ruby, discusses the concept of "colorless" methods in Ruby. This means that in Ruby, there is no syntactic difference between synchronous and asynchronous methods, simplifying concurrent programming.
  >
  > ## Function Colors
  > - **Function colors**: Refers to distinguishing between synchronous (blue) and asynchronous (red) functions, a concept highlighted by Bob Nystrom in the context of JavaScript.
  > - **JavaScript's evolution**: Initially relied on callbacks (callback hell), then moved to Promises, and finally to async/await, each step making asynchronous code somewhat easier but still maintaining a distinction between sync and async functions.
  >
  > ## Ruby's Colorlessness
  > - **Unified syntax**: In Ruby, methods for blocking operations (like file reads, HTTP requests, etc.) look identical to their non-blocking counterparts.
  > - **Threads and Fibers**: Ruby achieves colorlessness by using Threads and Fibers, which allow independent call stacks that can be switched between, enabling concurrent execution without needing to distinguish between sync and async code.
  >
  > ## Concurrency Layers in Ruby
  > - **Nesting doll model**: Ruby’s concurrency model is layered like nesting dolls, with each layer providing different levels of concurrency:
  >   - **Processes**: Independent instances of Ruby, running in isolated memory spaces.
  >   - **Ractors**: Ruby’s actors that can run in parallel, designed for message-passing concurrency.
  >   - **Threads**: OS-level threads sharing the same memory space, capable of parallelizing blocking operations.
  >   - **Fibers**: Lightweight, cooperative concurrency within threads, enhanced by the FiberScheduler in Ruby 3.
  >
  > ## Concurrent, Colorless Programming
  > - **Examples**: Demonstrates concurrent HTTP requests using Threads and Fibers, showing how Ruby can handle blocking operations in parallel without changing the method calls.
  > - **Concurrency vs. Parallelism**: Concurrency is about managing multiple tasks at once, while parallelism is about executing tasks simultaneously. Ruby threads and fibers achieve concurrency, allowing tasks to be interleaved efficiently.
  >
  > ## Practical Implications
  > - **Web and job servers**: Ruby’s colorless concurrency model powers threaded and fibered web servers (like Puma and Falcon) and job servers (like Sidekiq and GoodJob), enabling efficient handling of blocking operations.
  > - **Historical context**: Ruby had its callback phase (via EventMachine) similar to early JavaScript, but moved towards a more seamless concurrency model with threads and fibers.
  >
  > ## Conclusion
  > The post concludes by noting that the understanding of Ruby’s concurrency model will deepen in subsequent parts of the series, starting with an in-depth look at Threads.

Prevent layout shifts when body becomes scrollable

(The above notes were ripped from this nicely written post: [React: Preventing Layout Shifts When Body Becomes Scrollable](https://maxschmitt.me/posts/react-prevent-layout-shift-body-scrollable/))

Use [`scrollbar-gutter`](https://developer.mozilla.org/en-US/docs/Web/CSS/scrollbar-gutter).  However, if Safari / iOS support is paramount for your business, you can try with the following.

First, calculate the width of the scrollbar:

Then create a custom hook, around `ResizeObserver`, to understand when the document body is scrollable and when it's not:

Last, add _some_ padding to the document when its body is **not** scrollable, and remove it (the padding) when the body gets scrollable:

Sending keep-alive messages with Nest.js

SSE keep-alive messages are usually implemented via _comments_, i.e. lines with a colon as first character ([MDN](https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events#event_stream_format)); unfortunately Nest does not seem to support this type of messages, and this forces us to get a hold of the current request object and manually write keep-alive messages into it.

Nest expects SSE messages to comply to the following interface:

I tried to emit objects shaped like: `{ data: '' }`, as keep-alive messages, but Nest actually wound up emitting:

I did not like the fact that it was increasing the last id message for each keep alive message, so I opted for the other solution described above, i.e. get the response object injected and manually write into it.

Which of the `useEffect` dependencies was the one that triggered the effect?

I was recently trying to understand why one of my effects was getting fired even though I _thought_ that none its dependencies had changed, but then after a little bit of debugging I realized that I was listing as dependency an object which was getting re-created every time the hook was run...

The following homemade hook is what really helped me pinpoint the faulty dependency:

- Same signature as `useEffect`: effect function and dependencies array
- Internally calls `useEffect` to register the effect to fire when _any_ of the dependencies changes
- Also registers individual effects, one for each dependency, to log to console the dependency that did change
- Also registers an extra effect to log when the current component is mounted / unmounted

More handy react-hooks

`useEventSource`, a tiny wrapper around `EventSource` (for SSE):

- The hook's signature matches exactly `EventSource` one
- It returns the most recently received event / error

Couple of useful react-hooks we have created at work, recently

`useIntersectionObserver`, a tiny `IntersectionObserver` wrapper:

- `node` is the `HTMLElement` to observe on
- `opts` is the init params to pass to `IntersectionObserver`
- `observedEntry` is the observed entry, as seen by `IntersectionObserver`

`useVirtualKeyboardVisibility`, a hook to detect if the virtual keyboard is visible or not, while on mobile:

- handy if you wanted to hide certain elements as the user is typing into a form or something
- works by diffing the screen height with the document height

  - similar to what my vim-lispindent plugin does

[11 promises from a manager](https://twitter.com/MrEchs/status/1516024322409832450):

[How does React Suspense Work?](https://www.youtube.com/watch?v=onrMjAGY4qA)
  - You **throw a Promise**
  - React will catch that, wait for it to be fulfilled / rejected, and then call the render function again
  - The next time the render function is invoked, the promise's result is returned **syncrhonously** (i.e. no need to `await` for it)

TIL: you can pass `--not --remotes` to `git log` to get the list of local commits not present in any of the remotes
  - This was mentioned on [tpope/vim-fugitive] Large Unpulled section (Issue #1963), as a way to improve the information show while firing `:G`

TIL: [vim-rhubarb](https://github.com/tpope/vim-rhubarb) supports GitHub issues, issue URLs, and collaborator omni-completion
TIL: [Curl](http://curl.haxx.se/) supports reading secrets from .netrc

Git's dotted Range Notations

>

>

>

Source: https://mirrors.edge.kernel.org/pub/software/scm/git/docs/gitrevisions.html

TIL: ECMAScript [bind operator proposal](https://github.com/tc39/proposal-bind-operator)
  - It introduces a new operator `::` which performs `this` binding and method extraction
  - In its binary form, the `::` operator creates a bound function such that the left hand side of the operator is bound as the `this` variable to the target function on the right hand side

  - In its unary prefix form, the `::` operator creates a bound function such that the base of the supplied reference is bound as the `this` variable to the target function

  - `document::foo(bar)` is `foo.bind(document)(bar)` (this only makes sense when `foo` is defined like `function foo` and not `foo = () => ...` (`.bind` has no effect on arrow functions))
  - `::document.foo` is `document.foo.bind(document)`
  - The proposal has not been updated since 2018, but 2 new other proposals, namely [extensions](https://github.com/tc39/proposal-extensions), and [call-this](https://github.com/tabatkins/proposal-call-this-operator), are slowly gaining audience (both Stage-1)
  - Even if almost dead, 3 new proposals seem to try to replace this functionality

  - [Shadow DOM](https://web.dev/declarative-shadow-dom/), but for SSR
  - Add `shadowroot` property to a `<template>` element, and that's it

  - Content-addressed code: all the below definitions, **are the same**

  - For each hash, it will store it's serialized AST, plus additional metadata, like _names_

  - Inside the AST file, you will find the original definition with all the dependencies replaced by their hashes, and with all local variables normalized

  - No builds, easy renames, test caching...
  - No dependency conflicts
  - Easy typed, durable storage
  - Programs that deploy themselves + describe whole elastic distributed systems
  - Further reading: [Unison Programming Language](https://news.ycombinator.com/item?id=27652677), on Hacker News

WTF: Since when am I using the ancient version of bash bundled within MacOS, and not `brew`s one?
  - default bash shell

  - brew's one

  - Make sure `/usr/local/bin/bash` is listed anywhere inside /etc/shells
  - `chsh -s /usr/local/bin/bash`
  - didn't I do this already? @2017-12-12
  - I am not sure what's going on, but I am going to pretend this never happened...computers are weird
  - https://itnext.io/upgrading-bash-on-macos-7138bd1066ba

TIL: how to get a customizable entrypoint for a docker image
  - specify in the ENTRYPOINT, the base command only, e.g. `ENTRYPOINT ["node"]`
  - specify in the CMD, all the additional arguments to run the app, e.g. `CMD ["dist/main.js"]`
  - this way, a standard `docker run $image` would run: `node dist/main.js`
  - if you wanted to lunch a Node.js REPL instead: `docker run $image -`
  - if you wanted to fire a terminal shell instead, you will have to use the `--entrypoint` flag instead: `docker run --entrypoint sh $image`
  - [Docker CMD vs. Entrypoint Commands: What's the Difference?](https://phoenixnap.com/kb/docker-cmd-vs-entrypoint)
TIL: you can point your browser to `data:text/html,...`, and have it process some HTML
  - Three nested div elements, with a slightly opaque black background each (`%23` is just `#`, url-encoded)

TIL: `<a><b><a>` means `<a><b></b></a><b><a>`, i.e. the `<b>` gets duplicated

  - What if the `<b>` has an ID?  Well, that gets duplicated too!

TIL: the `<plaintext>` tag can be used to stop the parser from processing the rest of the document

  - You can use `<plaintext>` to make an html preamble to an arbitrary document, and have the whole thing be an html document

  - The `<plaintext>` tag just swallows everything coming after it, but you can still interact with the rest of the document just fine

TIL: module `<script>` are automatically deferred
  - btw, `defer` here basically means to wrap the script in `onload`

- is it possible to npm install a project with package-lock.json but without package.json? because that might speed up my docker builds a bit
  - say I add a new script to my package.json, but don't change anything else
  - ideally I would not want my CI/CD to re-download dependencies
  - re-building the it's fine, I guess, but re-downloading dependencies really seems like a waste of time, especially if the package-lock.json did not change
  - ideally I would: 1) copy package-lock, 2) run the magic npm command, 3) copy package.json
  - and if the package-lock does not change, docker should be able to use the cached layers for step 1 and 2, and only run 3
  - but does such magic command exist?
  ? https://stackoverflow.com/questions/51110793/bumping-package-json-version-without-invalidating-docker-cache

TIL: Replit.com just launched a @SearchEngine -- https://blog.replit.com/search
  - **We believe that you should be able to find anything on Replit in less than 30 seconds.**
  - First prototype created during what they internally call, the _hack week_
  - It uses Elasticsearch
  - Plus a bunch of data-pipelines whose sole job is to take from the database (or other sources), convert it to a more convenient format, and finally push the result _into_ Elasticsearch
  - It searches across REPLs, posts, comments, snippets of code, doc articles
  - Most importantly: no _commingled_ search: all the different data-stores are searched in parallel, and results are ranked

  - Some personal notes:

  - Clients open a Websocket connection to the liveprogramming server, and everything they receive, they will `eval()` it
  - On the server we will have custom DEFUN, DEFVAR macros that would a) emit actual _JavaScript_ (this way you can save the output to a file, and use that as bootstrap point for new clients), and b) send a message to all the connected clients to evaluate the just updated piece of code
  - I am not sure what a DEFVAR expression gets translated into, but we need to make sure the existing value is **not** overridden
  - Aha: https://github.com/eshamster/proto-cl-hot-loads
  - One could even think of integrating [incremental-dom](https://github.com/google/incremental-dom), and basically roll out your own poor man's version of React

TIL: You can stop `brew` from updating itself while `brew install`-ing something, by setting the following env variable: `HOMEBREW_NO_AUTO_UPDATE=1`
TIL: In JavaScript, `>>> 0`, is an abuse of the operator to convert any numeric expression to an "integer" or non-numeric expression to zero. -- [SO](https://stackoverflow.com/a/11385688)

  - This of this as a _public_ whiteboard, almost like the old guestbook
  - I am sure I am going to regret this ;-)

TIL: Vim landed native Language Server Protocol support! [vim/vim@9247a22](https://github.com/vim/vim/commit/9247a221ce7800c0ae1b3487112d314b8ab79f53)

Interesting presentation from @DavidNolen on @live-programming a react-native application: [ClojureScript in the Age of TypeScript](https://www.youtube.com/watch?v=3HxVMGaiZbc)

- Good analogy between a file-system, and a programs
  - You use a SHELL to interact with the file-system

  - REPL is how you interact with the program

- Too much focus on the _static_ part of the development cycle; no affordances for the _dynamic_ part, i.e. "what happens when I actually run the program?"
  - Lisp
  - Smalltalk
- Storybook (to deal with the _static_)
  - Helps you develop your React components in isolation
  - All significant UI component/view states are represented in a story
  - Can be tested via a simulator and on the device
- Krell (to deal with the _dynamic_)
  > In programming there is a wide-spread 1st order theory that one shouldn't build one's own tools, languages, and especially operating systems.  This is true--an incredible amount of time and energy has gone down these ratholes.  On the 2nd hand, if you can build your own tools, languages and operating systems, then you absolutely should because the leverage that can be obtained (and often the time not wasted in trying to fix other people's not quite right tools) can be incredible.  --Alan Kay, The Power of the Context
  - Connect to native devices / simulator
  - Hot code reload without loss of state
  - Possible thanks to: Clojure/ClojureScript, and React/React-Native

- Tooling should help with both the static and dynamic elements of our programs
  - debuggers solve only part of this problem
- Given the current state of technology 70s era Lisp/Smalltalk style live programming delivers incredible value over current practice
- You need powerful tools that do not get in the way to enable higher level thoughts

  - Apps layer
  - Motion layer
  - Function layer
  - Capslock
  - ...

TIL: CSS support the "parent selector", or as the [spec](https://drafts.csswg.org/selectors/#relational) calls it, "the relational pseudo-class" or simply `:has()`

This could be used for form styling, e.g. styling labels differently, based on the validity of their inputs:

But I am sure somebody else would come up with more interesting use cases that this.

A note on its usage though, from the [MDN](https://developer.mozilla.org/en-US/docs/Web/CSS/:has):

So it's fine to use it inside CSS; but it **cannot** be used with `document.querySelector()`...too bad!

Getting livereload to work when deployed on Replit turned out a bit more complicated that expected -- @whiteboard

- I am trying to integrate livereload with an Express application running on [Replit](https://replit.com)
  - When deployed there, Replit assigns you a hostname
  - It proxies all incoming connections to your service, so long as it listened to `0.0.0.0`
- To make this all work I then need the Express application to listen on `0.0.0.0` (not a big deal, it's the default)
- I also need to tell livereload to listen on a different interface, e.g. `127.0.0.1`
  - But this, unfortunately is currently not supported
  - Hence a fork, to [add support for an additional config, `host`](https://github.com/iamFIREcracker/node-livereload/commit/ac2b26e4d205f5be54c697eb487e21e98368e826) which I can then tweak accordingly (I have also [asked](https://github.com/napcs/node-livereload/issues/161) the maintainer of the project if there was appetite for such a change...let's see what they say)
- So, knowing all this and with our fork: first we spin up the livereload server

- Then we the application Websocket server

- Then the Express application, with middlewares to properly proxy requests to the liveserver and socket-io servers respectively

- Finally, we inject the following code on the client, to have them connect to the livereload server (you can read more about this [here](https://github.com/livereload/livereload-js/issues/98#issuecomment-1081922742))

DNS for @whiteboard

- I am going to be hosting this on Replit
- Replit supports custom domains via CNAME records
  - They give you a unique name, e.g. `$id.id.repl.co`
  - They have it resolve the IP address of the server your Repl runs on
  - You then set up a CNAME record so that `app.domain` gets resolved via `$id.id.repl.co`
- I bought [whiteboard.party](https://whiteboard.party) and I was hoping I could use that to access the app, but
- Google Domains would not let me set up a CNAME on a 2nd level domain
  - OK if you did it for: www.whiteboard.party, or app.whiteboard.party
  - Not OK for whiteboard.party
- So I have settled for [d.whiteboard.party](https://d.whiteboard.party) for now, also set up automatic forwarding so people landing on whiteboard.party would automatically be redirected to d.whiteboard.party
- I have not made up my mind yet; other alternatives follow
  - the.whiteboard.party
  - a.whiteboard.party
  - app.whiteboard.party

[Programmable notes](https://maggieappleton.com/programmatic-notes)

>

Few examples:

Or:

Or:

Or:

So the idea is basically figure out a way to make the knowledge base...alive!

From the same article:

  - I have also replaced the `<select>` with a _palette_ icon

  - This (and the change above too) enables us to display more control buttons on mobile

  - This way I don't have to mess around with nix scripts to get the livereload server to start while running on Replit

  - Quick overview of the existing functionalities, and on how to use it
  - "whiteboards are secret but not private" warning
  - "whiteboards older than 15 days will be nuked" danger

  - As of now, we are simply rendering an _ellipsis_ following the mouse movements

  - Pinch to zoom / double tap and hold a-la Google Maps
  - Two fingers to move around

  - [`p5.image()`](https://p5js.org/reference/#/p5/image), when in "destination rectangle mode" (i.e. invoked with 8 parameters as shown below) seems to be stretching the image when source's width or height gets bigger than the buffer's width or height

  - The solution was to implementing the _scaling_ logic ourselves, and simply paint the buffer (i.e. the dashboard) scaled up or down accordingly

  - `/` redirects to `/new`
  - `/new` redirects to `/20220325.ga49oukh4i`
  - In the future, we can have our landing page mounted on `/`

  - Repeatable builds, please!

  - `npm run serve` will use `nodemon` to start the server, excluding changes happening inside public/
  - `npm run livereload` will start `livereload` on the public/ folder
  - `npm run start-dev` will runn `npm run serve` and `npm run livereload`, in parallel
  - Change something on the express app, `nodemon` will kick in and restart it
  - Change something on the client facing code, `livereload` will kick in and tell any connected client to _refresh_ (note: JavaScript related changes require a full page refresh, while CSS or HTML ones, not)

  - That's because we were either registering touch events **or** mouse ones
  - Instead, we should have always registered mouse events, and optionally touch ones

  - 1 rendering canvas, 1 offscreen graphic
  - all the _remote_ draw operations are done on the offscreen
  - inside p5.draw, first we copy the offscreen graphic over to the canvas, and then we directly draw any local shape not yet acknowledged by the server
  - And with this, it's now decently usable on mobile as well!
  - For the record, this is the out of memory exception I was talking about

  - [javascript + html5 canvas: drawing instead of dragging/scrolling on mobile devices?](https://stackoverflow.com/questions/9975352/javascript-html5-canvas-drawing-instead-of-dragging-scrolling-on-mobile-devic)
  - [prevent browser scrolling while drawing on canvas on mobile](https://kirkdev.blogspot.com/2020/10/prevent-browser-scrolling-while-drawing.html)

  - We now use Bootstrap
  - Different modes of working: panning, drawing, erasing

  - We were moving the camera based on the point where the dragging had begun, and not just the previous point
  - We are now also taking the zoom level into account, and adjusting the movements accordingly (e.g. the more the user is zoomed in, the smaller the movement)

- Previously they were relative to the client view, and because of that draw commands had to include not just the points, but also the size of the client view
- This also also addresses a couple of quirks of the current implementation
  - Lines looked different (i.e. more thick, or more slim) based on the zoom level of the client that drew them; now they all look the same, at least **after** the server has acknowledged the draw command (while drawing, for the client who is drawing, the line would still look _different_)
  - Shapes would get stretched based on the aspect ratio of the client screen -- definitely a bug

- We were previously using UUIDs
- Now IDs look like: `r20220319.83e8fmmoo1`
  - `r`, to mark that it's a room ID
  - `20220319`, the date when the room was created
  - `.`, a separator
  - `83e8fmmoo1`, some random data [zbase32](https://philzimmermann.com/docs/human-oriented-base-32-encoding.txt) encoded
- One plus of having switched to a _structured_ ID like this one, is that we can now parse the room creation date and, for example, decide **not** to persist any room which is older than, say 30 days
  - We will still keep it it memory, just in case, but the moment the service is bounced, old rooms will be gone

  - Interestingly enough I was not able to use `p5.cursor` because it does not support .svg images; well, it actually lets you use them, it's just that if you also try to specify a x y offset to identify the _active_ portion of the cursor, p5.js will ignore this additional information

  - (try to) Draw a square
  - Open developer tools
  - Refresh the page (now that developer tools are open, the aspect ration of the canvas would be different)
  - The Square should be rendered as stretched vertically

TIL about the difference between _direct_ and _indirect_ `eval` in JavaScript

(You can read more about this here: [Global eval. What are the options?](http://perfectionkills.com/global-eval-what-are-the-options/))

Anyways, I will be playing with this a bit more over the following days, and see how difficult it actually is to implement a system that would let me change a Web page from my IDE, without page refresh (related: [Skewer: live web development with Emacs](https://github.com/skeeto/skewer-mode)).

I am dropping here a few links I stumbled upon, recently, around ID schemas.

Let's start with [Snowflake IDs](https://en.wikipedia.org/wiki/Snowflake_ID):

- Total of 64 bits (only 63 are actually used)
  - First 41 bits, representing milliseconds since a chose epoch
  - Next 10 bits represent the machine ID (to prevent clashes)
  - Next 12 bits, represent per-machine sequence number (this allow creating multiple IDs in the same millisecond)
- Sortable by time (IDs are based on the time they were created)
- The creation time of the entity using the ID, can be calculated from the snowflake
- Introduced by Twitter, in [June 2010](https://blog.twitter.com/engineering/en_us/a/2010/announcing-snowflake)
  - Later adopted by other companies as well, like Instagram in [December 2012](https://instagram-engineering.com/sharding-ids-at-instagram-1cf5a71e5a5c)

[Collision-resistant IDs](https://github.com/ericelliott/cuid):

- Example: **c - h72gsb32 - 0000 - udoc - l363eofy**
  - Literal `c`, identifying it's a cuid (starting with a character guarantees that the ID can be used pretty much everywhere, e.g. you cannot have a html entity ID starts with a number)
  - Timestamp
  - Counter, representing the number of IDs (modulus the block size) generated by the current process
  - Client fingerprint
  - Random
- Monotonically increasing (when less than 10000 cuids are generated within the same millisecond)
  - Suited for [high-performance database primary keys](http://code.openark.org/blog/mysql/monotonic-functions-sql-and-mysql), because they can be binary searched
- Fast, Secure, and Portable

Interesting [Twitter thread](https://twitter.com/meekaale/status/1503340213342556166) from @meekaale, on how, tagging functions, variables, and slots, with persistent unique IDs could aid with change tracking and hypermedia in general

>

>

>

This [commit message](https://github.com/mbrock/wisp/commit/6b5cb6599225beab6d0ec5bc0323042336608436) also shows how the author thinks this system might be used:

This could be useful, for example, if I wanted to create anchor points in my @plan file and have other notes reference to it.  Nothing crazy, really, but it's the simplicity of the solution that really caught my attention.

Feel like listening some chiptune @music, lately? [c64radio.com](https://c64radio.com/) got you covered!

Another @music related note; this time, it's [ThePrimeagen](https://www.twitch.tv/ThePrimeagen)'s [BANGERS](https://www.youtube.com/playlist?list=PLm323Lc7iSW9oSIDihesMJXmMNfh8U59k) playlist!

Getting zoom support for my toy @whiteboard turned out a tiny bit more complicated than I thought it would.

Zooming in or out, **without** taking the mouse position into account, is quite straightforward: all you have to do is widening or shortening the field of view as the user uses the scroll wheel.  However, users are used to move the mouse over the area of interest first, and when they use scroll wheel they expect the application to zoom in or out on that (and not, say, on around the center of the visible area, like the naive solution described above would probably end up doing).

To implement a smooth zoom in / out animation, the area of the whiteboard / the `<x, y>` point that the user is pointing at, with their mouse, _needs to stay the same for the whole duration of the animation_, or otherwise the camera would start moving around.  And that's it, really: it's that's simple!

The following is some documentation that I attached to my zoom routine; inside of it:

- `view`, represents which part of the whiteboard is currently visible to the current user
  - `view.x` and `view.y` represent the top-left corner of the visible area (relative to the top-left corner of the whiteboard)
  - `view.w` and `view.h` represent the width and height of the visible area
- `tview`, represents the target view, i.e. what do we want the user to be looking at, next

Again, pretty simple _after_ you realize you cannot move the area the user is zooming in to / out from.

  - [Main Thread Canvas vs Web Worker (Offscreen) Canvas](https://codepen.io/newinweb/pen/bxazNg)
  - [Generating the Mandelbrot Set](https://badgerbadgerbadgerbadger.dev/generating-the-mandelbrot-set/)

  - [companje/PanZoom.js](https://gist.github.com/companje/5478fff07a18a1f4806df4cf77ae1048)

[Programming, Motherfucker](http://programming-motherfucker.com/), will never get old!

>

>

>

In the same spirit, there is also: [@Outage party](https://outage.party)

>

>

>
>> My change was in a different datacenter.
>

>
>> I changed the internal network and this is an external problem.
>

>
>> I only changed staging.
>

>
>> My change couldn't possibly be related!
>

>
>> I didn't change code, it's just a backfill
>

>
>> Nothing changed! I just added some additional app nodes!
>

>
>> Seriously it would be impossible for this change to be related.
>

  - [Why does Teams always strip indentation when pasting text?](https://techcommunity.microsoft.com/t5/microsoft-teams/why-does-teams-always-strip-indentation-when-pasting-text/m-p/2349812) -- first opened in May 2021!
  - [From Markdown To Pastable Formatted Text In OS X Terminal](https://www.ostricher.com/2015/08/from-markdown-to-pastable-formatted-text-in-os-x-terminal/)
  - [Clipboard inspector](https://evercoder.github.io/clipboard-inspector/) -- Web page you can past stuff into, to see what's actually being stored inside the OS clipboard (i.e., plaintext, vs html, vs rft)

Thoughts on implementing undo/redo for my @multiplayer @whiteboard

- Each user keeps a stack of shapes -- the ones they drew
- Each shape has a unique ID attached to it -- generated by the user that created the shape
- "draw" event are broadcast'd to all the users (the sender of the message included)
  - this way, the sender, seeing a draw command with a _known_ ID, can acknowledge that the message was received by the server, and promote the shape into the "undo history stack"
- Each user keeps an undo-history stack
  - Entries of this stack contain the last received "draw" message
  - They also contain a "buffer", i.e. a copy of the visible canvas, **after** the last "draw" message had been processed
- When a user wants to undo **their** last "draw" action, they would generate an "undo" message, containing the ID of the shape that needs to be undone, and send it to the server which will then broadcast it to all the other clients
- They would pop from their shapes stack, and push it into a different stack (e.g., undone shapes)
- Each client (the sender included) will then
  - Pop elements elements from the undo-history stack (and push them into a different temporary stack), until the element with the matching ID is found
  - Pop that element too -- but discard it, don't save it anywhere
  - Copy the buffer of the first element of the undo-history stack onto the canvas
  - Re-apply all the "draw" operations, in order
- When re-doing the last operation instead, the client will simply generate a "draw" message, with the exact same shape information as before -- the only difference, is that now the shape will be rendered **on top** of everything else
- Drawing a new shape, should empty the local stack of undone shapes too -- correct, we do not support undo tree ;-)

[Copy canvas to graphics object in p5.js](https://stackoverflow.com/questions/70231135/copy-canvas-to-graphics-object-in-p5-js) @multiplayer @whiteboard

How to disable / enable specific Git branches from triggering a CI, with GitHub actions?

[This](https://github.com/git/git/commit/e76eec35540f9eca7baef3d84c164a1f8d4d3cb9) is how `git` did it, and I am going to summarize the steps here.

The first step is to create a branch, `config-repo`, with no files in it except for `ci/config`, whose sole responsibility is to return `true` or `false` if the input branch name is enabled for CI or not:

The next step is to create a new GitHub action job, `ci-config`, responsible for invoking `ci/config` above and ultimately set an _output_ variable indicating whether the current commit should trigger CI or not:

Last, you will have to update all the pre-existing jobs to a) wait for job `ci-config` to run first, and b) skip executing the job if `ci-config` decided that CI had to be disabled for the current commit:

And that's it!

I have been thinking about implementing a @multiplier @whiteboard lately.

"Why?" you might ask, and well, the answer is two-fold:

- I got sick of the alternatives, e.g. Gimp + scree/window share, or Microsoft Whiteboard, mostly because a) they usually eat up a lot of CPU and my MacBook Air from 2014 can hardly cope with that, and b) their integration with Microsoft Teams, when available, kind of suck (e.g., on Teams, you can activate Whiteboard only from meetings, but not from private chats)
- I wanted to play around with multiplayer concepts, and this seemed like a good application, with the right size, to get started with it

Here are some ideas of a possible MVP for this (`@A` items are more important than, say, `@C` ones):

Where do we start?! Well, of course the lines drawn will have to look _stunning_ (i.e. smooth), so why not kicking this off searching for ways to draw smooth lines?  Well, it _should_ be possible to do this (either with splines, or point filtering based on age / position), but I will surely have to dig deeper:

- [How to draw a smooth line through a set of points using Bezier Curves](https://stackoverflow.com/questions/9916119/how-to-draw-a-smooth-line-through-a-set-of-points-using-bezier-curves)
- [Canvas Spliner](https://github.com/jonathanlurie/canvasSpliner)
- [Cubic splines in JavaScript (via CoffeeScript)](http://blog.mackerron.com/2011/01/01/javascript-cubic-splines/)
- [understand implementation of cubic interpolation](https://stackoverflow.com/questions/28032958/understand-implementation-of-cubic-interpolation)
- [how to draw smooth curve through N points using javascript HTML5 canvas?](https://stackoverflow.com/questions/7054272/how-to-draw-smooth-curve-through-n-points-using-javascript-html5-canvas)

PS. I put together a simple Repl (it's a fork of another existing one, plus some local edits) which I am going to use to experiment with this: you can play with this [here](https://replit.com/@iamFIREcracker/MulitplayerTest).

Intent-based development environment

(taken from: https://amasad.me/right)

>

>

>

>

>

>

>

>

@vim
NrrwRgn - Region highlight is lost on write

I have been playing with [NrrwRgn]() Vim plugin lately, and I have to say it, I am quite enjoying it so far.  One small annoyance that I have experienced, is the fact that the highlight of the narrowed region inside the original window seem to get lost every time I write changes back from the narrowed region to the original window (read: https://github.com/chrisbra/NrrwRgn/issues/87).

I did spend some time looking into this today, and here are my findings.

First off, here is the context of the .txt file I have used for testing:

While to create the narrowed regions I have tried with the following steps, and either one of them seem to trigger the bug:

1. Line-wise selection, `:NarrowRegion` command
2. Visual selection, `<leader>nr` mapping

Let's get now to the interesting part:

- On save, while on the narrowed buffer, `:WidenRegion` ends up getting called
- Inside of it, `winnr` points to the ID of the current window, i.e. the ID of the window where the narrowed buffer is currently loaded
- `orig_buf` instead to the ID of the buffer where the narrowed region was created from
- In my execution path, `<sid>JumpToBufinTab` gets invoked which results in making the original window active (i.e. `winnr()` is now equal to `bufwinnr(orig_buf)`
- Note: later on, the following is run: `exe ':noa'. orig_win. 'wincmd w'`, but I am not sure what that is for, since `JumpToBufinTab` already took care of focusing the "right" window
- Then the narrowed region is widened accordingly, and highlights optionally reset - this is the guard being used:

But the thing is, `winnr` will **always** be different from `winnr()` (in my execution path at least) which means the "re-highlight" logic will **never** be executed.

Now, by the look of `:help matchadd()`, the new highlight pattern gets defined for the _current window_; doesn't this suggest that t the original window (i.e. the one where the narrowed region was created from), be the active, at the time `<sid>AddMatches` is invoked? (which should already be the case, thanks to the call to `JumpToBufinTab`)

For fun, I tweaked the guard logic as follows, and now the narrowed region seems to get re-highlighted correctly after each call to `:WidenRegion`:

Again, this seems to work, but I am not sure about all the other use cases that this change might have broken...

@vim @lisp
Today I finally got around to scratching an itch of my own: getting Vim to highlight the S-Expression surrounding the cursor position.

The implementation is super naive:

- When the cursor moves (both in normal, and insert mode)
- Get `vlime` to return us the start and end position of the surrounding S-expression
- Create a text property for that region (see: `:help textprop`), and highlight that accordingly

I am sure it can be improved (e.g. caching some of the calls to `vlime#ui#CurExpr()`), but I am really enjoying the scope-highlight effect so far!

Thanks [SO](https://vi.stackexchange.com/a/20522) for mentioning Vim's support for text properties (`:help textprop`)!

@vim @plan
`Neoformat` invokes `prettier` as follows:

But the missing file extension causes `prettier` to error out:

One possible solution to this is to rename the buffer and include the proper file extension to it:

Running `:Neoformat` will now finally get `prettier` to properly reformat my code...great!

There is one more problem though: `:Neoformat` is not kicking in automatically on `:write`, as it should as per instructed by the following `:autocommand`:

Same is for `:Neomake`, or any other `:BufWrite` activated autocommand.

Apparently, `NrrwRgn` is using `:BufWriteCmd` to manually sync the narrowed buffer back into the not narrowed one, and that seems to cause Vim to skip triggering `BufWrite` and `BufWritePost` events.

Anyways, long story short I ended up creating a [PR](https://github.com/chrisbra/NrrwRgn/pull/88) to add a new hook for running `:Neomake` in it; let's see what the maintainers think about this.

PS. I abandoned the idea of automatically running `prettier` on save; instead, I will be manually running it whenever I need.  On the other hand, I still think it's a good idea to have `eslint` (i.e. `:Neomake`) run every time the buffer is saved, especially because that is **not** changing the content of the buffer, but simply adding annotations to it.

Consider adding swank-loader.lisp's `dirname` to the location of the directory where fasl files are cached

(This was posted on [slime/slime/issues/704](https://github.com/slime/slime/issues/704))

While testing something out, yesterday, I got into this weird situation where it appeared as if an older version of Slime was getting loaded, and not the one that I was trying to test; after a little bit of debugging, I realized the problem had something to do with where Slime is caching fasl files, hence the enhancement request.

A little bit about my setup (your mileage might vary of course):

- `~/opt/slime/__main__/`, git worktree pointing to my personal fork of Slime
- `~/opt/slime/upstream-master/`, git worktree pointing to the upstream repo, i.e. this one
- Inside my CL init script I have `(pushnew #P"~/opt/slime/__main__/" asdf:*central-registry*)` (or `(pushnew #P"~/opt/slime/upstream-master/" asdf:*central-registry*)`) to easily switch between Slime implementations

With this setup, and due to the default location chosen by Slime to cache its fasl files, every time I changed my init script to switch the _active_ version of Slime, I also had to _touch_ any .lisp file contained in that directory or chances are the fasls from the _inactive_ worktree will end up being loaded instead (especially if more recent).

Of course this only happens because I have 2 separate directories where Slime can be loaded from: in the case of a single git worktree, switching branches would indeed _touch_ any changed file and invalidate cached fasls accordingly.

At the moment, Slime's fasl files are getting cached inside a directory whose location takes into account:

- The current user's home
- Slime's version
- A _fingerprint_ of the CL implementation / OS where Slime is getting run

For example, on my laptop (MacOS), when I fire up Slime with SBCL I get:

What if the chosen directory also took into account the location of the swank-loader file itself?

And with the above:

Alternatively, and as explained at the top of swank-loader.lisp, one could load the loader, override SWANK-LOADER:*FASL-DIRECTORY*, and finally call SWANK-LOADER:INIT.  Unfortunately though, even if the above would surely get the job done without the need for further enhancements from Slime, it would also _not_ prevent a different person with a setup similar to mine, from having to figure this all out on their own and implement the same workaround; so here I am, picking your brain about this possible enhancement.

Let me know what you think about this, and in case I will shove the diff above (or a similar one) into a pull request for approval.

M.

On HASH-TABLEs performance

(posted on [r/Common_Lisp](https://www.reddit.com/r/Common_Lisp/comments/s0g2q3/on_hashtables_performance/))

I [built](https://topaz.github.io/paste/#XQAAAQDdBwAAAAAAAAAUGQimgx+p6Nchs0/Hc3cRxcmyfeV+Bzi2FxeDDBZEkgZaDBSyRjbUkuFXP6dhVAaOH8AG99AzdDUHR/lSrXrRzt2ru8sshOcmQ5UeY7P5AZQhS4ncXon3a6r8j5K/gr4xuK1jjTG4PHnVajamzB6t54TV5dSPS63MDOK6jD6CsHfC+VkV4bms/+I8MmYXI4GU2JxpblEiXKntPh1orBPfGpyTCfhx4v+kHU29G6mF1Y4EM6ozuoAyzjwxpY0eKSSV1zFprANFIIlsaPqm/nWF9W4i224u0tUm3IHb+tnMDrFtscipbIplaGiZN8B2Q1apClGT/+51hyLVNGM+4prkx8VWxBWeWuN62LCmMrY0iqRvFeCwKqpwg4s4VRogYMgeG3AOyY1DlJ0UJFetXLjJ+7pMA+8jUmYyE6xRJd9R+jn/cPnkNyDceLd1iFB/ODUgVXLcyrYb7jFIIeucRNGqkgQ7lwe0xvmyiBLkHyIe3ML8lZQcmhyinz9Ynab880cOGsBYBuTRjCS7dCvLr5XKDjw8SpdnWXgjVrzLA49wE+NZXVkPz6tTVzFUR36unRBsIJZJKfYRi3ZUToT1eFyKKayvxZpI9V1QkNJvJehPwqf797u2T57qMuE1UrtnhSso1kQh/BEo33aCHrNXfO/H71RV95KbXakyaLfqTAeeKA2hUrQSbAFnewyRS+3eKmTvbe0+XL1ltwMKAccDiSJR+DZ8iMZhQx91qBpU6W4Gu5c+XA4oT8DFrhGWR1aHzdLLf2ICtG8VUVnLizIL/+Wv790=) an implementation of the A* algorithm which internally uses two HASH-TABLEs:

- `cost-so-far`, mapping all the searched states the cost required to get there, from the initial state -- this is used to calculate the final cost to move from the initial state to the goal one
- `come-from`, mapping all the searched states to their previous state -- this is used to calculate the complete path to move from the initial state to the goal one

As I was profiling this, I came to the conclusions that representing search states with 2D ARRAYs instead of HASH-TABLEs of the same size would have a huge positive impact on the overal runtime (i.e. it's better to use the former than the latter), but I cannot quite understand why, hence this post.

Now, it does not matter if you are not familiar with A*; in fact, we can completely ignore all its mechanics and simply pretend we have two HASH-TABLEs we need to update.  In addition, let's pretend our search state was a `2` rows by `10` columns grid, with numbers in it.

I came up with (and benchmarked) the following 3 state representations:

1. HASH-TABLE having `(row col)` as keys
2. HASH-TABLE having `(+ (* row 100) col)` as keys -- this to rule out any excessive consing from the above
3. 2D ARRAY

The benchmark is simple:

- We initialize `cost-so-far` and `come-from` hash tables
- We initialize our starting grid
- Then, 10000 times
- We copy the grid (I used ALEXANDRIA:COPY-HASH-TABLE and ALEXANDRIA:COPY-ARRAY for this)
- Move two random elements
- Save the new state inside `cost-so-far` and `come-from`

Here is the run time for the first state representation, HASH-TABLE with LISTs as keys:

Here is the run time for the second state representation, HASH-TABLE with NUMBERs as keys:

While this is the runtime of the third and last state representation, i.e. 2D ARRAY:

That's a 100x speed-up!

For fun I run another experiment in which I still used a HASH-TABLE (with `(row col)` as keys) to represent the search state, but also serialized that into a LIST of its elements and used _that_ to update update `cost-so-far` and `came-from`:

I was expecting this run to cons up more than the previous ones, but the runtime?! I was definitely not expecting this to be comparable with the run in which we used a 2D ARRAY as our search state!

So, can anyone tell me what's going on here? Are ARRAYs really that easier to EQUALP as compared to HASH-TABLEs, or am I looking at the wrong place?  I thought with such small states using an array or a hash table would not make much of a difference, but apparently it does!

...

>

I get what you are saying: HASH-TABLEs require more "bookkeeping" than ARRAYs, and I 100% agree agree with you on that.  However, most of these things that you mentioned are executed in **all** the different scenarios that we run, and yet the runtime seems to increase only when we try to EQUALP hash tables together.  Let's review what each scenario does.

Scenario 1 (HASH-TABLE with `(row col)` as keys):

- Cost to generate a new state

  - Copy a HASH-TABLE 10000 times
  - Rotate two random elements

- Bookkeeping costs for `cost-so-far`

  - Look up the new state, i.e. a HASH-TABLE instance, into the hash table
  - Potentially resize the hash table
  - Potentially insert the new entry in the hash table

- Bookkeeping costs for `come-from` (same as above)

Scenario 3 (2D ARRAY):

- Cost to generate a new state

  - Copy a ARRAY 10000 times
  - Rotate two random elements

- Bookkeeping costs for `cost-so-far`

  - Look up the new state, i.e. a ARRAY instance, into the hash table
  - Potentially resize the hash table
  - Potentially insert the new entry in the hash table

- Bookkeeping costs for `come-from` (same as above)

In one case we get a 7s runtime, while in the other a 0.2s one; the difference can be attributed to:

- Different cost required to copy a HASH-TABLE / ARRAY
- Different cost required to rotate elements inside a HASH-TABLE / ARRAY
- Different cost required to see if a HASH-TABLE / ARRAY is contained inside another HASH-TABLE (this last one being `cost-so-far` or `come-from`)

The last scenario though, where we serialize the hash table into a list of its elements, should help us better understand where most of the time is actually spent:

- Cost to generate a new state

  - Copy a HASH-TABLE 10000 times
  - Rotate two random elements

- Bookkeeping costs for `cost-so-far`

  - Serialize the HASH-TABLE into a list of its elements
  - Look up the new serialized state, i.e. a LIST, into the hash table
  - Potentially resize the hash table
  - Potentially insert the new entry in the hash table

- Bookkeeping costs for `come-from` (same as above)

With this, the runtime is now to 0.9s, and the only differences with the first scenario are that here:

- There is an extra serialization step
- EQUALP for the `cost-so-far` and `come-from` tables works with LISTs and not HASH-TABLEs

I mean, I get that scanning a HASH-TABLE would require more work, but _that_ more work really?  Here are two more tests where we try to measure the time to generate the new states, and the time to update `cost-so-far` and `come-from`, separately.

Here we use use HASH-TABLE as keys:

And it takes around 7.5s for keys comparisons and resizing.

Here instead we serialize HASH-TABLEs into a LIST first, and then use that as key:

I am still puzzled by this, but it is what it is, so I guess I will have to make peace with it.

...

That's correct.

What about the scenario in which I serialize `next` into a LIST first, and then use that to GETHASH into `cost-so-far` and `come-from`?  I would expect the hash function to behave similarly to the case where we are hashing hash tables; yet somehow there is almost a 100 folds difference in the overall runtime.

For _fun_, I even tried to serialize not just `next` values, but their keys too; it conses more of course, but its runtime is still way better than if we used EQUALP on hash tables:

"For a _small_ dataset, a LIST performs better than a HASH-TABLE" -cit

I am not sure where did I read this from, but I guess this rabbit hole I find myself in, right now, kind of testifies to that ;-)

...

>> What about the scenario in which I serialize next into a LIST first, and then use that to GETHASH into cost-so-far and come-from?
>

>
>> I would expect the hash function to behave similarly to the case wherewe are hashing hash tables; yet somehow there is almost a 100 folds difference in the overall runtime.
>

Oh, I finally see what's going on, and I think I misread your: "So your gethash on COST-SO-FAR and COME-FROM are not O(1) operations. They are O(N)." in the parent comment!

Let's see if I am getting this right -- please, do correct me if I am wrong:

- When writing to / reading from a HASH-TABLE, the provided key, `k`, gets _hashed_ (SBCL uses SB-IMPL::PSXHASH for this), and if an entry with the same key is already found in the HASH-TABLE, the implementation then goes on and tests for _equality_
- If equal, the we found the entry to update / read, otherwise, the implementation needs to try a different entry; this usually translates to either scanning a list with all the keys clashing on the same hash value, until one is found which is _equal_ to `k` or until the list is exhausted; or, a different implementation could decide to keep on trying `(hash + 1) % size`, `(hash + 2) % size`, until an _empty_ entry, or one which is _equal_ to `k` is found
- Now, when a HASH-TABLE is passed in to SB-IMPL::PSXHASH, the function will return a hash value which is only function of a) the test function the HASH-TABLE got set up with, and b) the number of entries of the HASH-TABLE (yes, the **number of entries**, and not their values; I wanted to stress this because I originally did not pay too much attention to this while reading the parent comment, as I assumed it was referring to the _complexity_ to calculate this hash, i.e. the more elements, the longer the hash function would take, but clearly I was wrong about it!)
- But the number of entries of our HASH-TABLE instances, is always the same (i.e. `20`), and so is the `test` function we initialized them with (i.e. EQUAL)
- This means that SB-IMPL::PSXHASH, for any given state, would always be returning the same hash number (i.e. `4242822982970596467` for the case of a EQUAL HASH-TABLE with `20` entries)
- This means that GETHASH's performance will quickly degrade from O(1) to O(N), as the implementation is forced to scan the full set of entries until one which is _equal_ to `k` is found, or we wrapped around

This also means that under these circumstances, `cost-so-far` and `come-from` are almost behaving as if we they were association lists; actually, let's try to confirm this with yet another scenario:

And we exclude HASH-TABLE resizing costs from the first scenario, we are getting a very similar runtime!

Right: I wanted to simplify the code a little bit, to make it easier for readers to follow, but clearly I did not think this through.  Thanks for noticing this silly mistake of mine!

Well, there is a comment in the source code covering just that:

Hashing the k/v pair vector would take insertion order into account; this could lead to SB-IMPL::PSXHASH to generate two different hash numbers, even though the two HASH-TABLE instances are _equal_ (as per the EQUALP definition); this could lead to duplicate data getting stored in the HASH-TABLE.  Instead, we prefer SB-IMPL:PSXHASH to do the minimal amount of work, that cannot cause duplicate keys to accidentally be stored in the HASH-TABLE, and let the `test` predicate (i.e. EQUALP) do the rest.

Thanks /u/PhysicistWantsDonuts for helping me with this!

Advent of Code: [2021/25](https://adventofcode.com/2021/day/25)

>

So we call a deep-sea marine biologist (whose number we found on a handwritten note taped to the wall of the submarine's cockpit), which explains us what's going on:

Continues:

For example:

OK, kinda makes sense...

The task for the day:

We are going to simulate this, i.e. move the two herds, the east facing one first, and the south facing one next, until none of them can move any more.

But first, the input; let's parse the input map into a 2D array:

Now, let's see how we are going to move the two herds:

- All the sea cucumber from the same herd are moving at the same time, so we will be creating a copy of the input map, `next`: we will be reading from `curr`, and writing to `next`
- Then, we will move the **east** facing heard first, and the **south** facing one next
- For each row, for each column
- If the _next_ spot is empty, we swap the content of the two elements
- And we also keep track that at least one sea cucumber did move

Then, all is left to do is call TICK repeatedly until the sea cucumbers stop moving, and return the number of elapsed steps:

And that's it!

Final plumbing:

Test run:

This is not too far off from what I [used](https://topaz.github.io/paste/#XQAAAQBUBwAAAAAAAAAUGQimgx+p6PZhRh7uIO+WahagjQFtPUiCoxNgFycn2BrqOj/HOBL8Z7DCsyBqFgSXDidjaytfAiVhJKKToKeI2JxiZ1r3xMJuElxpV/LfXi+nfkg/MWFCDwfkS6x35gl2OmlvYLs1AppDHrAR5MIjo5hAvQiA9y9MxVh48Mqj81RrYO7q1GfdyW/pFPj3hl6kTirDyjE5L6TtFsCxNfeCLugBv8cfYt3DY/ia2Epg1VkMZ91iBAFrgeSef1aRh4arkULTSjUqIMa588z4sP9TTTv0PqBamaxPUZGDu1Tr1KRPunpf8tB2zfbmEabkt86WtB7WTltXj6WGRoeFCcg8tGjKV9/bV7Qj4xMu1NVIm94XISUtHE6i7n6xaAHOiMFQyEhLctU51vQxOHfIJwnL81D7j9i6oYdEMRjfNJfahIPYpKmBTlc4V8/AaCLCBumz24LNRMR305NuNFQNX1OmgK2eTToEfjF94iG26pTN5KbOoxpmaUGs56fY7XAU1shggy59mMrVqjquFxuBkorPucWyv4rA00DIw4fSC/UrRvGV5kduUHEkQBxEGGVxenkuzNkZ/cgwceHNxLAEHF3vYIPjbPdBPtFtCtE8tLpm9p4Y+7iqDKi2dpxvYceCYl3bVrxRR3fz4Sm1PMTVhC6KZWlh8Sq+TqhXvrfpqHPDFEqU6zd+0YHxwiK8Iv35pare3idS1FS8oeYm6+vSgDstpS04s/OwxCdMJSADz/VguTxIcg07RU9e0P/pqzT/) to get my star for the day; main differences:

- Used a HASH-TABLE instead of a 2D array for the map
- Kept on forgetting about ROTATEF -- instead, I went with the usual SETF / GETHASH combo

Rest is pretty much the same; and if you wonder how does that compare to the solution presented here, well, as expected, the HASH-TABLE one would cons up more and take longer to run:

And this is really it, folks; this was the last day of Advent of Code 2021, and these are my personal stats for the year:

What to say:

- Another great year, with lots of interesting challenges
- First year where I tried to be aware at 0600 when the problem unlocked
- First year where I ranked sub-1000 for one of the problems
- A bit upset that I failed to solve day 23 and day 24 on time

Until the next time...

TIL: You better cache your CL-SOURCE-FILE instances if you don't want ASDF to compile your files...TWICE!

Let's create ourselves a little playground, with a couple dummy files in it, `foo1.lisp` and `foo2.lisp`, each defining an empty package (`:foo1` and `:foo2` respectively):

Create `playground.asd`, and dump the following in it:

Before we move on, let's take a closer look at the snippet above:

- We define a new class, AUTO-MODULE
- We specialize COMPONENT-CHILDREN for AUTO-MODULE instances to look for all the `.lisp` files contained in the current directory (i.e. `self`), and create instances of CL-SOURCE-FILE off of them
- We define our system, `:playground`, and add an AUTO-MODULE component to it (this way ASDF will load / compile all the files contained inside `foo` without us having to explicitly listing them all)

Pop SBCL open (or any other CL implementation), make sure ASDF can load systems defined in the current working directory, then load `:playground`:

We defined 2 packages, `:foo1` and `:foo2`, yet somehow we ended up with 4 different compilation messages, two per package; this isn't happening if I manually list all the files in my .asd file, is it?  Let's confirm this.

Update `playground.asd`:

Load the system again:

As expected, no double compilation messages.

So what's going on exactly?  Well, COMPONENT-CHILDREN is getting called twice, one from within LOAD-OP and one from within COMPILE-OP, and there is nothing we can do about that (i.e. it's expected); the problem is, we are creating new CL-SOURCE-FILE instances at each COMPONENT-CHILDREN invocation, and that seems to trick ASDF into believing that there were 4 different files instead of 2.

Let's solve this by creating a cache of reusable CL-SOURCE-FILE instances (we will be attaching it to the AUTO-MODULE instance so that the cache will be deleted as soon as the AUTO-MODULE instance object is disposed of):

Reload the system:

...and it looks like we fixed it: this time around, `foo1.lisp` and `foo2.lisp` were compiled only once, as if we listed them explicitly inside the system definition.

So yeah, you better cache your CL-SOURCE-FILE instances if you don't want ASDF to compile your files twice!

:wq

Advent of Code: [2021/24](https://adventofcode.com/2021/day/24)

Continues:

>

>

OK...

>

OK......

>

>

OK.........

Finally, the task:

OK............

First off, let's take care of the input:

- For each line
- We start reading _forms_ out of it
- Instruction and variable names will be read into symbols
- Integers will be read into...well, integers

Let's join the instructions together, to see if anything interesting comes up.

First we define a function, EXEC, with associated modify macro EXECF, to symbolically execute the given instructions, i.e. wrap two operands together with the symbol of operations the instruction represents:

Next we start executing instructions, and inspect the content of the variables (and reset them), every time an INP instruction is found:

Let's see if we can simplify some of these expressions a bit (I am thinking about those `(* ... 0)` expressions):

With this, the output tends to get a bit better, but there is more we can do:

All those `(+ 0 ...)` expressions can be replaced with their non-zero operand; all those `(truncate z 1)` expressions can be replaced with `z`:

With the above changes we get:

If you carefully look at this you will notice that:

- `w`, i.e. the first element of the array of variables, will **always** contain `?`, i.e. the value read with the IMP instruction
- `z`, i.e. the last element of the array of variables, will **always** contain an expression, function of the `?` and `z` only

Knowing this, we can _compile_ these expressions into 14 different functions which later on we are going to use to find the largest model number which our monad can validate.  Note: these functions are going to accept two parameters, one for `?`, and one for the previous `z` value:

What next?  Well, we are going to brute-force this, hoping that the simplifications that we discussed above will reduce the complexity of each of the 14 ALU stages.

Here is what we are going to do:

- We pick a value in between `1` and `9` (well, better to start from `9` and then down to `1` if we want to find the *largest** model number)
- We feed that digit the previous value of `z` (it starts from `0`) to the first function that we compiled, and get the new `z` value back
- We move to the next ALU function and repeat
- Until there are no more functions to execute **and** `z` is 0; in which case, we found our solution and all we have to do is walk backward and construct the model number
- Or we run out of functions to execute, in which case we will have to backtrack as we hit a dead end (i.e. we found an **invalid** 14-digits model number)

Easy right?!  Well, no: there are a lot of different states to try out, i.e. `9**14`, so the above will take quite some time to run, irrespective of all the simplifications we did before.

So what can we do?  We can give memoization a try, and hope that it would help us quickly prune input choices which will ultimately lead to an invalid model number:

Let's go!

What about part 2?

We lucked out!  All we have to do is tell FIRST-VALID-MODEL to try the different digits starting from `1`, up to `9`:

Final plumbing:

Test run:

Now, how did I fare while on the spot, as the clock was ticking?  Not so well actually:

- I only managed to complete this few days after Christmas
- I got stuck and was _forced_ (well, nobody really _forced_ me...) to peek into the day's [solutions megathread](https://www.reddit.com/r/adventofcode/comments/rnejv5/2021_day_24_solutions/) looking for just the minimal amount of help that would unblock me

What did go well?

- Even back then I was able to simplify input expressions quite a bit; some might say I even went [a little overboard](https://topaz.github.io/paste/#XQAAAQCqEAAAAAAAAAAUHMineAofRq+qilruyMI8srv1Rg1uS/cG09uVz6iNOSymsWauBb4HdvwRzUgG3psYwA9ob03xmHHICYRXgzfu2i0nGZpixjzLcDptv6TCLlXXrz98p9BIthGkSVFhdvb6gLoZ1STrdqf969ZW0uN6e9tnSLpzmV/cfNPAa4yZuX8r/QUt5GPLLw9WBxZsvBwVd+iA3jgA0dSOkuWY/Wny+WZ9MDi9HufgXnKGeCV9q3rqEv9KMjQ7gvBB7qXZi3DbHfcXP/Rh5GRrbuKUI+p1fChdFmfPWTq303v6WlVEh9SXwXYEzgQo26eLpHG4d3v+POROD1yIk3I5aLlQQCbalbasGItRN9EpKT8aP5jk9wEX/EBTX64iRSAlXAHUTpTA6S19gXIvN1cX6wbx4iux2hdjw0fcADYjKwMXcNYHV/cBZxaas46sis7VUpI6UEZHIk5SS1s2cq48brLVFAp+OSMpMLN9sOvxwWwjdoql1MQlqAZeZj/lwvJC9+7zYdov52Qpa1Jl12AWN1m2hS8gNsxl+VRv41FtOBqLPxJEvCXUjTPR5SjIc4LRgvS3ZRlfvnrn46LGR86q5IJvYCMP2cYVLmbsWhDTljQQsfIpRaUbQlDnAOjdj441qqd0uq3wCwnKYCckEDY8rZzulQOAuK3CcIbgA1rx4xFqoD6A1E63buHyYhivk3EeBq2AFEEwlWVK3F5WtIxLTFTpUTjN2O2P94/BuIHPFfOBBRCmN9yhrZTpHEcyjHYV3QpstwDdoVaV9ZCW0GoMp6SpCOHDnYg1ApFYBjbxXZXFNOwIwLqs4jbvGZEgucK/Xl5H5FJmi23msTBaKI1KosOczB92Vls4M81OP/LixEsGk1Oxb6++JIcGLQQj1/wAkXBodz9ipb9R3mzuqTD6E7032eMaJH8ZT6VVkpWHdQTY+weIJFMP+2USy+MZcwwsw/E2fJY+khg+iHwavAJzu99224jTDLMR7jGwPjhxmHM62eLj+bngOyhZXLlICMckWQ5qbyjunI1c78GYZoG5Pkc/pRkecAqa1EOe4kLtAFdssxTzRoOescam6+9bAP4Y3+1Zsl98+ToPxb+OimqcU5ogi7jFf27Iq/FkOAH3qwcoc7rqOpeiD4krQRVwwd/gIagp6A7n0oFzBZcMzzfkF/tUAYvLLNk+KIcB+hDqfvqrqAchZTFjh2zj2pAwONRTSW3JQBf14HZ9+BiM26wMCxashcpd26q0Rf/7dksh) with it, especially as I started reducing them based on the minimum and maximum values of each expression
- I was able to notice that each expression wound up being a function of the previous value of `z` and of the current digit of the model number, i.e. `w`

What did not go well?

- I spent time trying to get an ALU runner to work with local bindings (instead of an ARRAY as presented above), only to realize SYMBOL-VALUE cannot not be used to access the value of a lexical variable (see: http://clhs.lisp.se/Body/f_symb_5.htm).  I should have used DEFPARAMETER instead, as shown [here](https://topaz.github.io/paste/#XQAAAQBRBAAAAAAAAAAUGQimgulVkMqJePdJ12uYSyrx9HETSDeM7iPwMm5IzbnhqpMgXbIZ4j+wT3G3yM/Phd9tY3YWGUV5vVqRYE41FzNleAVB3CZ1VdavQwqHLspPcheinZ29SxrxBs+UugGbKyMw8Cjyc5tfvwceJi2lK3srvAqCYe8dTUDreC1lbu5JIlNdTDSvkoQ4U6tfizTr5wNdnl/PT+rX4qRsvS/HylH4dGdRVXNkttLCoE3/ZuaGbju5AcTub2qhXsAH2D2KWb7m368oylPdNdaeeElu3w+21SA/wiHJlBPSZgs/daoC4FQiNa7Zvj46biP2W4tShV9lpsclm0+zKm9ADHlF29MYMkpuv6p+JVndGry6/HywWWuO4mKd7jem6ik1BVOJLXPmecX3AKsQFX058TVpucNg+P0QL6xyB1/ISRh3Npa7pBPXMRhsLa4LWseDuqM4RhdnT7B0B5ECH5pler/vvA1RJepfEq/NGbbzTgI+96j4UsPgAarLdXIi5BIUY7n///JNZps=), but go figure why it took me so long to figure this out...
- I went [a little overboard](https://topaz.github.io/paste/#XQAAAQCqEAAAAAAAAAAUHMineAofRq+qilruyMI8srv1Rg1uS/cG09uVz6iNOSymsWauBb4HdvwRzUgG3psYwA9ob03xmHHICYRXgzfu2i0nGZpixjzLcDptv6TCLlXXrz98p9BIthGkSVFhdvb6gLoZ1STrdqf969ZW0uN6e9tnSLpzmV/cfNPAa4yZuX8r/QUt5GPLLw9WBxZsvBwVd+iA3jgA0dSOkuWY/Wny+WZ9MDi9HufgXnKGeCV9q3rqEv9KMjQ7gvBB7qXZi3DbHfcXP/Rh5GRrbuKUI+p1fChdFmfPWTq303v6WlVEh9SXwXYEzgQo26eLpHG4d3v+POROD1yIk3I5aLlQQCbalbasGItRN9EpKT8aP5jk9wEX/EBTX64iRSAlXAHUTpTA6S19gXIvN1cX6wbx4iux2hdjw0fcADYjKwMXcNYHV/cBZxaas46sis7VUpI6UEZHIk5SS1s2cq48brLVFAp+OSMpMLN9sOvxwWwjdoql1MQlqAZeZj/lwvJC9+7zYdov52Qpa1Jl12AWN1m2hS8gNsxl+VRv41FtOBqLPxJEvCXUjTPR5SjIc4LRgvS3ZRlfvnrn46LGR86q5IJvYCMP2cYVLmbsWhDTljQQsfIpRaUbQlDnAOjdj441qqd0uq3wCwnKYCckEDY8rZzulQOAuK3CcIbgA1rx4xFqoD6A1E63buHyYhivk3EeBq2AFEEwlWVK3F5WtIxLTFTpUTjN2O2P94/BuIHPFfOBBRCmN9yhrZTpHEcyjHYV3QpstwDdoVaV9ZCW0GoMp6SpCOHDnYg1ApFYBjbxXZXFNOwIwLqs4jbvGZEgucK/Xl5H5FJmi23msTBaKI1KosOczB92Vls4M81OP/LixEsGk1Oxb6++JIcGLQQj1/wAkXBodz9ipb9R3mzuqTD6E7032eMaJH8ZT6VVkpWHdQTY+weIJFMP+2USy+MZcwwsw/E2fJY+khg+iHwavAJzu99224jTDLMR7jGwPjhxmHM62eLj+bngOyhZXLlICMckWQ5qbyjunI1c78GYZoG5Pkc/pRkecAqa1EOe4kLtAFdssxTzRoOescam6+9bAP4Y3+1Zsl98+ToPxb+OimqcU5ogi7jFf27Iq/FkOAH3qwcoc7rqOpeiD4krQRVwwd/gIagp6A7n0oFzBZcMzzfkF/tUAYvLLNk+KIcB+hDqfvqrqAchZTFjh2zj2pAwONRTSW3JQBf14HZ9+BiM26wMCxashcpd26q0Rf/7dksh) with trying to simplify the given expressions, to the point that I started reducing expressions based on the minimum and maximum values of each expression.  Anyways, why would this a problem? Well, it's not a problem per-se, it's just that even with these fully reduced expressions, I still did not know what to make out of them -- which leads me to the next 2 points
- I could not "connect the dots": the monad is made of 14 expressions, 7 of which multiply by 26, and seven of which either multiply **or** divide by 26; we do not have any control over the former ones (i.e. the ones that multiply by 26), but in order for the final number to be `0` then the remaining 7 expressions need to execute a division and not a multiplication.  Well, with this hint, I was then able to put together a [brute-force solution](https://topaz.github.io/paste/#XQAAAQBDBAAAAAAAAAAUGQimgx+p6Nd2KTQBipD+ebHgWB2KYDhg0p5cT2fB6T5DWjG1mGzImJ/kMxYYski2R0EnsbD9DF3grfTnWe90IMbzhaDW4WiGLYZjXrM+/SmzHR9JwBqvEb4zsQ2dj3FKSP6OxJxreUccJIEvgbi4LjKXtUhxNe40qDl8DSS9h7DUMOup9fUxuPTx0mL4cgxRxXwzP1SXolNrWIqaIeRySLL+xqHk5qdYz4YgF8M+Yji7vb1/s6fj6MkkleWB1ugxORngfKvDSR5y4EeQRytPcHZCqWY+zNzGh7KciXn3Q+23tQvK6tEmHvKq9K/QcUn1aYxKHJLQHQup8Kd60xBQo81hImkTexgQfd6UbIZeJmAbxizkRmGiuCbYHgLcnDzMT30Fimb3sM4s9nFYbr7W4rAxzNVhn+Bd/NDK8JtQDB2OFPRC47sERu/1Cm5gKJWCrv9XpNfIdUDYx8ei1hh5ESnFidaugWaEhu+N1rWGbu+j0osqaMSX4OSV/82ZuEs=) that _ultimately_ got me the two stars for the day
- Last but not least, I could not see that the monad would do the same operations over and over again and that memoization could have helped pruning lots of the dead ends; instead, I let the thing run for hours (true story: I went outside, had a few drinks with friends, and on my return, the solution was there ready for me to submit it).  Cherry on top: using ERROR to notify when a valid model number was found -- a clear sign of burn-out from my side lol

Well, what else to say? Another great problem, with quite a few things to learn from!

Advent of Code: [2021/23](https://adventofcode.com/2021/day/23)

Continues:

We are given a diagram of the situation (your puzzle input), for example:

The amphipods would like a method to organize every amphipod into side rooms so that each side room contains one type of amphipod and the types are sorted `A`-`D` going left to right, like this:

Amphipods can move up, down, left, right, but there is a cost attached to each movement:

In addition, amphipods are not free to move wherever they want:

>

OK, so given all these rules, and given the energy that each amphipod uses to make a move, we need to help the amphipods organize themselves and at the same time minimize the energy required to do that:

Input first:

- we will be parsing the burrow into a CHARACTER 2D array
- we will also keep track, separately, of the `(row col)` locations of all the siderooms -- bottom ones first!

Next, a little constant for all the _valid_ locations in the hallway (i.e. the ones **not** facing any rooms):

We are going to treat this as a search problem:

- Starting the input situation
- We try to move every amphipod that can actually be moved (as per the rules above) -- POSSIBLE-MOVES
- We keep on doing this until each amphipod is in the right room

Note: we don't have a heuristic to play with, hence we will go with Dijkstra's algorithm, and not A*.

Let's now take a look at DONEP, the function used to break out of the search loop:

- For each sideroom -- a sideroom is characterized by a type (i.e. `#\A`, `#\B`, `#\C`, and `#\D`) and a location
- We check if it's occupied by an amphipod of matching type
- If not, it means we are not done yet

We now have to figure out, given the current amphipods configuration, all the possible moves that do not violate any of the rules above; we will do this in two steps: first we will try to move amphipods from their current (and likely wrong) room into the hallway; next from the hallway into to the _correct_ room/sideroom.

For the first part, i.e. out of the current sideroom, and into the hallway:

- For each sideroom location
- If it's empty or occupied by an amphipod already in the right place, we move on
- Otherwise, for each valid position in the hallway
- If not blocked, we move into that location

For the second step instead, i.e. out of the hallway, and into the _right_ room / sideroom:

- For each hallway location
- If occupied by a amphipod (of type `type`)
- For each of of the siderooms for type `type` (from the bottom one, up to the top)
- If not blocked, we move into that location
- As we scan the siderooms of type `type`, bottom up, we stop as soon as we bump into a location occupied by an amphipod of the wrong type -- it does not make sense to move any amphipod into any sideroom above the current one, occupied by the wrong amphipod, if later on we would be forced to make space to let the amphipod out of this room and into their right one

We add two locally defined functions, ADD-MOVE, responsible for:

- Creating a copy of the current situation, i.e. the burrow
- Swapping the content of `pos` with `target`, i.e. we move `pos` into `target`
- Calculating the cost to move there, i.e. manhattan distance times the amphipod unitary energy cost

We wrap this all into a DEFUN, and there is our POSSIBLE-MOVES complete definition, in all its glory:

Let's now take a look at IN-PLACE-P, the function responsible for figuring out if the amphipod at position `pos` needs to move out of the way or not:

- We get the amphipod type first
- Then for each sideroom of the same type (again, bottom up)
- If the location of the room matches with the position of the amphipod, then we the amphipod is already in place
- Otherwise we check if that sideroom is occupied by an amphipod of the right type
- If the types match, we move to the next sideroom (i.e. the one above)
- Otherwise it means the amphipod needs to move into the hallway

The last missing piece of the puzzle, BLOCKEDP; we know our starting position, `pos`, and we know where we are headeded, `target`; all we have to do is to check all the locations _along the way_ and break out if any of them is occupied by another amphipod.  But what are all the locations along the way?  If we are inside a room, we need to move vertically first to get to the hallway, and then horizontally; otherwise, horizontally first to get in front of the room, and then vertically into the sideroom:

- We destruct `pos` and `target` into their row / col components
- Then using the spaceship operator <=> we figure out which direction we need to move horizontally to get from `pos` to `target`
- Then, we check if `pos` is in the hallway
- If it is, we move up first, then horizontally
- Otherwise, horizontally first, and then down into the room

And that's it:

Let's take a look at part 2.  It begins with:

Uh oh...

>

>

OK, let's _massage_ our input as instructed:

And that's it -- our part 1 solution should be well equipped to deal with the bigger burrow!

Final plumbing:

Test run:

Nice!

Unfortunately, I was not able to solve this problem on time; actually, I could not solve this until a couple of days after Christmas.  In addition, the [solution](https://topaz.github.io/paste/#XQAAAQDMIAAAAAAAAAAUGQimgulVPYrJhMVjyYOkoNMRrPzuMVk/CekO/LruVC9Ms1jGXD3R2Xlv5UJlKv+s2h7+RTSP3QyatBEOZf/6fJFeUYm3COdf7TjD+XiU8nnIhdlmU0sqbnEce3WEEZT8fVJzKzYGaenESgPH65+4oNltMKuRZg8ao2GtPWXf8DnPXqqfbnFIsTeDvaTSGfGvdU9GUnQcBljQ9K6Nw62ag26yS8cwUZM/bCRnajawkIc2weuEY/hmFsnGIZxPhCSIQv7WZjvc+kaKuCbmoC7YAP3d0c7vaOVDEMl8PwCANg/SZTB/sfaFOPtnGTv8Aw/ZllojmEAwPe6v5CCwiNzIMs2pWUE3AuVriSTxOZYEb2kkrzpIzLelBDL3h1xDxMmaEMTyF6FcxebFSEUbdi5gCjNtETqx/6YsOJ2izvZyVGVV20ZX8pvHfkrZF2dDiK2CsQUpshHYh70NioDVWqVT6C5+MIxmuSWYE3gMVGJ+34O+ZspJOAiEsGsKofsG6U/l1up9CudsT49cOlUVLNwxS417crs99EZqzLUdVNcV202tbGHGYKxjKr+C/1s6IBE2lOSYkovTgEjPHj1LqrzyXSXDCOAcdwaLHbm/3xICgVMBOjUZX4YnbmWpuU4K7Lz2h/1aMnZ0jd1fE/UMwug8thiL1zUnk/xM3/5JcYhbrJ8QpDQCOLP1CL2VVj8BdN20hldXz/YXxAgGC/vpaIp88uS9l6km595sHdXAQlV1uc+tY3Dw/HpL7nt1Oy2tUSzsmTbSuSt3gVq3zrspMLvorORLUL/1OP/8ptBJ/7I3ZKDbIkRp31hQBuhUGtchpJWrCelDqLHBZS9196+ilHJ1YnjAoHVc2gBDDtplDUcqd9nBF/AT9Gxi9oOmQGgBSPkQveQxrQiyWjQU1rXHWKDO9KHvjb8m4vXBCladiph1PygKi/cNvmHEJeo+wtwDX8RL/T69B3AAi6Xy9y+/aF2KF3USpeYkGl9bXX/UV8GzI4dNnqJXS3VEunEjaK50B/Z7ZjLcSisiNdH1mcgp35yzegmbULYgn6m3X6UMGMrwENtR2CAXXX0renSLm0GZYQ5t1sao7iazmv26Q4KCjg66PQPlw33Z8loRnLhzQ5CvDeW2RFWb6Bx92mDaNroqrhYhirq5jmtwaLFCIM7/UYtNvmSCxL5bIzqfjvycajG/0G3gkv4aeASr2kdbQuET1wOky/53hlsJmzG2GR7gF1gzSZwHWiu/PscBM3Qme2VA9kV2CiQx0HHEd9VM1LjmO7os/I7tUUspmwzuH3RFdX/YSOJ2U5Til55ns4/ki0qhjPcU8z4CFgvqrSIyv4gh9muPYP2OHN2duPrNh3T1OV9OfDnnSIYj6sPDBzFvfsCd84Fcj/LioSVKTkAsggTg/bw4/5bSlHr8LZpZS+CTOT7qRGOIfXKCLNAMQ9kXPYNW9wB3tsnlPy10RZIE/Q99PG6ALFJeknjKSDd1gBC6LCYQHTJyTFLXt3FPkQw8tq/HEyP3yuXtimfm2pWAmNXP9oCyuf73v2uHS8clt6EPMSTMOcVfv+6kI5ZrAHDKk80hlbGq8OvyG5Rmitr1an8gOoHbmUTAkjc36GpdGhS0ILoAR4wDIVwLeuGwggQeNNep1JLCKN5D5bN1pyfgwI0Q0Qpj8p8d/Is7vkgZrPW6JApPNAsRvhHB5aUVr6W4/gEcCTWn+KHUQ7Bj4AqnwHLwXmWmzKdRULMM+4OGs+xYMaHB0GR9Dbt7oHqpRng8Sv0e68LlP2rWZO2kq9zkxunEYf2KA6QOB2pfAz7B5DdDtVGFWLIra/WG7ODKfeMthR14vY3foNDwg2B7nQE1ePGzmIyLALxf/c1u8efki3ERj8PMwrok+eJ/HR0RmwP35YGYbhfGq94R9sry1amPvlquBI8ipNx1IG3ain0JX0172IgZpvsPe/jbIyzCu/EUZaUGIOSPp/eoVpkNZ62E8VHLtpi23n52xRdYMj0cA64EHSciXL169QdRwYTTw4iluj/D3tVkce92ZOMW2F/CQs4mJUSZiZWw31euDnYDVZWO7yH98PFM6XajEsV3J74muooEA89szjItMuBrx8Zax6pmznTZfHaIh/9nW73Lzmf82wsd1pKIu6ylYjWbijMXWlFyPKG7jFpOTUOQjN0LEESDkjOOhhneuoKbbKWJjiOYkt8gpgNNWjz1Zsiy//Mj1U55JIHMfEe79iA7fcmiMckT9T0I6c1KrgZklYNErsOuF9bVQfAxqWUZaJ7gZCshwckMI7STzOsupvQV6JEMk2dsMPOuuDmjKuND93MBuEb9AyV4MoyoR3PyYWbaL6JRbLj291lXd+XyDAtUMdpSAvPKtN13KAgHuywMslkYFHdjSP8uLWvYcupGKzHYG3ceUpnBgh1lqweJOxnZ4rmvOOApFgqnIXh4ww3yH9MgvTw8gEwoNFZU186OyIzOFrJFPkRJ+DcBWSMi5weqOBEKb1zdCqvEIrRnPCOR9J51976qmOV5bNXfyUKAEgARdjgoEeA85Wh5A6Rzf/+DdtYAz/BLd44yRpnAUTQ6IjWNoW4ySzZBtOUAIkOy/tO8ArYaY5nNYMKxGkICAEUEWh1K4ULTEupaF0m2QeMtPufvwwOmVHdINMF4YKobMNondrDtyWKwgRQ9xvS5jnLtRTIv4OWMKVUS1bRD0rynV4f/knwKtg==) I came up with back then was not nearly as efficient as this one: around 8 seconds for part 1, while for part 2...

What did I get so wrong, back then, to achieve such a huge runtime? Well, a few things actually.

First, I did not realize I was _pre-calculating_ all the costs to move between any two locations, over and over again every time A* would invoke my heuristic function...WTF?!  Well, I did realize my solution was taking forever to run, so I came up with the following heuristic hoping that this would speed things up a little:

- For each amphipod type
- We find where these amphipods are
- We find the minimal cost to move them in place, as if no other amphipod could get into our way (e.g. with two amphipods, `A1` and `A2`, and the two siderooms, `R1` and `R2`, we have two possible scenarios: `A1` moves into `R1` and `A2` into `R2`, or `A1` moves into `R2` and `A2` into `R1`; we try both, and pick whichever costs less)
- We sum all these minimum costs together, and that's it

_But we cannot calculate all these costs, all the time, right?_  So we are going to pre-calculate these, _once_,  and then look the values up:

Except...I did a silly mistake on the calling site:

Spot the problem? It's the use of PARTIAL-1!  Let's MACROEXPAND-1 it:

I am not exactly sure what I was thinking, but I guess I thought it would create a new local binding, assign to it the result of `(calculate-all-costs opens)`, and than pass that along to HEURISTIC; instead, PARTIAL-1 is keeping all its input forms as they are, meaning CALCULATE-ALL-COSTS would be invoked over and over again!  Oh boy...

Something else that I did, and that only later I realized was not beneficial at all (in terms of performance) was keeping track of the number of moves each amphipod had made (and of course backtrack when any of them did two and still found itself _not in place_).  The thing is, we only allow two types of moves, from a room to the hallway, and vice versa, and each move has a cost attached to it; so why care if an amphipod keeps on bouncing back and forth between the same two locations, especially if it does not make the burrow anymore organized than it was before?  The cost to get to that state would simply increase over time, and after a bit A* would simply pick a different, and cheaper branch.  My original solution (**without** the heuristic!) would take around 316s to organize the example burrow situation, and when I changed it to stop keeping track of the amphipod moves and simply let A* do its thing, the runtime went down to 264s.  Still a lot, but definitely better.

Last but not least: search state representation.  My [A*](https://topaz.github.io/paste/#XQAAAQDdBwAAAAAAAAAUGQimgx+p6Nchs0/Hc3cRxcmyfeV+Bzi2FxeDDBZEkgZaDBSyRjbUkuFXP6dhVAaOH8AG99AzdDUHR/lSrXrRzt2ru8sshOcmQ5UeY7P5AZQhS4ncXon3a6r8j5K/gr4xuK1jjTG4PHnVajamzB6t54TV5dSPS63MDOK6jD6CsHfC+VkV4bms/+I8MmYXI4GU2JxpblEiXKntPh1orBPfGpyTCfhx4v+kHU29G6mF1Y4EM6ozuoAyzjwxpY0eKSSV1zFprANFIIlsaPqm/nWF9W4i224u0tUm3IHb+tnMDrFtscipbIplaGiZN8B2Q1apClGT/+51hyLVNGM+4prkx8VWxBWeWuN62LCmMrY0iqRvFeCwKqpwg4s4VRogYMgeG3AOyY1DlJ0UJFetXLjJ+7pMA+8jUmYyE6xRJd9R+jn/cPnkNyDceLd1iFB/ODUgVXLcyrYb7jFIIeucRNGqkgQ7lwe0xvmyiBLkHyIe3ML8lZQcmhyinz9Ynab880cOGsBYBuTRjCS7dCvLr5XKDjw8SpdnWXgjVrzLA49wE+NZXVkPz6tTVzFUR36unRBsIJZJKfYRi3ZUToT1eFyKKayvxZpI9V1QkNJvJehPwqf797u2T57qMuE1UrtnhSso1kQh/BEo33aCHrNXfO/H71RV95KbXakyaLfqTAeeKA2hUrQSbAFnewyRS+3eKmTvbe0+XL1ltwMKAccDiSJR+DZ8iMZhQx91qBpU6W4Gu5c+XA4oT8DFrhGWR1aHzdLLf2ICtG8VUVnLizIL/+Wv790=) implementation, makes use of two HASH-TABLEs internally:

- `cost-so-far`, mapping from a given search state, to the cost required to get there -- required to build up the final cost
- `come-from`, mapping from a given search state, to the state before it -- required to build up the list of steps to get to the goal state

And as it turns out, putting HASH-TABLEs (my original representation of the burrow) inside another HASH-TABLE (e.g. `cost-so-far` or `come-from`) can slow things down...**a lot**; I am not entirely sure why, but I guess it has something to do with the EQUALP function performing way better on ARRAYs than HASH-TABLEs.  Let's put together a little experiment to showcase this:

- We initialize our `cost-so-far` and `come-from` hash tables
- We initialize our burrow, with 20 elements
- Then, 10000 times
- We copy the burrow
- Move two random elements
- Save the new state inside `cost-so-far` and `come-from`

First we do this, with the burrow backed by a HASH-TABLE:

Then, with the burrow backed by a 2D ARRAY:

/me gulps...

Ok...let's tweak the first experiment a little; let's serialize the burrow into a list of values (i.e. one value per location of the burrow), and see if that affects or not the runtime -- it surely will cons more than before:

It does cons more indeed, but the overall runtime is now comparable to the second experiment, the one in which we used the 2D array!

So I went on and [updated](https://topaz.github.io/paste/#XQAAAQBXCAAAAAAAAAAUGQimgx+p6Nchs0/Hc3cRxcmyfeV+Bzi2FxeDDBZEkgZaDBSyRjbUkuFXP6dhVAaOH8AG99AzdDUHQi11t+qsyRC3uWF4xf7knr94XFFlmAeHILKPJwTwqqiga/1AEzyjEmZm8Yje6+ZHdKsFZGwHMCe/PZHtbXN/DaFKTz/nMcvv0X0lc8AlYgDi14Hn9ISQyH9XRgO+JbXFpgPy71pVPWxKSeE9inD39mrgND27XXv7js03AL688VbWW8oZQyLz1u5RAXqcKElyltwGhlBEB6XVIKJAuaP/FuFdbS3SHHBNncyV7y7P6mMraqzuyU4MEyUWrNiUkhkRpwZbu/s+fvqjI9sdiDoQKZbnjy7V+/gv1v4wkhkkv1NrFjXEjD2+jiiJVJc431kuzbcB/juIWu+jV0SBCzURL96i8kES2htSfzAyxPuOqzuPoWZ+Q72smhX9RJXjeTq2pVRlpu0D1LNOiakkvMJxGtK1+HdQOGRD3UBQhw9POB14yS+g4KS8NBTn0hBS9r2IRYc/LmAfNjy9aBys2QEtgSx/fl03ASL6xd6y4VSCgeus+A+GGfcdRsNfXIvKnVjMx7XWksMgNbFGkpzejqIunal82kOYfSuIRv+cBTydZ4w5WCjVkePqmn+COe7U6k5LneS/8KgPSmFl+W0GjKFiOtWzF7yILs7M9ErGHAUEeuCpCcp+fMb5NXkNsedoDxc7zQNP0FO+XOTsktOJ1EWnf7RMjcC+XZr+kYITTwOplIy23GfpjIiQN7pwWJAF5O5hf03PlvWKriOw/3zKT9MbMIhP33+f4viqU/auPXhPLIpnkOX3IUyD2WjKYQVh5y7vs0s7/8K2ADA=) A* to accept a new `:state-key` argument to be used to transform search states into easier to EQUALP structures; I then [changed](https://topaz.github.io/paste/#XQAAAQA0EAAAAAAAAAAUGQimgulVPYrJhMVjyYOkoNMRrPzuMVk/CekO/LruVC9Ms1jGXD3R2Xlv5UJlKv+s2h7+RTSP2wDdB5SpbuTIPB6pqSVlqYlUsNiH6bdTOE5QKqdFl92a7Ozx1/mb/dNm2aI7MI+ZxX5n9plD5QGYOpO2b4mm1/FiuMP2shOFemQ/Wfwh8V+p129h/QDVtymp0AdnAEQOhyl+bp4E9+3xL2NcfGe1BSlhs0YyeE3zE8wJrVNf9GvX3K72f0cvPEq7Y3F5Bv4AxMtxLwKd6gOTIQXo/WttDCftDO9XmR3inU3/uaIviMgdOQt+DqZBy95/qjG9yOXUUmBYvAsF1fSiVBxiKa4/fNkL//VVW7gJnOGymMv+JdnfRgnPuKXr6K5ldamg5rh1TUe24OBDzxAyGrjcc5J0nAG/ug8002ZOFrZEVa09UhGe1gYuGG3zmGD7zXGZIzmOefMWykGdUaZkRMWV1EyTvmPUu45wHk06qlY8VO4v5k9eZBWnlqvubobMmlUsYNfyP+ytl89kzRG9llQFOeHy5wj4qPrWbKDWOxIMyLMoufo6F9RQwcQWugoxqZ2+bN8agbTYfs5jbEMFuysB8OkPXs18Da6Lp0MJVk758pxSaCtHmJNHG2a0jc5hdLQ3a72g6+i/b/RaARny+CxcMX6ZszC3fWJzQq+33Xx2IPKvAnwWpDCQ9cVJ+AwPEWe/m06hVs4gpSJGVSfM9M5Gkigl9erK6cesztVVhlGAGUOX5C7f/Nug2IwTH/xAUEonOzKIUofdgkxExwuMwh3+7P1UQpbP4cccrjSP8BJGwgjWEn2KpF0j6Q3xIx82P3kUkiY3JIiWY+bV7WhJNGSdoqcMYNOLTZdAykAQ6hIHFqfV8JRz3ml17yG6GroygkZ3lO7d9X93p9TzrbKibQ3cfZ8l5M1Dm3uY+wPggdZj9mx//MrifxUqQulfVnTS4tUQWlqqnQ6rGpUdbjc34k2U5Wdb+PEwf+YA5rC7+jYTbUz+wZG8v/yPHuQchRr0w4wI6yvg14V+cRthX5AemM9pUDhBFjRFCerJ9XlNVdvU2UIrYhtqKDF63OintpoEnlyA9iqtheBIdRxiUsWyZnfhI9U49ahnaOjO2l21fMOZzwzJmT/5BxIvU91gDUlqJ/VnLI/KV2gIVlJulaigucc77sDzEkxB/5GW0lbXE9hXBbMoDehA3Sx6VsSzAQfRde1tklW+v+YyiAnhaD4i57j+W6KZOBd5lrS0On+gXcQSX9JJdjqkrB5MzOmQTb5+88+i5V1uU+8pwZmXxjMEuEGE0+eIFkmAOyzWI0ggGkCIuWNtnadXjWG3bLKcPFRWCl01YIuWBp8qVe7txAggenOaGnnAKF6PJsuP4QNaPY64+Omb5jkmK+i7oli8mTzBv93BVS9csxalztzUF/zlzveWfRWTm3fSR2dJbXI6o5c6m1TtBgdH0CsJRv4lebrKOlFIE98fYubgxL9XkKSOA0vuQtWeFjzq9tAb6Sl4UXnKWutcUnbZtsysRHEj36u7Hktd8QtA8+UpLkXKaDx6vZ5E95IbVCshSbw7irz3/bIVOAcxyExnprnrFmSneaPwOTpwFddbYcKhMJhSKuOqCn4JIhwz40VXkRd/W38RZo9DKS3PHAqQD+T5isN95R4WP7BlrzlDB/L+j9lB3GKTRcLDvEz7e9m+2dsMTb9aWaB5/HRMnZDvzu0x00SuBfQiQiP3NydjG1M/ECIhDvkVbDt563KmpWj/GDTXU/vFg9m3URYO9LD606zyyF9P00OGUDlvsnywI7BxrOr/O7/8AA==) the calling site of A* to leverage this new argument and serialize the burrow into a mere list of amphipods; and with this:

- Part 1 with the example configuration would now complete in less than 1 second (that's a 100x speed up!!!)
- Part 1 with my input would complete in less than 8 seconds, while part 2 in less than 11 seconds

That's huge.  It's still better to use a 2D array instead of a HASH-TABLE, but at least I would not have to wait minutes to see an answer!

From 40 minutes, to 3 seconds...what a ride!

Advent of Code: [2021/22](https://adventofcode.com/2021/day/22)

We overloaded the submarine's reactor, and we need to reboot it:

Continues:

For example, this is how our input is going to look like:

Let's begin by parsing this; for each line, we are going to be creating a tuple containing:

- :ON/:OFF as first element
- Min and max x values, as second and third argument
- Min and max y values, as fourth and fifth argument
- Min and max z values, as sixth and seventh argument

Let's keep on reading:

OK...

Easy peasy:

- For each instruction
- _Clip_ the cuboid to the given -/+50 units region
- For each 1x1x1 cuboid in the resulting region, turn it on or off accordingly
- At the end, count the 1x1x1 cuboids which are on

Part 2 starts with:

>

Note: the text contains an example, the solution of which seems to be: `2758514936282235`.  So I am afraid we won't be able to bruteforce this -- not naively at least!

The solution that I ended up implementing, which honestly took me way too long to get to and that only later on I found out that in literature it goes under the name of: [**coordinate compression**](https://stackoverflow.com/a/29532057), builds on the idea that we could _merge_ together adjacent cuboids if a) they are in the same state, i.e. :ON or :OFF, and b) if the final shape is still a cuboid.

So, if we figured out a way to _split_ all the input cuboids (possibly overlapping) into another set of **non-overlapping** cuboids, we could then solve the problem as follows:

- First we build a 3D array, where each element represents the state of a **non-overlapping** cuboid -- we will use a BIT array for this
- Then, for each input cuboid
- We figure out which **non-overlapping** cuboid it covers, and turn that on / off accordingly -- here we turn on / off the NxMxO cuboid, not each of its 1x1x1 ones
- When done turning processing input instructions, we scan the grid of the **non-overlapping** cuboids, and sum up the _volume_ of the ones which are on

The above should translate into the following function -- We are going to be looking into COMPRESS-COORDINATES in a sec:

So how can we split the complete 3d space into a set of **non-overlapping** cuboids?  Well, we could use all the distinct `x1`, `x2`, `y1`, `y2`, `z1` and `z2` values mentioned in the input instructions; unfortunately though, this choice would still result in a list of overlapping cuboids, and that's because all the `*2` values mentioned in the input instructions turn out to be inclusive.  So, what can we do instead? We could use all the `v1` and `(1+ v2)` values, and _that_ would for sure result in a set of **non-overlapping** cuboids.

And that's it!

Final plumbing:

Test run:

Unfortunately this takes quite some time to generate the correct answer for part 2, but I am not sure what we could do to speed things up a bit.  When I timed the two LOOP forms of PART2 inside:

And run the test again I got the following:

Which means the two thirds of the run time are spent while scanning the grid of non overlapping cuboids (FYI, it's a `828x836x828` 3D array, with `573148224` elements in it).  I am going to leave this for now, but if anyone had any idea on how to optimize this, do reach out.

For comparison, my [original solution](https://topaz.github.io/paste/#XQAAAQDzDQAAAAAAAAAUGQimgx+p6PZhRh7uIO5BVe7pcMkiG6eOV22j2MYKuFs91c+ybCSTgFinLxYMDBog9+D9wK6Mym3ryCQmnaAMvpJKQHyEdtVsPNjjYnuytyD7Qrf6bGu6LFg1BiAQ72xs23DoX1Ss84dXIY34R1KEstD5kaS3TZaBhOkCRt1rui/F8X46S4FNkH8lmNyXe65HGJxbLmM5AxC70fIrc01PnIeYXoBYDXOWDzVB/LWRj/aG+TH+ub2IlKnO2F+v6DYfX2gwfzmZLlgQw+QhaHr0GPGmPWgaMnfHgKe7blNOvRP1NRvQ6FTbxw5mMV1TIJxFCc/lapiFsx6hxF5SPmxBQe6Btb2qY+fbFBRVnoSuvtD2+klndh7SHKu9rsBkp+sXSacQCv1uey4f7dheHjB0H+G4gQK3CvxjXd1ePXR972yZ/R5KQ789h7lPj5gU+zhSC3ckrECpA9D0pqD5j3hr2RXNun3RxEY9/u9KM29QW8U24xifKkVT9ugCuaB1JcAOFPluLox+xz+5z0lFEyXVGnLPN6i+zx2xnZiJ1Hwxt/irXSdaV2Y/hqGyxagGeuOSFBUxhropP0WtGMcggJ7h+uTFi03SUVFSdAMdE89APmygn4tZ8Ao54unEWsiD9ePqp/LcGKnOcgdq3fJkE47Alx9QR2F8DQKau80zfX3qYOOOTzXqAxVk8aUbZOtMV6iz5GUr5798oXsSWXKn0/ghAnO7GjQrOCbeGz7uYBi4u1E7ehUSfpJG+MKlo4fpL7Jyf7Nmn1nAACLn/he+SIWsa/6VkYIQT0IJis/C3tuiGeOEicXwvpjNNuR4n5czJY0Ta0UyWnbyftmHNNakZXKJcGWEZq4p0XFuLuzZqfp22bwwxOJWEIPTmPCrYL3bgpoaDpFbJhAc8T07WauEsQbDJA4UzfSAA1yClQpeW3HG6LUOTdM5s+q5ef7uEkxOZ8lqdbwVVJqh1R5NI5ITL2u2tXpWlH7thLThrYBccNXPxqFWlQLlFWWkgwQbkxqrx5NrygPJ2qqvBUHE2mFQic9ovGOTTF1T9Dj9FMQ7OL1TZ46ZtHbZynWaYYwnPpTfyZQDXPjuvpgPtYA9TWuq0dXupWhex6Nfi+OqXuzxtnDtLUgUpHl+ps8Wq1jEGk4jWijdseIIRMaur9U8U7Sv2nMAr0JFrbS7b8AOc+jkFxDNtOwNvkkn4oIMzrRiTKAecYWCMpERpIDgJEYI6RbyzeWrv073RkOY00F9LYH2uIP86bmY5cBcapqcu4cDzpbgIv6HZGV50onnbTTFfJ5pKTHt4mGefrymPqzdSKJF9uXVM+EMtJw6iSFT4pt6XOf/PbBBAA==) took around twice as much to get the answer for part 2.  What did I do wrong, there?! Well, as I moped things up for this entry, I realized that we could speed things up a little bit by a) using **binary search** instead of a linear scan to find the min / max indices of the **non-overlapping** cuboids, but most importantly, b) we could do this search **once** per input instruction (i.e. once for each `x1`, `(1+ x2)`, `y1`, `(1+ y2)`, `z1`, `(1+ z2)` value) instead of doing this over and over again inside each one of the nested LOOP forms.

Live and learn!

Advent of Code: [2021/21](https://adventofcode.com/2021/day/21)

We have been challenged by the computer to play a game with it:

Continues:

The task:

As usual, let's worry about our the input first; this is what we are expecting:

And we are going to parse this into a CONS cell, with accessors functions for each player starting position:

Now...to get the answer for part 1, we are just going to have to simulate the game:

- Each player score starts at `0`
- We initialize `last-die` to `100`, and `roll-count` to `0`
- We roll the die thrice, and store its sum, taking care of applying the _right_ wrap around logic
- We increase `last-die` by 3 -- again, taking care of applying the _right_ wrap around logic
- We move player 1 forward
- We increase its score
- We increase the die roll count
- If player one won, we stop; otherwise, we recurse and swap player 1 data with with player 2 one

MOD1's job is simply to apply the _right_ wrap around logic, i.e. if the new value is equal to the maximum value, then set it to `1`:

Now that we're warmed up, it's time to play the real game -- part 2:

>

>

The task:

Again...we are going to simulate this.

Let's suppose we had a COUNT-WINS function, capable of telling us, given each player positions, how many times each player would win; with it, getting the answer for part 2 would be as simple as calling MAX with each player win count:

Nice! Let's now see what our COUNT-WINS function is going to look like:

- Each player rolls the three-faced die, thrice, and collect its score
- If it won, we increase the player win counter
- Otherwise, we let the other player play, and collect win count accordingly (when recursing, player 1 and player 2 data is swapped, so the win counts will be swapped as well)

The problem with this naive solutions is that it will take forever to run; the text for part 2 should have hinted us about this:

Let's think about this:

- each player maximum score is `29` -- worst case, it started off position `20` (with a score of `20`) and rolled three `3`
- the same is valid for player positions

So maybe there aren't that many _distinct_ states after all; maybe we can _memoize_ all these calls?!

Well, it turns out we can, and it will work pretty fast too!

Final plumbing:

Test run:

And that's it!

As I was trying to clean this up and make use of my custom DEFUN/MEMO macro, I realized it was not properly supporting functions with `&optional` and `&aux` arguments:

So I went on, and fixed it -- pay attention to EXPAND-DEFUN/MEMO-KEYABLE-ARGS, in which we:

- Skip `&optional`
- Skip `&key`
- Skip `&rest` and the following parameter
- Exit on `&aux`
- _Unwrap_ optional / key parameter

With this, COUNT-WINS can be updated as follows:

(Yes, all we did was replacing DEFUN with DEFUN/MEMO)

Advent of Code: [2021/20](https://adventofcode.com/2021/day/20)

For example:

The first section is the **image enhancement algorithm**.  The second section is the **input image**, a two-dimensional grid of light pixels (`#`) and dark pixels (`.`).

The task for the day:

OK, first off, the input:

- A tuple
- First element is the algorithm, with all the `#` and `.` characters replaced with Ts and NILs
- The second element, a HASH-TABLE mapping from `(row col)` pairs, to whether the pixel was on (T), or not (NIL)

Next, the core of the enhance algorithm:

- All the pixels are enhanced at the same time, so start off by copying the current image
- Then, for each pixel -- plus some extra ones, to properly account account for the enhancements happening on the border of the image
- We fetch the 3x3 block centered on _that_ pixel -- NEIGHBORS9
- We convert that into an index
- We use that to access the algorithm and figure out whether the pixel will be on or off

NEIGHBORS9 simply checks all the adjacent positions (including the current one), and does this in the _right_ order -- fail to do so, and we would be accessing elements of the enhancement algorithm wrong!

Inside AS-BINARY, we scan the input list of surrounding pixels, and thanks to DPB and BYTE we construct the index to use while accessing the enhancement algorithm:

The last bit: the guy that does the enhancement, a given number of times (`2` in our case), and that finally returns the number of pixels which are on:

Feed this our input, and we should be getting our result back...right?!  Well...no!

As it turns out, the first entry of the enhancement algorithm is a `#`; that entry can only be accessed with index `0` which can only be obtained for pixels centered around a 3x3 with all the pixels off; now, since our image is _infinite_, and since all the surrounding pixels not specified by our input are expected to be off, that means that after the first enhancement step...**all the surrounding pixels will be on...WTF?!**

Well, lucky for us, the last element of the enhancement algorithm is a `.`, which means that a 3x3 block with all the pixels turned on will cause the middle one to be turned off; so maybe, if after the first iteration all the _background_ pixels will be turned on, after the second one they would all be turned off again.

OK, let's start by changing ENHANCE to check for the current enhancement step, and use that information to decide what the background state is going to be (i.e. it should be on, T, for all the odd steps):

Next we update ENHANCEMENT-STEP to use `background-lit-p` accordingly (i.e. use that when accessing a pixel which is outside of the current image):

Calling ENHANCE on the input image should now work as expected.

What about part 2?  It looks like `2` steps were not enough:

Easy peasy -- the code we have for part 1 will work for part 2 as well!

Final plumbing:

Test run:

Well, that conses a lot, but again...it gets the job done, so I am going to keep it as is for now!  Maybe I could use a 2D BIT array, rather than a HASH-TABLE of Ts and NILs?

PS. As usual, my [REPL buffer](https://topaz.github.io/paste/#XQAAAQBRCgAAAAAAAAAUGQimgx+p6PZhRh7uIO5BVNPIdM7CxikuU7ERkd0dQuCDrZBhpxZTCueZNLCEOlFkCLmeqCJZFrxgbEMOXRzMoYJB/FMrFs8T4gJnMYA3TPqI3D5vjVHPr1ZfdXnTvjYJBkm6A/55PkeXgxNmxzw3LW7bJ0kUiMhOp6QbHb2yWa8RAgVsSF0ty2N7peZQ76w6a8ZVyDteIUd5jJxoqqPOE8oBWOjlb8NquqBmrq4rss2WDa1qyYznBxpJBUT/pZULLTPsKTfDwp5rT5gp+dGNnfoqSwkGzc32cfjmmEYQQiT7cqMgAgDNOAX5vWFDGdudGXY9Qu7SaTQdPgBCVOc8r/y6qgUKDvREdOixMDwECLpDGRtnBhJL9EJ76Fxmf1R7alP2C58s9yw8gzkzvM3EJzGmiABCfwiS7T/g6gx7gFz/32oGCvVFtgQ65rq3JfWMtNvooXIuGCBZ+fdsXzUv8UC+0GIejPoaYe3EIyXdBr4I//Pb3c0qM+TeCcKGEkSV32QnI6xshkfMIC98CwvKFXZaZLNjXfw52gPUFiKoZAomS3hYxzlPf4x7jP5e9LrWxGIEf2SGl69YuU2r2R1QJ9rAQIJ9/HBbX1+sh/TIBQGI+8t71PWDMHI7VzpUGU8RRQ9kjsd/MIDb2xNnLlzKatDYnhq+NUIhXfvIs4Q8nU+ptkfQd0HEtYHOE6mkea/iymvu72Wmqt0NMgI5vlFtuD+jj+QQRAksMjtVtA2dnqSaxbAet5W37ws30UvbcpI1zxZ47/tC6pc1OQmtdq2tdnAzToPU1ZDBryRsDy5Cc+d2s2pLa7LjCbrjFnGY+6GGqOB/Nidfzbt+nlTkxXydENby7ITRAiyv/JgmR3U9ve44B7lSntPwWR39Lbpk4exY/0AABHYeou36vUEfEJF/HfT0L+DAFQicFBvYteYCgrehEwePyMQLTu/jgUux+SRXDBG0s7n7yRZjbiYWIHuw84v3bYwxPI/cVvEAbizScOWYoBCDZj7whw2pZZ99hNv8f9RIBCeXuAbno+SRNCNpH+O1DrfA515YQCl4ep23IsSZxKx3o2FESuCqlcH+ZpTJaAO8MYjJb//VGo7k) -- it's not too bad...I have seen (and authored) worse!

Advent of Code: [2021/19](https://adventofcode.com/2021/day/19)

Solving today's problem took me way to long, so I am not going put together a full write-up for it, not yet, especially because my solution takes around 2 minutes to complete, and conses up like hell!

Very high level:

- We pick a scanner and check it against every other one, and see if they overlap
- To see if the two scanners overlap...
- ...we keep one as is, while rotate the other in all the 24 possible directions
- ...for each beacon of the first scanner, we calculate the relative distances with all the other beacons seen by the scanner
- ...for each beacon of the second scanner (the rotated one), we calculate the relative distances with all the others beacons seen by the scanner
- ...if these two sets of relative distances have at least 12 elements in common, then the two scanners overlap!
- ...do some math to return the scanner point, and the rotation matrix that we used to _orient_ the second scanner
- We now have a new scanner (with a new origin, and a new rotation matrix), so we can:
- ...convert the positions of the local beacons to the system of coordinates of the scanner used as reference
- ...use the new scanner to check against all of the others

Input parsing:

Some utilities to deal with matrices first:

The beef for part 1:

With part 1 done (and working!), part 2 should be pretty easy:

- With the same algorithm we used for part 1, we figure out the list of scanners -- FIND-SCANNERS is 99% copy-pasta of FIND-BEACONS
- Then we check each scanner against each other, and maximize the manhattan distance

Things have gotten...interesting!

Advent of Code: [2021/18](https://adventofcode.com/2021/day/18)

First off, it's the last _serious_ weekend before December 25th, so expect this **not** to be easy!

We descend into the ocean trench and encounter some snailfish; they say they saw the sleigh keys; they will tell us which direction the keys went only if we help them with a little math problem...sigh!

Continues:

OK.

>

>

OK..

OK...

OK....

OK.....

OK......

OK.......

Well, well, well...

OK, first off we need a way to represent snailfish numbers; nothing fancy, we are just going to parse these as list of objects (i.e. `[`, `]`, or a digit):

Let's confirm it's working as expected:

Now, adding two snailfish numbers together translates to:

- Append the second number to the first one
- Wrap it all up inside `[` and `]` characters
- Then _reduce_ the number

Let's do this:

To reduce a snailfish number:

- Try to _expode_ it
- On success, go back to the first step
- Otherwise, try to _split_ it
- On success, go back to the first step
- Otherwise the number is fully reduced, and there is not anything else we can do with it

_Exploding_ a snailfish number...now that's a tricky one!

To recap what we have to do:

- Find the first pair nested inside 4 pairs, say `[left, right]`
- Replace the current pair with `0`
- Add `left` to the first regular number _to the left_ of the exploded pair
- Add `right` to the first regular number _to the right_ of the exploded pair

We are going to be iterating over the tokens of the number; as we do it, we are going to keep track of:

- the depth of the current element -- increase it by `1` on each `[` element, decrease it by `1` on each `]` one
- the list of of processed elements, i.e. _to the left_, in the form of a stack
- the list of yet to process elements, i.e. _to the right_

This way, as soon as the depth of the current element equals `4` we will know we found the number to explode.

When this happens:

- The first element inside _to the left_ will be `left` in the recap above, i.e. the element to add to the first regular number _to the left_
- The second element instead will represent `right`
- The third one will be a `]` -- which we can discard, as the pair just exploded

The last step, is to re-assemble the number:

- We add `left` _to the left_, and reverse it (remember, it's a stack)
- Then we add the `0` in place of the exploded number
- We add `right` _to the right_, and append the result

It sounds a bit more complicated than it actually is, so hopefully the following will help understanding what the general idea is:

_Splitting_ a snailfish number on the other hand, should hopefully be easier:

- For each element of the number
- If it's not a regular number, or if it's smaller than `10`, we keep it as is
- Otherwise we found our number to split -- so we split it, and assemble things back together

OK, the last missing piece of the puzzle is calculating the _magnitude_ of a snailfish number:

- We are going to push the number elements into a stack
- When we find a `]` it means we found a _leaf_
- So the pop one item from the stack -- the `right` part of the pair
- We pop one more -- the `right` part of the pair
- We pop and discard one more -- the `[` char
- We do the _math_, i.e. `left * 3 + right * 2`, and push the result into the stack
- Eventually, the only element inside the stack will be the magnitude of the number:

Alright, time to implement the solution for part 1:

LOL!

Off to part 2:

We are just going to brute-force this, keeping into account that addition of snailfish numbers is not commutative:

And that's it!

Final plumbing:

Test run:

It conses up a bit more than I thought it would, but there are a lot of APPEND operations going on in there, so it's all right.

PS. I spent way too much time trying implement a _recursive_ solution for this, but I simply could not wrap my head around it so eventually I gave up and implemented the solution described above.  I did come back to it later though, and finally made it work, though I am not sure if the [recursive solution](https://topaz.github.io/paste/#XQAAAQCbDQAAAAAAAAAUGQimgx+p6PxOfQ0HAVSqOhDGRhLYS4AIXHNjFDrj6MgyqfWSlccS4l0btc+HyT+rEaJLGW07vOLFN859pjh40yell1zYamhcJsv23wn7PYA+QotQJxAOejK0GThz/3JyaALDPO1FOA2Oh9rE+UCIBjPgLv1KgU8B2d4Isir5AoL77R1bJFucR5fG0jnx96p8ADEKuWZ0eer/W2cSVC139qTnga4EZ4U7kIB2ZPkwHwcWifaKp8TShG6LsU1H1LWhjnTRVZ97yPEYWIUM5l91rQVYL2cYFl2IL6hQfK/lafy5migGPSHgDKGRfk0jH0OUfo11MRRUc9kABZzHtKemqfpmgoT2U90kOC4nxD/cTPqX7rvVZoQ0/ECO3Tl/TvbKf9vpSYdGa/6EWYLATSBYI+cHf+kDDhD02OabvQOUVgTmxPiadyqWbi5m4BF6cvHQiANd8pYaxslsvqWp6vVmBMST0Ruvyolglg6x26k3rEqar5xl9RccmxrU1T6xCOSFTGdkbZqAYwk7Yhtw8Tl2eKoC0URbBgWZgVeueZ8aVKnXKdgNRf1BJnuh0Lw1yKOseKlNNkROWE29DU6hDMKwB4WDCs6DRB9qaxN3he3YUQvXPyi3Zh9YQSWQPsjAuLkoKC0iEtjlqitQqdvrv83NcCFHwpnp8OQfOXrY4nKT6RZUnHR+vWaowZVr/51xUkrqatpUJpAGwlvcV4tz9xf5RE742xu0gbuImB1KcpaOM0InJmY+WuibPdpeT8WIAvXAxgsIB3g1aFwsf1MdWJFJhmlQ4B6TOHcBYEaBonWnQVlu+TwEnYeNTxY9qtUKG6qo1qzuhj/7/ziyiNM3ODOCsXMJmXRifRLAuk9Xl28hYHzB6nJtzvARYkM6tUhNBagB+gmsBqQPh4sW2Tv9e9usJv+vxDZQg69XxtW6Vc93rp4snBoDm+n/UzMZBywC1aq5T4//hie7AA==) reads any better than the _stack-based_ one!
PPS. Looking for today's REPL buffer?  It's a [mess](https://topaz.github.io/paste/#XQAAAQD4JwAAAAAAAAAUGQimgulVPYrJhMVjyYOkoNMRrPzuCgpk2vvB8zuHocU/UmwqVZ1sTCnaK0NdCN8xvWnzuO3o0oJ7tsGitzMD6VSohAXfG4WdBUVsQWHtwENe+DuLgLzypkLjE9jdVpaLDtkB1SAZOluLi6VUwc+cK6L7r5mNZ45uwXhWAEB+he1ylnjo1og34aLT4Olg97TfLchGgGxx69H0lWGppixzj8/Ye3xH7xNWjMK5AKgdRw4re0xAJ12W1NjC64skEPhp33qlfUuZhNG6AIF6HoaVw7ihxxO9DRx4hL6+/Q5/ymImMiOBk1M4n5RAa6xXaDGf8sN/YAETfEx688/kVaEJBiYf+ZgnAsMzGn1GLJp/KZipYjReUBGBkbnOzmIvQTaV2s96zAqBDtQz4A+vdGeIvc9QW+3OniYGyCYx5w4FTrh0CmhwVGq0Xk1v/jX/OYGOLx4ESnecHbJS3oH0Pxfivzi2dXqN2GByKB0HAZ3FXbN5icYs+DD3Ba0LGo3G7ajf+ivbM3aozm/vMnTVBCCTTwV9Nawdp5LKKANekBeTqyCKORZ3wDcbYMm5rIvIev2DzXKAj0t2VMFRCaSumE4EtKmgOk0/3+WYz/rFwh8WWBbmM1NijdBixwE2q6qmOdi+wU0r1Fagpga1vRO8F/x2Xn2S7R2QainlYiBMUO6KBbT2Tlow/gB4yrrllQA7NJEiEAxW9y+lgnRnanp94p0FJmT24eFQqahr1/JWUlZN3MWV0iXenX0DVa8u8RM9Sgptk8Ps8WrhBXJVvukOuSUy25jn8prYL3xSNeE9PVK5Y69m1X/AE0bwCX8pW0DLT7a80tuWRtsKamx8kXly2LUFTWCMYkSoZclYlQ3nChB0rrSqKpdpjpQU60/21r7hpA1MUbFI9n7BvDjfH6jhEdKxjt0AJxUEURu7zR2V/l+HH4A3ELNN99xN75pFQ9W1927WtkJdDn8RSSFvqGhIikV2nfrMc/fQZaJUsOfQ8XNxJM3/saiNKUj+zomYIKuVKsBPzgEc15uveinzmXFvOoATeXLAq4ASljHgaBJa9irXVtU1F58/rGkuipGoCSDDR0TGEL9MAgFPDFNAjPmwnSKcJoA9YthyXAhYj4oxhLqNXVVbQXuKD28S9RHQHZet1Zc06nVDixvsX1x7OYXb8eBX1avSMhBRqtczjUrxqMcOiWyQBkpqn/M8xVY/8FaoD1ELMH7Dqvxh7y6tLt+22UGMBIByrC89D7G0JVag4lseMvSbwpLkdScJqAz4TBoOpfG+PRmAqxcvWooCD3Bf0lRwXtzHEXN4brr2lAs1DMrU1nrDFhUy222kG1oUZNe9MckjVRAvlh6YSdmkI4pdNMEP+qrSd1mSQ+lNelL0ihRfpl7sxc+O7sQApbtMrEVOcWxTHaRcEgGmmVkLuIYmZ8HG4rnosSaOZTNLzV0nIRbB8L7Se03CQ6/qx6WFZip/LPW1TpsrtBlbJAPW/XTbMLyTXZT9QWxt9vKvRkdxBwauTXzPWnWkTWLuEmpOA0Jb8nHUpKs8F7qByf1iRlQlM7gea5zHT/tXeWitAZ7AewZK3FKMSOkf9xp9THmed/POhsAmt1jOqTSE2wmY/qgdv5HiVrm80LaESczOeI8l9E1VskJ/RVJ/RueYlI0fZaBoT9Li0DkJnkob6VeIfk1Lxwhp00besZ/7zMgYdp6QoTYIBpiUYlgyzaz757ooHonsb5QurgJRDaT91Bax2xP1gNODPr+y5UEv8cyo4JJgNgIWJVJkugn5Fi3dbln6aemOjc44/9RJ2zBLZ132TECJJ9gTPnpDruCrNDqroA962YmLDLQwPXH0YBJwu9GnUqvP3z24wyk93ytkIrPws7q42H7/6PnpI3uPN3XHwdHkeMw2KN/gCVcCoIJDZo8EFZek6xGROnZYPN8iaLYfDf5b8WH83awmetYvsO60RHx9mURTXwX8OpR+OVYALCbKj8J1wx2WyC/xvdb1TKoleEw5ReKdz+2s5plyO9SDudzNItxWtPDMAvuzSoJ5imnAsOoiuahS3W7LuKoxR60U85Ar34I62BWxxuGLmsZgNEwW0blsRRZpAm288VPHr/Lek9IcV3dXkl5USQJdKFBVrbw/knrnGgRFC6G4SF/joMXVq6fDUKPd/TmhYyUZcmmLmz2r4x8T2g5i18KkDEgkvamZ+WitpTMQ5wARz47L6z5PCSd74ble3VDQ+aFHAVK++mmkDfx2KdCMJCK+82s22cyO1G3j5Vn5R44EsUmyk8k3smaRoY71KYt4wWIbMsg/8mgdmr++pZd1bxNLWhzIhxIGqBVwIV0BQzherLiDMSZY9nc85mCzvBcrZz3ar+5b70cRXbnNjlwYRphta5ilxiY8Zjjj0okzz6OONYfCVCoPx5G3sNsq/7BBSvVnBJVDVZ56HSPdmnG0qQvQoScEmhaGa2MggqwdcbbbInyB3HZ3IITNI2qWBgkyl6gwTYlfcK9z4f+mGCONhMDtT/5oA/POEXuF0TciMfGpbqCG0+etGupHsaL79B2OABKIMuyFdaCiW7c6oJaCPnUpjvK2NPnRPNTq6CkvBm3yiNsjPdcMIg2hbeO+2lbbqzZDxW9gzre5wcOS2+saBulbuqijxa60wF/oyM7y1yJQfKhZqAYJKDOrpJKhFvtksepJ4IRcQ/WyzIaPPSSc2cTlpWS5OijgRUavVerCAT1ebCepnnQoG+D5BX+LOhURz4CrwoCSmkDfsqATXL4KciCKrHG60Yxa4K9cQLYO30xTSFKSKlA+l7oyxJ2DoBuHS6fece+pJtjmb2au8luaTqcTuQhMpboORdZlsKhDeLk2QlLibtwUOBROxRiBIGifPaaxC6FeYm2ykUtGDTHsDYnsktG8kkRfs5g5Ir97/Fsu8//8jFu7)...
PPPS. People on [r/adventofcode](https://www.reddit.com/r/adventofcode/comments/rizw2c/2021_day_18_solutions/hp14ia0/) have been mentioning [Zippers](https://en.wikipedia.org/wiki/Zipper_(data_structure)) as a way to solve today's problem; it's the first time I hear of them, so I might as well look into this again and implement an alternate solution!

Advent of Code: [2021/17](https://adventofcode.com/2021/day/17)

We treat ourselves with a little physics problem today:

Continues:

>

OK, let's create a PROBE structure with `x`, `y`, `vx` and `vy` slots, and let's add a MOVE function as well, implementing the _step_ logic above:

Here is an example input:

For this, we are going to create a new structure, AREA, having slots for the min / max `x` and `y` values it represents; we are also going to implement PARSE-INPUT to extract `x1`, `x2`, `y1`, and `y2` values from our input, and create a new AREA instance off of it:

To recap:

- We know the position where the probe is shot from, i.e. `0,0`
- We know where the target area is, i.e. our input
- We know how the probe moves
- We need to figure out the initial velocity which a) maximises the `y` value, and b) causes the probe to eventually hit the target area (without overshoot!)

We are going to brute-force it:

- For all the horizontal velocities in a _sensible_ range
- For all the vertical velocities in a _sensible_ range
- Shoot the probe
- Check that the probe does not miss the target area
- Maximise `y` values

The tricky part here, is of course to figure out some _sensible_ ranges to use, for the horizontal and vertical velocities, but let us worry about the simulation part first:

- We shoot
- We keep on moving the probe until it gets past the target
- We keep track of the maximum reached `y` value, and if the probe ever make it to the target area, we return it

A probe gets past the target area if its `y` value is smaller than the area _smallest_ `y` value:

On the other hand, a probe hits the target if its `x` and `y` coordinates are contained within the box defined by the target area min / max `x` and `y` values:

Now, let's do some guesswork to figure out some _sensible_ ranges to use for our horizontal and vertical velocities.

The maximum horizontal velocity we can shoot the probe at, is the maximum `x` value of the target area; one more, and we are going to miss the target:

What about its minimum value? Well, the probe loses speed at each step, and if we don't want to miss our target then it means the horizontal speed of the probe when it reaches the target area, has to be `0` at least; so, if we start from the minimum `x` value of the target area, and keep on _accelerating_ towards `x=0`, we should find our minimal horizontal velocity value:

On the vertical axis too we lose speed at every step; but what's interesting about this, is that if we shoot up with vertical speed equal to `10`, by the time the probe reaches `y=0` again (i.e. after it has decreased, reached its highest `y` value with vertical speed of `0`, and then came down again), its vertical speed would now be `-10`; also, the probe keeps on moving faster and faster after it has come back to `y=0`, and if we don't want miss our target, we cannot set the vertical speed any higher than _minus target's min `y` value_:

The minimum value?  Well, `0` of course, given that we are trying to shoot the probe as high as possible:

Cool!

We change our mind for part 2, and rather than focusing on shooting as high as possible, we want to count all the distinct velocities that cause the probe to hit target:

First we change SOLVE to cater for both part 1 and part 2 requirements:

- For each horizontal velocity
- For each vertical velocity
- If we eventually hit the target
- Maximize the highest `y` value reached by the trajectory
- And add `1` to a counter

We are not done yet!  We were trying to maximize the `y` value of our trajectories previously, so we had our VY-MIN always return `0`; well, for part 2 we need to look into negative vertical velocities too, and the smallest value is if we aimed at the smallest `y` value of the target area -- one more, and we would miss it!

And that's it!

Final plumbing:

Test run:

PS. Here is my [REPL buffer](https://topaz.github.io/paste/#XQAAAQDNCgAAAAAAAAAUGQimgx+p6PZhRh7uIPIyuyAIK6ZLP67xEPqz09kRR9BiodGX5LsCfgvy7BcuypYSfKKqx+AtXqQWFxe0nzhH61j8l3QKC7iUulObpvghgkmWSzGbWXfAo2DfFk/uD/VFsTKmOVQ8gM51BSHXEnuVpXLu3En+2I7QlQuk+v/qdHpkX1k2pvnzU3FY17neHkMiN07lznDaUuQ9FveRKi8KRjH0Tkbz6+e4b1GESJw0SPeXeqbQJIVjsbogeqPejiqBNkvWzwHsvNNDCUMoVFWzeK+lYgUPLHrDPQDnia5mR2YZnmkldkqJN8i1H6o70I47UqxX+Sr37anfTCLucm4vhiVOo9DnaqRoazpfALZhTmwAFxV1NNbaVoXrJtfuEDApdHKT1UPG9PBVcHC/huBEqL7oWGklWU7yaCvsjVgokBwUxOc8XFzV+HSM4BhNrlDcpVLIZGWnG2Ga1SM3IXYUV3/Dcmsux4713urVdHE84mZoY0ZsUmkxYlH5mGLtAL/kop2VawVsveSpBF4ZD7v3a+5fhP88J90bg2dxPi3Dj+wKaQqwq/CACIWwXVWmt+Ea1RstX9fcvOOqp2LY5FhBAaR0TyrEPa+iVawT/eboY2CiYDuQq33e/ENI3a2LYll5GBvMycU2RlaTL7xVXHfjt+lxmu74+DYOq0UosOCaou9aQaMwYlH2X8ecR9j0/t1Fsp+Yfuc8VZUE2jt9DQ1Ix1s3b63dHAG8V4YdtSjHutjGjrDsIZ2a5irbaD83PZsecsxhBgAXouytNJOBp5nwEAc1QFe3Z78PB6PuVU8JWvYQZn9sgVzGouy6LaVcfJfjvKbbTFnCFquXDpYrUf+mbDZak+pxubXUYZs+N6L9iua9OEBYhysjz7cCffsi9zHJI6aMkDC0H3on3i8sQwuhLC2vt/0FPvFLy6ubHhHS/BaKfoMu+whNzHLXFxr1Xf6a3B9yzxDFPpVB92TqaCebEaIG1rb0aTXIjl664T+qAiRBvwTbteQk3EIoKStPd7Cj1MOfuedOXhM/k9xXmxZglPi1LS9dPJlfqCHf3TgQFieew3CzCe0xkGTmzEQTQ2BkxH1Ijuv7/v1CKw==) for the day, and I kind of feel ashamed by the things you can see there:

- `x1` and `x2` are min / max, while `y1` and `y2` are max / min -- why?!
- PAST-TARGET-P was not working, so inside SIMULATE I ended up breaking out of the loop if the probe `y` value is smaller than `-200` -- lol
- With pen and paper I (thought I) figured out the _optimal_ vertical speed for part 1; but was not working with the input, hence the 1+
- For part 2 instead, I made the search space big enough to make it work with the example, and then feed the actual input to it -- and `304.470` seconds later, it spit out the right answer!

It's clear my brain is not _functioning_ too well under time pressure, but _whatever it takes_ right?! ;-)

Advent of Code: [2021/16](https://adventofcode.com/2021/day/16)

We reached open waters; we received a transmission form the Elves; the transmission uses Buoyancy Interchange Transmission System (BITS), a method for packing numeric expressions into a binary sequence; we need to figure out what the Elves want from us.

(It's one of those wordy problems, so sit tight!)

Easy:

Let's update PARSE-INPUT to account for that:

Now, we know we are going to be fiddling with bits a lot (well, `0` and `1` characters more than bits), so let's create ourselves BIN, a utility function to:

- extract a range of characters from a given string
- parse that into a binary number

PARSE-INTEGER already does all this, so BIN will just be a tiny wrapper around it:

Now we got everything we need to implement the parser.  Let's begin:

Continues:

OK, let's give PARSE-LITERAL a shot:

- We pop `1` bit from the stream, interpret it -- MOREP
- We pop `3` more bits from the stream, and _add_ it to `literal` -- we are reading `4` bits at a time, starting from the most significant ones, so for every group we need to multiply the current result by `16` and then add the current group to it
- We do this until there are no more groups to read
- When done, we return the literal value and the number of consumed characters

Cotninues:

>

>

OK, that's a lot to unpack, but let's see what we can do:

- We pop `1` bit and do a switch/case on it
- If `0`, we pop `15` bits (the number of bits used by the current packet sub-packets), and recurse into PARSE-PACKET until we cannot parse packets anymore (note: the `3` there is used to discard any padding value introduced by the hex to bin conversion)
- If `1` instead, we pop `11` bits and recurse into PARSE-PACKET a number of times equal to the number we just read
- Lastly, we return all the sub-packets we read, plus the number of consumed characters

All is left now, is to implement PARSE-PACKET:

- The first `3` bits represent the packet version
- The next `3` bits represent the packet type
- Next is the call to either PARSE-LITERAL or PARSE-OPERATOR
- The result is all wrapped up inside a PLIST with: `:version`, `:type`, `:literal`, and `:sub-packets`

OK, but what's the task for part 1?

- We take the `:version` of the current packet
- We recursively calculate the version-sum of all the sub-packets
- Finally we add it all up together

Cool!

For part 2 instead, we are asked to calculate the value of the expression the packet represents:

>

Of all the operators listed above, only three behave differently from builtins: >, <, and =; builtins all return T or NIL, while we want to return `1` or `0` here; let's fix that:

Again, another recursive solution:

- If the current packet is a _literal_ one, we return the value
- Otherwise we pick the _right_ operator function based on the type
- We recursively _evaluate_ all the sub-packets
- Finally apply the operator to the the values returned by the sub-packets

And that's it!

Final plumbing:

Test run:

Note: replacing APPLY with CONS inside PART2 will cause the function to actually output the AST of the expression stored inside the packet:

You feed that to EVAL, and there you will have the answer for part 2:

For comparison, here is the [code](https://topaz.github.io/paste/#XQAAAQDICwAAAAAAAAAUGQimgx+p6GAb9hHoZ3fvJbGJPjDLntuErw51NVAnlOviYJRwBSse/MwTGbUr6VRb/SGDBS7kDEyk5SGdBerzuXLz99I6xz4UE07I7T9xro7z8E3/5FvKuhBM1EyjH89HLViGE1wOfzuYF4dSuAU0kZjDxsAacWmaJ2GqNu7x7WpDV0pNg5DozIPKhOWVzh70FgJjwFGNxhijdV7azmNxn8SZ008PetsCLXUXQ1FT/jqVGAmTyqN/2vDApllBSrD13UxM0cWt63WWmkbx/xQzqCBsb4DoZb/w2+FqOQd83gKDS/YWR23w3BaG2T67KyKI1Zu0dbqWc3rr5M7rqtcyJM84KNZqz2hW3W27glGGzniv8ThG+pxCKZfptUY1/G2ZDQdAVOyVHeZN06972GEJJNtm6PD0PtRWy/Vac7vRmCYPh5K8FmWkQuEBYJAGqOD7jwn/8L9wX+E6jc35rN7bcf4phh/4OjrifPuV89u2hmK0juizfB24T9DBvuStiUgbAWf4pGLPMkQEDw2ADeL5tU121zh/Agza6vISnSjJ5efeWPNvWo68dqURjJRtO8l1mAWTKCsbsOe7VX3cvnu57rEbt6tfLejUcaUIdOuO+91RP4DtJ9n15vAiwuH3xMrz2q+8XT2A3EFbeh/ASEfcssk4hPcnopj7c6sVWLbY7sQpKjcCIYBRqxVR1aHZvV+XPIoix1x5SxSWv2Uj0hGfQesMP8fbKFNlflpC6tMebZ6u09GY+wnvWGBAiQV8HQL3SNF5kYOuqvaIy+2dX7cRtMKM0/sgg3SFKh75KtxYCY2RNSZE1jgTZtiLlsN+1Kh9WJNfMQhEUU0VdD1h24ZUPmQy7jDvXKGs1E/ddB1zxHVmNRz1L1poE18CJIcEOiFIqfgj4gubRTzFJsp8J1ZMJxi4h2N4ZNOersMTz7iRvzx1UkPK1uQS9WftxQ7CWueVHa6GGM3lABVXI0vW/GS2MZ1MSvc4/ZPSqrvx50dQIT4AR2fYE+s3R6bCAM612MP+q1lHcegVLv6Z2E5+Z+rVH1eEOk/3wFkc31NjP98pIJPoil/i6m9Yfuuh5tscRUqoDRUF58qlwxU2zXIlnjv9T3KcBlsZagbElfimHt9YpMUiEM13iJo8rH6K+TUCJMARFj/wJDdwMdo2ECMGwye3sDPpfFbV1D4ZPequ7prPK+VCCltmSKCugTNi/UPntF73fQI2AyMNzOxqXPm/LiUnL7d9fX8EUqLRe5chvLeMt0bvrJw8Tt1MSjBCNRTotImsijgWTz/91cNA) that I used to get the stars; in there:

- The _parser_ and the _evaluator_ are the same thing, so to sum the versions and evaluate the expression (part 1 and part 2 respectively) I had to resort to global ^Wspecial variables to keep track of the sum so far
- I was creating new strings all over the place, instead of simply playing with indices

Note for the future self: when implementing a parser, think about PARSE-INTEGER:

- It uses a string as its input stream
- It optionally can be told to skip a certain amount of characters from the beginning of the string
- It returns not only the parsed object, but also the index of the next unprocessed character -- and that makes for easier composition of the different parsing functions you most likely are going to implement

<3

Advent of Code: [2021/15](https://adventofcode.com/2021/day/15)

Continues:

For example:

OK; as usual, let's start with the input -- let's parse ours into a HASH-TABLE:

Next we need to find the path, starting from the top left corner and ending to the bottom right one, that minimizes the total risk, i.e. the sum of all the risk levels along the path.

Well, it looks like we are only going to have to use A* for this, with the usual MANHATTAN-DISTANCE to the end state as heuristic:

Pretty standard NEIGHBORS function (note: we are not allowed to move diagonally):

Et voila`!  Let's take a look at part 2 now:

And:

So to repeat:

- We need to expand the input map, both horizontally and vertically
- Every time we do this (again, 5 times horizontally, and 5 times vertically), we use the risk levels of the input map, incremented by 1, 2, 3...(0 for the original tile, +1 for the second one, +2 for the third one...)
- When risk levels get higher than `9`, the wrap around starting from `1` (and not `0`)

Let's have the MASSAGE function take care of all that:

We call MASSAGE first, then pass the result to LOWEST-RISK, and that's it!

Final plumbing:

Test run:

Few closing notes:

- I already got a [A*](https://topaz.github.io/paste/#XQAAAQDdBwAAAAAAAAAUGQimgx+p6Nchs0/Hc3cRxcmyfeV+Bzi2FxeDDBZEkgZaDBSyRjbUkuFXP6dhVAaOH8AG99AzdDUHR/lSrXrRzt2ru8sshOcmQ5UeY7P5AZQhS4ncXon3a6r8j5K/gr4xuK1jjTG4PHnVajamzB6t54TV5dSPS63MDOK6jD6CsHfC+VkV4bms/+I8MmYXI4GU2JxpblEiXKntPh1orBPfGpyTCfhx4v+kHU29G6mF1Y4EM6ozuoAyzjwxpY0eKSSV1zFprANFIIlsaPqm/nWF9W4i224u0tUm3IHb+tnMDrFtscipbIplaGiZN8B2Q1apClGT/+51hyLVNGM+4prkx8VWxBWeWuN62LCmMrY0iqRvFeCwKqpwg4s4VRogYMgeG3AOyY1DlJ0UJFetXLjJ+7pMA+8jUmYyE6xRJd9R+jn/cPnkNyDceLd1iFB/ODUgVXLcyrYb7jFIIeucRNGqkgQ7lwe0xvmyiBLkHyIe3ML8lZQcmhyinz9Ynab880cOGsBYBuTRjCS7dCvLr5XKDjw8SpdnWXgjVrzLA49wE+NZXVkPz6tTVzFUR36unRBsIJZJKfYRi3ZUToT1eFyKKayvxZpI9V1QkNJvJehPwqf797u2T57qMuE1UrtnhSso1kQh/BEo33aCHrNXfO/H71RV95KbXakyaLfqTAeeKA2hUrQSbAFnewyRS+3eKmTvbe0+XL1ltwMKAccDiSJR+DZ8iMZhQx91qBpU6W4Gu5c+XA4oT8DFrhGWR1aHzdLLf2ICtG8VUVnLizIL/+Wv790=) implemented in my utilities file, so part 1 was just plumbing things together -- first time I ranked below 1000!!!
- For part 2 instead, I had to use my brain a little more, but apparently neither me nor my brain were actually ready for it: first I got the wrap-around logic wrong, then I realized I was only expanding the map diagonally, and last, I bumped into some weird errors because I was iterating and changing the same HASH-TABLE at the same time

Anyways...

_"50 fucking minutes to _expand_ a map?!"_ Yes, I know, that's ridiculous!

Advent of Code: [2021/14](https://adventofcode.com/2021/day/14)

Continues:

Here is how puzzle input is looking like:

A note about how the polymer is being created:

And finally, the task for part 1:

As we need to make room for new elements, I figured I would use a list of characters instead of a STRING; so, the first line we are going to COERCE it into a LIST; the remaining ones instead, we are going to store them inside a HASH-TABLE:

I think we are going to _simulate_ this:

- For 10 times in a row -- DOTIMES
- We are going to evolve the current polymer -- TICK
- And at the end, we are going to return the expected result -- RESULT

What does TICK look like?

- We traverse the polymer by pairs
- See if the set of insertion rules contain one for the current pair
- If it does, we _collect_ the first element of the pair, plus the output of the insertion rule (i.e. this is how we insert the new element between the two existing ones)
- Otherwise, we _collect_ the first element of the pair only

Last, we are asked for the difference of the number of occurrences of the most and least common element:

- We calculate the frequency of each element, and sort them
- Pick the last one, the first one, and do the subtraction

Cool, let's take a look at part 2 now:

Uh oh...I am pretty sure the above is not going to work:

Let's take this new version of EVOLVE out for a spin:

I am afraid we are going to need something clever than that!  But what exactly?

Well, if we think about it, insertion rules are defined for pairs of adjacent elements only; also, if the same pair of elements is present `10` times in the polymer, if an insertion rule for that pair of elements exists, then that will produce `10` new output elements; so what if we simply kept track of the number of occurrences of each pair of elements in the polymer?

Let's begin by _massaging_ the original polymer representation (i.e. the LIST of characters), into a HASH-TABLE counting the frequencies of each pair of adjacent elements:

With this, we are then going to update TICK as follows:

- For each pair of adjacent element, `a` and `b` (and their number of occurrences, `n`)
- We check if an insertion rule for the pair exists (insertion rule producing the new element `z`)
- If it does, then we know the new polymer will contain both `(a z)` and `(z b)`; how many of these will it contain? Well, we started from `n` occurrences of `(a b)`, so we will have `n` occurrences of `(a z)` and `(z b)`
- Otherwise, if the no insertion rule is defined for `(a b)`, we simply carry that pair (and all its occurrences) along

Last but not least, we got to update RESULT to account for the fact that the polymer has now a different representation.  How do we do this?

- We know the frequency of each pair, `(a b)`
- We know pairs are overlapping, i.e. for the polymer `(a b c)` we are going to have one entry for `(a b)`, one for `(b c)`, and one for `(c nil)`
- If we don't want to double count frequencies, we then have consider only the first element of each entry

And that's it!

Final plumbing:

Test run:

Advent of Code: [2021/13](https://adventofcode.com/2021/day/13)

The submarine has a thermal camera; the camera has never been activated; to activate the camera we need to enter the code found on page 1 of the manual, page which falls out as we open the manual page 1; luckily for us, the paper is marked with dots and includes instructions on how to fold it up.  For example:

The first set of data represent dots, i.e. `x`, `y` pairs, with `0, 0` representing the top-left corner of the sheet; while the second set of data, are the folding instructions.

What are we asked to do with this?

OK, first things first, the input.  We are going to store all the dots into a HASH-TABLE (with `(row col)` as keys, and Ts as values); for the folding instructions instead, we are simply going to use a list:

Now, applying the folding instructions should not take that long:

- For each fold instruction (only one in our case)
- For each dot
- If it's on the left of a vertical folding line, or above an horizontal folding line, leave it where it is
- Otherwise, project it left / up, using the folding line as rotation center (it sounds more complicated than it actually is)
- Lastly, count the number of distinct dots

Cool!  What about part 2?  Well, we are asked to run all the folding instructions, and to _decode_ the message to use to activate the thermal camera:

OK, let's update FOLD to run all the instructions (and still store the answer for part 1), and then see how we could decode the message:

PRINT-PAPER?  Nothing crazy:

- We figure out the max row and col values
- Then for each point from `(0 0)` to `(row-max col-max)`
- If a dots exists, we output a `#`, or a ` ` otherwise

And that's it!

Final plumbing:

Test run:

PS. [This morning](https://topaz.github.io/paste/#XQAAAQDUBQAAAAAAAAAUGQimgx+p6PZhRh7uIPCirs4j6zlpXvdP2y9WdJ6sK9eG/VBt3Z4fnkHxTu3NuCMJ2nmF+B13yA+9sGhCoAHyJ2ZXjZpF6phEUDagCs+h8Ufu+I4B+Xi9tITOLsXEvZfLoH40qd+kCDFX2l8GZ6e6N7gbel/1Cdrm2GooklZBGu591PFeRTEdeTCp9z/uectoPBE3rIyaSwHho1c4uTLfVtTHQrRsa2lxYHWf1y1QGSZ/HceOadgyazkIf6sjipC2net/qdX0s8EM+giC1iAp0f0pJDMBVHJncpyD7r+jix3nC0Fx3vmEBtRvkGTbxtpSPL2FFPaH766gk2rfa5U5djoRM+qJFHzhSDrTOGhUq8QB8+KleQsKs+cswBfYJI3+IrJJrRCN8ilo8rJhMp76rJOzDQ/A3KtynWTFA4mc5+HUaTAhbYrNJdjV9exUecAeMv8UMH96PU4xRZPbKAD7fYPqGs2Q9AQlu6vUT/Aa1t25huhQyhVgWIh7Xxit7AMMMX5/pJLvpuh18R+1vqXSHZh0BrfpGdmJCt03ejSNjizp1lNKQNawGyAJNJerOw09ENby0Nxap8j5WzGHlVzj6kyIu87klBKwrs62U6qb+g4Q3Lc5hg0397CqQxaBTh9mL7irkrlMwVLkDuyYCNZCNT9RrpFBWxXWlpkpIoX96shVBJnpiW+Ma/idPjPGhHXplUMNzgpA7cg1YjcYckkvH0+yT8i0W3Qxvj8aUedIlTCyEHEVcTW2DG/tTHgL7thj9k/dX/YDjyb9lZr/q7Jc0miXU9VitIDMCbbMS8l6WUpt/qD1khDJf661iTz7C8bIK1uucMrS9Dc89Gr+2jDd), while solving this, I forgot to swap `x` and `y` while reading dots; all my `(row col)` were flipped, and because of that:

- Had to flip the bindings inside the for loop
- Ended up swapping rows for columns inside PRINT-PAPER (see `(dotimes (c rows) ...)` and `(dotimes (r cols) ...)`)

It's clear and simple, I am just not meant to be productive at 0600!

Advent of Code: [2021/12](https://adventofcode.com/2021/day/12)

OK...

So, we are given the map of the cave:

Except that it's encoded, like this:

And we are asked to find all the paths connecting `start` to `end` that don't visit _small_ caves more than once:

First off, let's load this map into memory.  We are going to implement an adjacency list storing which cave is connected to which other one, and we are are going to do this using a HASH-TABLE instead of classic association lists:

Next, let's walk through the cave.  We are going to recursively build up all the possible paths starting from `start`, and count the ones that lead up to `end`:

- If we reached `end` then we found one more path to count -- add `1`
- Otherwise, check all the caves reachable from the current position
- And if _visitable_, add the new cave to the current path, and _recur_

And when can we visit a cave? When a cave is visitable?  If a big one, or if a small one, only if we haven't stepped foot into it already:

Cool!  Let's now take a look at part 2:

So, it looks like we will have to tweak VISITABLEP a little; for part 2, we can visit a cave if:

- It's a big one (as before)
- Or when a small one, if it's not `start`
- Or if the number of small caves, visited more than once, is less than or equal to `1`

Let's update WALK to accept `visitablep` from the caller:

And that's it!

Final plumbing:

Test run:

It's not the fastest solution, I will give you that, but I love how self contained the changes for part 2 were, especially if you compare that to my [original solution](https://topaz.github.io/paste/#XQAAAQAvCAAAAAAAAAAUGQimgx+p6PZhRh7uIO9C+TaXA2WvmEoBbmvcTSA2hNnhLNH9+NrXNpDAj8zGpwdcigC0xrwLmwiSZZAqQM7Oije2QNF71VjFvbAaFekLQoen1k9WQoYxw2xUV7tO5VVf85sY5Oa1paBH1vKEy0XuNJQkr4d4ZBPPgQpnUP2/M0gvBS5jcjfPws1bA77znBuGdmednXnc7webfWPkjzoFmI2/JMLMWyd9ChVUdsl89VQNxsrW7nLnAV/fzJVBrXBveYAs8qmrgh28XeCtT3uF6Vnk8jodHq5fjM/wz+fQScMyhH/q/m+SdBAJ+Qn9YYOqoAJqjY/0LdPJOraJAy5Jrox9keHXNZOGNx9qO4m56n2/b0y9V7AkAkeFftoVYskrcdqFROPXVP98FdUvcXv/uNdduoJbcIKeNa4XwMh0v7pSr0yV+U2ZJfUH57G+8812kphcBYJYnwoF8YJMbskQlannpznyiPa2QsPaK9sOYK8uahPK8kuWymzKkl3+R1aMs4bGo+dpfO5D5eUqW4gZ6ZBHfD4FJncXQYPCDmlCUp5dLYIDL8l911ZnaQYBnPGcLCsR7D9mQ+lBOG0ccOety6yKlGTujVWaz9MUKEYXkHBhgmiK8FcuklQlsG68lJTMp/engA6bpjJqilPIXGVU7aZEVTG5bILS7BQNSwuRbcD+iaylfEpg3amoDfSD7KGN+wIU/EEjpBihZPT7mWNKQG3P7H1eeIh+rFNTsg6VgyqvsIQ4orijcjh4V7l+OdeL0ShFU4IsMy4cHeCUzxPIEp7asE97eQH8q9g1JNuNXJ/1opC/61n1SV0F1AwHwGeN1Sfh3pI/HMtGgxe46JzXHl8d9znhNDMeGmpUZ6jcQk87N9mhuziYsKnh3g//wFhpgw==), in which I ended up copying PART1 into PART2 because I needed to pass around a new boolean flag to keep track of whether walking into a small cave was allowed or not.

PS. I was using UIOP:WHILE-COLLECTING to collect all the paths first, and then pass the result to LENGTH to get the answers to today's problems; well, I did not like that, and since I found myself with a little bit of time I decided to create the WHILE-SUMMING macro:

I am sure there are already 100+ different versions of this, better ones for sure, but still, one more would not hurt, so here is mine!

Advent of Code: [2021/11](https://adventofcode.com/2021/day/11)

>

Each octopus has an energy level whose value we receive as our puzzle input:

>

Note, adjacent flashes can cause an octopus to flash on a step even if it begins that step with very little energy.

OK, our task for today:

As usual, let's parse our input first.  Like we did for [2021/09](https://matteolandi.net/plan.html#day-2021-12-09), we are going to parse this into a HASH-TABLE, mapping from `(row col)` pairs, to the octopus energy level:

With the puzzle input taken care of, we can now try to sketch our solution:

- We safely copy our input -- we are going to mutate it, and one too many times I have been bit by me accidentally using a mutated list / hash-table, so when in doubt, I copy things
- Then we let the octopuses dance for 100 times, and keep track of the number of flashes at the end of each dance

Great, now we have to figure out how flashing octopuses influence adjacent ones during the dance; here is what we are going to do:

- First off, we increment the energy level of each octopus, and if the octopus energy level is greater than 10, we FLASH it
- FLASH-ing an octopus means adding the octopus itself to the list of octopuses that already flashed (remember, octopuses can flash only once, per step...err dance), plus scheduling all its neighbors for an additional energy bump increase
- Next, until there are octopuses scheduled to be processed -- see `remaining` -- we increase their energy level, and if that winds up being greater than `9`, we call FLASH on them -- causing the octopus to be marked as having flashed, plus its neighbors to be added to `remaining`
- Note: this is very similar to the classic DFS / BFS, with the exception that nodes (i.e. octopuses) are marked as _visited_ not the first time we process them, but the first time their energy becomes greater than `9`
- At the end, we check all the octopus, count the ones that flashed and reset their energy level to `0`

NEIGHBORS is the exact same function we used for day 9; the inly difference is that *NHOOD* includes deltas for diagonal locations too:

Cool, now let's take a look at part 2 instead:

This should be easy enough: we let the octopus dance until the number of the ones that flashed is 100 (i.e. the size of the grid).

Let's update FLASH-DANCE accordingly:

- We use `:for step from 1` instead of `:repeat 100`
- We accumulate flashes into a loop variable, `flash-count`
- When the current step is `100`, then we save `flash-count` onto a new `part1` variable
- When the number of flashes in the current step is `100`, we break out of the function returning `(values part1 step)`

And that's it!

Final plumbing:

Test run:

PS. [Here](https://topaz.github.io/paste/#XQAAAQC/BgAAAAAAAAAUGQimgx+p6PZhRh7uIOzWurUlN7fbFBw1HHgfNfGNNS7rNArrqFq/zq9awLKNdO5kmayCD7rk2HvFkonJ+07rAMPt3bdfbDoWgkRF4z+uYA8UeujpEPQ4K6D1P0e5Jc9C40O+I6B0/H+FvCYHKQ2vdlF2PoWqAiAZLsmHiW8H0ADVNJ3BSrpxO2VGYR+ONxGjvs9/lwjYPMB33adgSL9lbXZldKw10ruhWD45sMcoe5VPxiUdPM85iMzaG68++Xt0oUPct+MTdMyqSiq2cKJyUhJ3B4mQWzLZIuISnXaZOodJSkkRypBcS8jnZ7eOuxAGjWrUss2UTlwW//L913A6XkSnGc0y3XzvNySeS/uMMPMdwOdEOgzDtHvKA+jESWWoedLrMtaL/57EpEu9fdxCUrsDMTRdqzzw0aa7EkSUyqyMhjOHsR1eZfiL9DyQ2nOOyh05dQwGefb6r3/5PNMcLxk1QouVVOxfPTKrrEKiEpW3HXKfJqvyBaIvoH4684AQtXFJ9hE7RyR18SM1GWev+HGdr166bvCGmbKRA+YLXHJ4QXAh3F+rwJRa3mfJOJhWD4/8rsCXp2ciYlNiLPB1mBldaSnNOKLNGB06Pc3uDrcq6QJFxPGcQbcCwOlPvpzJbdy46dA6ZhFNOCADnkjEA9pMglyaxBPEnu5jNBV81/8akcYU3hfOJcGNiGFpBGJ/u8RBoH2Cg6mjSms9JWkwCHQ73RWuGvqrc3+IrJ2xAQjyu83lMTliIMGH9iD5/ICfBitI8NVyKcZfYE214UWNZM9gAQ6ExCvl87yEgOs2cVb1G10bI0lQnIyZqv/kKwU4O7so7K0nHHuREfaMONIM0FIMiUmX1waZlPKukXnK/PEJ0Q==) you can find my pre-refactoring REPL buffer, and as you can see, as I cleaned up my solution I mainly renamed things, and combined the _cowboy_ loops into FLASH-DANCE!

Advent of Code: [2021/10](https://adventofcode.com/2021/day/10)

>

>

Continues:

>

It goes on explaining the difference between _corrupted_ lines (our focus for part 1) and _incomplete_ lines:

>

What we are asked to do, is process each _corrupted_ line, stop at the first invalid character, and generate a _score_ as described below:

>

To recap:

To solve this, we are going to use a stack; given a line, for each of its characters:

- If open parenthesis, push the relative closing one into the stack (e.g. if `(` is read, I push `)`)
- If close parenthesis: if it matches the value at the top of the stack, I pop that from the stack; otherwise it's an error, so we calculate the syntax error score

Let's start by defining a table to map between open and close parentheses:

Next, let's define our main function, SYNTAX-SCORING, which we will use to:

- Process all the lines in our file
- Implement the stack based algorithm mentioned above
- Sum all the error scores together...and return it

Last missing bit, SYNTAX-ERROR-SCORE, which all it does, is looking up the given character into another table mapping from _invalid_ characters to their score:

For part 2 instead, we are asked to focus on _incomplete_ entries:

Once we figure out these completion strings, we need to calculate their score:

>

Then we need to collect all the scores, sort them, and pick the one in the middle:

>

>

OK, first off, let's update SYNTAX-SCORING to start processing _incomplete_ lines as well.

In our case, an entry is _incomplete_ if it's not _corrupted_ (i.e. it did not cause an _early_ return from the LOOP form), _and_ if when done processing all the line characters, `stack` turns out not to be empty; in which case:

- we calculate the completion score -- :FINALLY clause added to the LOOP form
- collect all the scores together -- see COMPLETION-SCORES added to the function parameter list
- sort them and pick the middle value -- final LET* form

Note that in our case, `stack`, actually represents the _completion string_ mentioned above, so we can simply go ahead and calculate its score as instructed:

And that's it!

Final plumbing:

Test run:

And we are good to go!

PS. Today's problem was a breath of fresh air, really, especially if we compare it to the problems of the last two days, and even my [pre-refactoring REPL buffer](https://topaz.github.io/paste/#XQAAAQA4BQAAAAAAAAAUGQimgulVkMqJePdJ12sc+KZM7LOyBuIC1dzJtzX33KNaMXj9jmVZTPyfQOmX9PpTg5GvWdrvb7nTb9ehlqWqzZpjVnVnMGhfrX1xdaAgSNaXDCXu2M2WHr9Ka+4Bd6xYmaJlsoLibJAMVSflYybG5/E4vkNUo9nyCiaOJft/b2FbN3paNVzj8HO6fbrKik9iPjcV2n7jQfOxB05bL4ApX44oMtesKX1WwNluA6y2i7r90FAeHyyaMNak929zF5LGhGiARa+nmXNv+6suXMQZiCOAD8O2O7R7OTmdtXH7GCK+Selm1SwZ1vC0BGB4xzp8njvpRtUewleaWkBHZu5aCElvzg9/Hn7gHgXkrzWzL9ONANarpyCBZGmIwIQAmm47PQvTUh1YLAUhSXnIOm6Yyy0lbHzdfEwLmq5PnbuthOsEWJ/aiTtxFGv7r9LvfcfwgxUT1dIyvqHoy6ktffQZGdaMKGy7xzLg/LPwnTzhPHjDbCGmPcTJdDLro1/iXCNwXfDowju2lnfal26uMNhzeBb/Y6GvH3lNlzKH4Yq4tBzQbJOwXUFMGrw/XY3GqH8BUK5TRxRhGBqi2vpQa2vHjRfwkn+oR3Lis3R6kK4BjEBeJK9J5OqyXern7uZkiOhAoKOvNHwIcTY0xQkVqOZJYnXEuI3JCDHiN/wpn1E=), seems to agree with that!

Advent of Code: [2021/09](https://adventofcode.com/2021/day/9)

Rain...underwater? Aren't we still on the submarine, are we?! Anyways...

Continues:

>

>

The first step is to parse the input heightmap; we are are going to use a HASHTABLE, mapping from `(row col)` to the corresponding height:

Now, here is what we are asked to do for part 1:

So, for each low point, we add one to its height, and sum everything together:

But what are the low points of our heightmap? All the points surrounded by locations with a higher height:

- For each point in the heightmap
- For each of its neighbor locations
- Check if the height of the center is smaller
- If it is, and for all the neighbor locations, then it's a low point so we should collect it

But given a point, what are all its neighbor locations?  The ones north, east, south, west, which do not fall off the grid:

Now, for part 2 instead, we are asked to calculate the size of the largest _basin_:

And in particular:

OK, so:

- We find the basins
- Sort them by size (biggest first)
- Take the first 3 values
- Multiply them together

Let's dig a bit deeper, and see how we are going to calculate the size of the basins:

- For each low point (we know each basin expands around one of the low points from part 1)
- We apply BFS, scanning all the surrounding area, until we either fell off the grid (NEIGHBORS already implements this) or we hit a location with height of `9` (from the text: _locations of height `9` do not count as being in any basin_)
- As we navigate adjacent cells (i.e. our :NEIGHBORS function), we increase a counter representing the size of the current basin

I already have BFS available in my utility file, so implementing the above was quite straightforward:

Final plumbing:

And that's it:

I wished I were able to code this up, on the spot, as the clock was ticking; instead, my [REPL buffer](https://topaz.github.io/paste/#XQAAAQDHCwAAAAAAAAAUGQimgx+p6PZhRh7uIO+WahagjQFtPUroo2DHmQaY6XQY1BYJ+FMCLkj+Xpf+GXwi1mkfiahNXzGziXL6bKmTzHNvb+uG5oA435oUBU5eqNnZv0QZ7grjrReQCKmII7Qfq3wAMvM+VOxZt/n90rZ8BZYGbFNoRn3y2DYmMyM/VImdJxNjfq0yhV53UoWNkQL61HpdCStQHM2EJ1Mh9VhTk6oNhbfFah6BArXTOVwK1xvMxv4DAhqQ4F1DcTE/vpl9OinZXp1CKRSxMIHv9k4fkV8F6i1damTN7gRXQS/ahc1TkeJm3e28uw0DJM/hxRuUvrRAzQkX9WQzNqVqvYxNjp2T5c+rPq4uIoBap1pQsiGqBxJ+462us1oa8mDQijvvmNUm+B7F9wYizQfra3lEedhNyea50YTCG7eVi9cXU0+w1AszW7+Qc4N+EF/YHYOQ6pNO9oMWkXKLNwtFxFFZhv0lISG3hjowK5FMycdOZussyrF9M20IO/mq6feOWp309AO/T+Q83Z+iah4GzohefjT05OR0sv8+EWlDOoPadylXaPdXW4kV2Kz3SFXCriiTUkYpr8Nmu3ZSbtBNaEHn0k19uQ9XR8vqw6FKbpfslM+2WzNY7gpxi1TqZ4UtetR/30sSoYE8uly4hHPmd0U0IboW52c4PVg2wUluyUZuk2Dt5hNHUPh2CTR2out6u4EhJ6MOT2eEdtmhDrfHoHhWiuBcTJUVMbtnJstp9hBY/ce15UMEVKqgKQEXu2n8tOLALvezzfOq03TXkC6v2vpL2I3dvBkSkxY1DjGjSxNxpN3wAnsdtYpS5vuHZZnEnQ6YnP4k2QH5hOH8OZVg3kKY7AyAnajGyFtK0UbiF5TlP09/aYAbkBWGibTLWApQYfLyJmtYP7r5H6dZBzUBJiWQSzPcDnHED2m7Rzot9n8X/zXGfZvi3Ie8oRgu2vr1kovWfbzkkHFkt+OhjPMsgybIVfMGbk0lzRgJGHuVTPSfqiICgE/oPBxHkPQbjz8zUgj5IbmBoVKOo2ABq4EFzeYY1b5RpUtkL9/yZEIzyG9z0XLEbnAuo6RJPmKHdHii5xAUWUG1FGR6YEwFNFXoqpB0EeMWBBj8rt3JwNUSaUAGXJTYF6NcYGRpi3accSCK/X8JkA==) for today wound up looking anything but clean:

- Used a 2D array instead of a HASHTABLE to represent the map, and _that_ made pretty much all the rest really **really** verbose
- I was only checking the location above and to the left of the current one in first BASINS attempt, but that clearly generated the wrong answer
- It took me a while before I decided a NEIGHBORS function would have helped with the overall readability of the whole solution -- very important, especially when things ain't working as they should, but go figure why I had not thought about that sooner
- Last but not least, I forgot I already had AREF-OR in my utilities file, for safely accessing array values even with out of bound indices; so, for part 1 I ended up sprinkling a bunch of OR / IGNORE-ERRORS forms all over the place, while for part 2, I wound up re-implementing AREF-OR as SAREF...

Still got my 2 stars home anyway, and _that_ alone is a reason to celebrate!

PS. As it turns out, part 2 could also be solved using disjoint sets / union find:

- Each location starts as a disjoint-set / basin of its own
- For each location, for each of its neighbors, if the neighbor height is not 9 then we join the two sets / basins
- For each set, we find the root element and start counting how many locations roll up to the same set / basin

And these counters, one per basin, actually represent the list of sizes we were looking for:

And just to be 100% sure, let's confirm we did not break anything:

We didn't!

Advent of Code: [2021/08](https://adventofcode.com/2021/day/8)

We managed to escape from the whale, but something is not quite working as it should:

Each digit of a seven-segment display is rendered by turning on or off any of seven segments named a through g:

So, to render a `1`, only segments `c` and `f` would be turned on; the rest would be off. To render a `7`, only segments `a`, `c`, and `f` would be turned on.

Continues:

>

>

For example, here is what you might see in a single entry in your notes:

_OK, I kind of get it, but what exactly are we supposed to do?_

The following algorithm should get the job done:

- For each entry
- For each output value
- If its length is either `2`, `4`, `3`, or `7` (i.e. the number of segments on, for the digits: `1`, `4`, `7`, and `8` respectively), then it means the entry is trying to render one of those digits, so we add 1

However, let's parse our entries first:

Now, the algorithm to solve part 1:

An easy part 1 is usually followed by a somewhat complicated part 2, and today is no exception:

So yeah, somehow we need to figure out which wire is connected to which segment, decode each output value, and add them up together:

OK, before we actually figure out a way to find this wire / segment mapping, let's pretend we had it, and see what we would do with it.

Given the following wiring:

Our mapping would look something like: `(#\d #\e #\a #\f #\g #\b #\c)`.

Now, if we _had_ this, we would go on and _decode_ the output signals:

Before looking at SIGNAL->DIGIT though, we are going to have to define a table mapping from digits to the list of segments which are on when the given digit is rendered; and instead of coding the list of segments as a list, we are actually going to use a bitmask instead (e.g. segment `a` -> `1`; segment `b` -> `2`; segment `c` -> `4`):

And with this, to convert a signal to a digit all we have to do is:

- For each character of the signal -- DOVECTOR
- Find the segment it's connected to -- POSITION
- Set the _right_ bit in the bitmask -- DPB
- Look up the bitmask in the table above -- RASSOC

Now, let's take another look at what exactly we are asked to do for part 2:

If we gloss over the "determine all of the wire/segment connects" part, and consider the fact that we already know how to decode a message (once we have the mapping), it should be pretty easy to wire things together and find the answer for part 2:

Now we have to figure out what FIND-MAPPING will actually do.

Well, even though the following algorithm produces the right answer (for my input at least), I honestly think I just have been super lucky because the more I think about this, the more I question _why_ this would work.  But it does seem to work, so...

Anyway, we begin by saying that each segment could be linked to any wire:

From here, we process each signal pattern, from the _easy_ ones to the most difficult ones, and try to _refine_ our mapping until any of the following conditions happen:

- Each segment maps to a _different_ wire -- in which case we found our mapping!
- We cannot map segment to a wire -- in which case we will have to backtrack!

Given a signal, first we figure out based on its length the different digits it could refer to; for example:

- `ab` uniquely refers to the digit: `1`
- `abc` uniquely refers to the digit: `7`
- `abcd` uniquely refers to the digit: `4`
- `abcde` could refer to any of the following digits: `2`, `3`, `5`
- `abcdef` could refer to any of the following digits: `0`, `6`, `9`
- `abcdefg` uniquely refers to the digit: `8`

Then, for each of these options (e.g. a single option in case of `ab`, three different options for `abcde`), we see which segments the signal uses, and refine our mapping as follows:

- If a segment is used by the current signal, we know that it can only be linked to any of the wires used by the signal; we can then safely remove (i.e. INTERSECT between the current list of options, for the segment, and the wires of the signal) any other possible option for the current segment, as choosing that would cause the constraint defined by the current signal to break
- If a segment is not used by the current signal instead, we know it will never be linked to any of the wires used by the signal; we can safely remove (i.e. SET-DIFFERENCE between the current list of options, for the segment, and the wires of the signal) all the signal wires from the segment list of options, as again, choosing that, would cause the constraint defined by the current signal to break

We then continue to the next signal until either we find a valid mapping, or we hit a dead end step back.

Again:

- If each segment is linked to a single wire, we found our mapping
- If a segment, for whatever reason, winds up not being linked to any single wire, then we hit a dead end
- If we run out signals (and none of the above hold true), we hit another dead end
- Otherwise, for each digit that the signal could render -- POSSIBLE-DIGITS
- And for each segment of this digit
- We update the list of possible options as described above (i.e. INTERSECTION for the segments which are on, and SET-DIFFERENCE for the remaining ones)

But what are the digits that a signal could possibly try to render?  As mentioned above, we answer this by looking at the length of the signal:

Last, we said we wanted to process the _easy_ signals first; here is the predicate function to pass to SORT to make sure signals with the least number of _renderable_ digits are processed first:

And that's it!

Final plumbing:

Test run:

PS. As it turns out, part 2 could also be solved by brute-force:

- Generate all the possible mappings (it's only seven wires!)
- For each entry, try all the mappings until one successfully decodes the inputs

WTF?! It runs pretty damn fast too!  I guess next time I am going to try to remember that sometimes inefficient but no-brainer is better than efficient but requiring a big-brain.

Advent of Code: [2021/07](https://adventofcode.com/2021/day/7)

- A whale has decided to eat our submarine
- Lucky us, a swarm of crabs (each in its own tiny submarine...LOL) is willing to help
- They want to drill a hole in the ocean floor so we can escape through it
- They need some help to figure out the exact position where to drill

In particular, given the horizontal position of each crab, we are asked to align them and minimize the amount of fuel each tiny submarine needs to get there.

Parsing the input is a no brainer; it's a comma separated list of numbers, so the usual CL-PPCRE:ALL-MATCHES-AS-STRINGS, and MAPCAR with PARSE-INTEGER will do the trick:

Now, to minimize the amount of fuel required to align all the crabs, I am just going to brute-force it:

- For each point between mix and max crab positions
- Calculate the amount of fuel to move all the crabs there
- Minimize this

For part 2, the situation changes a little bit:

Continues:

If a crab needs to move 5 steps, it will consume: 1 + 2 + 3 + 4 + 5 units of fuel; and [in general](https://en.wikipedia.org/wiki/Arithmetic_progression#Derivation), to move `n` steps it will consume: `n * (n + 1) / 2` units of fuel:

Little bit of refactoring plus final plumbing:

And that's it:

PS. In the heat of the moment, i.e. at something past 6 in the morning, I could not really remember the formula for the sum of an arithmetic progression; so what did I do, instead? [I simulated it!](https://topaz.github.io/paste/#XQAAAQC3AQAAAAAAAAAUHMind5jo50a72d6QS46YciZNqOxJy4V2WTiur+Qo5cWe6U9r6SyOJAjWcaSIJPsSzysjospBanW0NWsGyUEVOXTNYugyPi3UXtxVSE8V+6fKq9IN0ZrRch0UCsc5gmMVc2vkQkX2qH6njUoOmlI6Xm2D3GZKxJ+qvujI4z6GepPH5hvGuXJR4XqsTpmHnO9yonbOUFSylej8rV9O3jJvc7kMJNFPhxuzkK3ck//MJx9hg/flYZrAMJ/oKg+iWjJBqyliY44AHrsEmGNm2Aa4A7pc1ncIOIHxtWLrvtPRFIT/YnyyAA==), adding 1 unit of fuel at each step...

Advent of Code: [2021/06](https://adventofcode.com/2021/day/6)

Today we are asked to study a massive school of lanternfish; in particular, we are tasked to see how big this group will be, after 80 days:

>

>

So, to recap, we are given a comma separated list of numbers, each representing the age of each fish, and we are asked to measure the size of this group after 80 days, knowing that:

- A lanterfish will produce a new lanterfish every 7 days
- A newly spawn lanterfish will require 9 days before it can produce a new lanternfish

As usual, let's start form the input (it's a comma separated list of numbers):

With this, we can evolve the school of lanternfish as follows:

- For each fish in the school
- If it's 0 it means it can reproduce; we add the lanternfish itself back into the school (with the timer set to 6), and then we add a new lanternfish with the reproduction time set to 9: it's a new fish, so it will have to wait a little longer
- Otherwise, we simply decrease the reproduction counter
- We do this 80 times

For part 2 instead:

Before you try it, replacing 80 with 256 is not going to work -- you will run out of memory real quick!

The big realization here, is that lanternfish with same age are all alike, and they all are going to reproduce at the same time; we don't care which one comes first; we only care of when in the future they are going to reproduce.

Let's parse the input again; this time though, let's output a 9 elements array, representing the number of fish reproducing in 0 days, 1 day, 2 days...

Evolving the school of lanternfish for a given number of days (so we can use this for part 1 as well) would then become a matter of:

- Rotating array values to the left (i.e. aging + reproduction)
- Increasing the `6-days` slot by the number of fish that just reproduced (i.e. they will be able to reproduce again in 6 days)

Final plumbing:

And that's it:

Advent of Code: [2021/05](https://adventofcode.com/2021/day/5)

Uh oh!  It continues:

The task for the day:

Let's start by reading our input; we are going to parse each line int 4 elements lists, i.e. `(x1 y1 x2 y2)`:

With this, the solution to our problem would be a simple:

"The evil is in the details" they use to say, so let's take a look at the details.  DIAGONALP simply checks if the points describing a line have the same `x` or `y` value:

Inside COUNT-OVERLAPS instead:

- For each line in our input
- We generate all its points
- We store these inside a HASH-TABLE, keeping track of duplicates (as that represents our answer)
- A naive `(loop for xx from x1 to x2 ...)` would fail if `x1` is greater than `x2`; similarly, a naive `(loop for yy from y1 to y2 ...)` would fail in `y1` is greater than `y2`
- <=>, a.k.a. the spaceship operator, returns `-1` if the first value is smaller than the second, `+1` if greater, and `0` otherwise; this represents how much to move in a given direction
- Once we know how much in each direction to move, we just have to figure out the number of times we have to move -- `n` in the snippet below

For part 2 instead, we are asked to consider diagonal lines as well; we could not have been any luckier, given that all we have to do is feed COUNT-OVERLAPS with the original list of lines (and not just the horizontal/vertical ones like we did for part 1):

Final plumbing:

And that's it:

PS. This the code I originally used to solve this:

- Part 1: MIN / MAX to figure out where to start and where to stop, when using `(loop for v from ... to ...)` kind of loops
- Part 2: consed up all the ranges of points, and iterated over them

PPS. I fucking bricked my laptop yesterday while upgrading to Big Sur, so I had to sort that issue first before even start thinking about today's problem -- what a bummer!

Advent of Code: [2021/04](https://adventofcode.com/2021/day/4)

Today, we are playing Bingo with a giant squid (yes, apparently it is on the submarine with us!):

This is the kind of input we are expected to process:

I am going to create a new structure, BINGO, with slots to keep track of the numbers still left to draw, and each board; for each board representation instead, I am going to use a 5x5 2D array:

Now, let's play some bingo!

- For each number to be drawn
- For each board
- Let's mark the number on the board
- If it turns out to be a winning board, let's return its score:

MARK-NUMBER would:

- For each number of the input board
- Check if equal to the number just drawn, and in case, mark it (i.e. remove it)
- Finally return T if the move made the board a winning one

Lastly, the score function, i.e. the sum of all the remaining numbers of a given board:

For part 2 instead, we are asked to keep on playing, until there are anymore boards left.  All we have to do is update PLAY as follows:

- Collect the scores of each winning board, instead of simply returning it
- Stop processing winning boards

Final plumbing:

And that's it:

PS. If you are curious, [this](https://topaz.github.io/paste/#XQAAAQCcBwAAAAAAAAAUGQimgwpCHOTIZ4cAdwSqqsL7YgkUjovizS3Rs1wUzEvkHpHd8o1Y7gEL0qcj1QOhqpL5g1eXcPnMqtKzYd+JHJvk5TCuqeIZwbOUxyOKy+tnAnfUMPqoLtTHNC71/R6Sv4Ls2YYxCXO/8YKt36evcoX5GU0U8VRI0OwWzBYML+rGFdtD2Wgh8+vxKgohgOBuhIjO89Cyj0VFzH9aSXZkIiuK42nn0rL9Oz6eaYbjUjjV7VU1AqKc5EV43BJVefv7+4HYe3lCBRu+BqyO4PcGrUOYVR4npFsgz7gDvTlOgryFzKpD2E0Vlf6A+k9bRwheXOXGZMgS38+zHzWN8biiDw6u9l6gdfonmBkGDdTyTCB4i6+yJyZrVPhM0FBsHMPe/+D5wPudKuZ13Az6U3B+NyZi5i1p14Uob+U9hA15Yprs3LLfyvdac8MfNXf1QKNoSOEOmZ+EjxBkpHuPWDWsgbDDeJZ5Xr/WPiGZvWrJrBj5am+ohpzDckuRSWyCd4CZGQobh8xSeadJNb9kQ5zuqJRDQiJRxy5UTeKWJTONi3R1EXI1wudHfDOAHlxpri78iWY0XWbCU8HxArT8vLP8RM6A+IdlaMWV8V6YdA5USqjI4v5l/UVc3+k1h0UUcikLRf/C8xetTSJTIfUXQaY4cTHsxnEiB7Gt0GfONV+gkYGPpy+k/hzA+v5mIVUNxAR6YI8WoHuELRuJ/1sNo4oHplkOBrWrHcrLjnKlzJH5YlnNvg0P65FtPnFRkY7OsyHmYBf4KxilEtZzhKxJAkxKegEbY6fcTpXWVTsHISzNLh8sv8OikMGNXYdsklMi9p7KRSXjD5kr01EdP0L0/VuDRDZfdvidseczEawqgtz1EOrCpm1T6VLBu+OiblOolwhUocYqZdndLv9j1pU5LTIvuSa/s+ErqCwh6K36jUEP1E/ZAIKE6lxXXo/+f8ce) is the non-cleaned-up of the code that I used to take my 2 stars home (see how I went overboard and used conditions to notify the runner about winning boards).

Advent of Code: [2021/03](https://adventofcode.com/2021/day/3)

The submarine has been making some odd creaking noises today, and after we ask it to produce a diagnostic report (our input), we are tasked to _decode_ it and see if everything is all right (or not!):

>

>

>

>

We are not going to do anything crazy with our input; in fact, we are going to keep it as is (i.e. as a list of strings), and jump right into the core of our solution:

- We calculate the gamma rate...as instructed
- We calculate the epsilon rate starting from the gamma rate (i.e. it's just its complement)
- Parse the two strings into numbers, and multiply them

Note: we could have returned a number and not a string from GAMMA-RATE; but then, to calculate the epsilon rate, we would have had to mess with bits "a bit more" to account for any leading 0 (i.e. 0001, complemented, should be 1110, and not simply 0).

Inside GAMMA-RATE we collect the most common char at each position, and then coerce the result to a string:

Things are going to get messy for part 2:

>

>

>

>

Thaaaaaaaaaat is a lot, with lots of details too; hopefully we are going to figure this out -- well, if you are reading this, it means I already "figured something out" ;-)

Let's start from the top:

Now, to calculate the oxygen generator rating, let's proceed as follows:

- Until there is only one string left
- Figure out what the most common char is -- at a given position
- Remove all the strings having a different char at that position

To calculate the CO2 scrubber rating instead, we just have to consider least common bits; this is done by wrapping MOST-COMMON-CH-AT inside a call to CH-COMPLEMENT (the rest is the same):

Final plumbing:

And that's it:

PS. My original solution was not as cleaned as this one: it was super messy, I coded it fully in the REPL, i.e. there is not a single function in my solution (I am not proud of this, I am just stating a fact), and even though messy, it still took me forever to came up with it; lastly, cherry on top, to actually get the answer for part 1, I manually converted an ARRAY of Ts and NILs into 1s and 0s!  Anyways, if you really, really want to take a look...[have at it](https://topaz.github.io/paste/#XQAAAQBxBwAAAAAAAAAUHMineAofMgXCOJWpWvfWz/ftuK+H3bIoU+EY9K2IiV45Fs/OqcTa6MWLBv78pFRraVXpcVqiedY9084OCmjcb/QJchZ9UEBYH48m0joS9Aw/nxLo/p6sl85X0fHkzN7M1g4UHvmCT6m5+RQoVi5WzXyVLb8BMgsVfyznajX7BnSwi1DY1pm/mdUrqcbzLt9S1/EJXnn20zKLNFUc8D7Z2GvFp03xL3z5WfIH+9bsPqUQr/7K2MDl21y6zGf0PPLzklkVeuxlkw7W2uXWL4clSS1jDWeSF1v3eiZ700d6El2Z3GzO3VmHKX24dPBwOrqJABV1tUILx7gUs/vmlmOHsSSBLtDMj1bmBC8bR12iX9oiz72csFMK/a5koBQ/mm1HpUShSuhVnevc1bGd0+HJfTqsV5LBRVVguP8fJcC4J+hiPcmv29AP8lM/4KUVH6UobmQLEyNR479SlukyI7cKuFPuO91W6TqvYHCKp810/eiS+28dL6RaktTLtEpYJRjLDSUMt5SyuYqAVGCKPHryDzeqHLvcwsngsZ7wKRIA3X/ZB9iJej0JlNMCYHxLV/FL0hfVWJoAJErxH+XQqATKi5ibPlo+ppSkj+kbNQejQq65jKdk2nkFiXMo5FjY4G/7SJj49Z9xywnPUqSy/NVX3OMUiJ43r8JSF/ypZvk=)

Advent of Code: [2021/02](https://adventofcode.com/2021/day/2)

>

>

>

>

OK, let's start by parsing our input, i.e. the list of instructions, into `<direction,unit>` pairs:

- CL-PPCRE:REGISTER-GROUPS-BIND to parse our instructions using regexps (we could have also used SPLIT-SEQUENCE)
- AS-KEYWORD to convert a string into a _keyword_, i.e. `:forward`, `:up`, and `:down`

Now to get the answer for part two:

- Iterate over the instructions
- If `:forward`, we move our horizontal position
- If `:up`, we reduce our depth
- If `:down`, we increase our depth
- Last, we return the product of our horizontal position and depth

For part 2 instead, the `:up` and `:down` instructions seem to assume a different meaning:

>

>

>

>

>

Nothing fancy, let's just implement this:

- Iterate over the instructions
- If `:forward`, we move our horizontal position and descend / ascend based on the current aim
- If `:up`, we increase our aim
- If `:down`, we decrease our aim
- Last, we return the product of our horizontal position and depth

Final plumbing:

And that's it:

PS. My [original solution](https://topaz.github.io/paste/#XQAAAQD2AgAAAAAAAAAUGQimgx+p6PZhRh7uIO5BVe7pcMkiG6eOV22j2MYKuFs91c+ybCSTgFinLxYMDBog9+B+g/uA1iuHBXT5kPl5FbfHsjTt/UH6LeDhwtxS++LtE/cfL47hqbZilPQVUp7nWL834NkL1xo124ObhgTHG4Vaq0sDvXEWYVT61bdI9njY95YkUyYD8jeF6mdT+45tB+epQP+OgkkUyyWgSGXG3mXlBPAuGtfQ2d6F6X56fu266chYGK/yaubPY1GuajRiidCeYijfEAPoeMsgyIZcp6U4hgNM0D1M6vPzyThdMrcJtAwVid8BqQUE8ebzylpWag4uZPUQgHKdoZTgteopbArgU34gzK34OzvfXyvwL063kO+uz3rYxgePqqnFxROOQdSe0tseMzpTFeHv+lLiE+efMBoId4Ao8BsmGov79aT/8r1yLg==) parsed instructions into COMPLEX numbers (e.g. `down 4` into `#C(0 -4)`); this way, for part 1 all I had to do was summing all the deltas together; for part 2 instead, I had to check if the delta was horizontal or vertical, and adjust the aim accordingly.  I figured a more readable solution would be better, hence the rewrite.

Advent of Code: [2021/01](https://adventofcode.com/2021/day/1)

- An elf tripped, and accidentally sent the sleight keys flying into the ocean
- All of a sudden we found ourselves inside a submarine which has an antenna that hopefully we can use to track the keys
- The submarine performs a sonar sweep of the nearby sea floor (our input)

>

>

We already have an utility function to parse a list of integers, PARSE-INTEGERS, so there isn't much we have to do here, except for calling it:

Now, here is what we are tasked to do for part 1:

>

Nothing crazy; we simply do as told:

For part 2 instead:

Here we can re-use PART1 completely, except that we need to pass to it a different list of numbers, each representing the sum of a three-measurement sliding window; again, LOOP/ON makes for a very readable solution:

Final plumbing:

And that's it:

Vlime: Make swank_repl a prompt buffer

(This was posted on [vlime/pull/55](https://github.com/vlime/vlime/pull/55))

Alright, since these changes got merged into @phmarek's fork, and since _that_ branch is the one I am using these days, I would like to provide some feedback about this; also, please note that I am running this with Vim, so expect some of the following feedback not be relevant to Neovim users.

**Performance**
I have no number to back this up, but I noticed that forms generating some non-trivial output are more likely to cause Vim to freeze if the REPL is made a prompt buffer than when it's not; don't take me wrong, t's a bit sluggish anyway, with or without these changes, but more so with the prompt buffer than without.

I have a [project](https://github.com/iamFIREcracker/adventofcode) with quite a few packages, and every time I touch the main .asd file and QL:QUICKLOAD it, Vim becomes very sluggish.

**Stealing focus**
The currently focused window seems to be losing focus every time a new line of output is added to the prompt buffer; this causes all sort of issues, especially if you were in insert mode when the focus got stolen.

I was messing around with a Web application of mine, and had the client fire a HEAD request every second (request which got logged by the Web server on the standard output, i.e. on the REPL buffer); that alone seemed to make editing in a different buffer impossible (e.g. missing characters, unable to move around the buffer), to the point that I had to disable the polling on the client!

I am not exactly sure what's going on, and I would not be surprised if this wasn't somehow related to the performance issue above; however, the moment I disabled this PR's changes, it all become responsive again.

**Current package**
While Vim itself might be the cause of the two problems mentioned above, this one is most definitely a bug with the current implementation.  Previously, forms typed into `vlime_input` buffer would be evaluated inside the package specified in the closest preceding IN-PACKAGE form; for example, imagine you had the following buffer open:

Opening up an input buffer (i.e. `<localleader>si`) from line 2, and typing `*package*` into it would cause `#<PACKAGE "COMMON-LISP-USER">` to be logged to the REPL buffer; opening up the input buffer from line number 6 instead, and typing in the same would output `#<PACKAGE "FOO">`.  Well, with this pull request, it would always output `#<PACKAGE "COMMON-LISP-USER">`.

**Only works while in insert mode (minor, opinionated)**
I am not sure if this is Vim's fault or if the plugin's implementation, but evaluation from the prompt buffer only seems to work while in insert mode, i.e. pressing enter while in insert mode seems to be the only way to trigger the evaluation to happen.  This unfortunately clashes with some of my settings / how I am used to work; I can work around this of course, re-wire my muscle memory, but I wanted to flag this anyway.

I use [delimitMate](https://github.com/Raimondi/delimitMate) to keep my parens balanced (yes, it's a poor man's solution, but gets the job done most of the times); this means that if I want to type in the form:

By the time I type the closing quote at position 22, the closing parenthesis would be there already, so I would just leave insert mode and expect the form to be evaluated; however, as soon as I leave insert mode, a new line is added to the prompt buffer and then I am forced to type it all again, the closing parenthesis included, and then press `Enter`.

**Empty prompt (opinionated)**
Maybe it's just me, but the first time I entered insert mode while in the prompt buffer I started wondering what that initial space was for.  I thought it was a bug, having something to do with Vlime wrongly calculating the indentation level; but then I looked at the code and realized that that was the way we told the prompt buffer to look like.

I think we should either set this to an empty string, or maybe the classic `> ` or `* `, as that would make it super clear what's going on.

**Next steps**
I am OK with tinkering with this a bit more, but here is what I think we should do:

- Understand if the performance issue mentioned above, as well as the focus stealing one, are getting experienced by everybody, i.e. Vim and Neovim users, or if it's just one man's problem (me...sigh); this will help us understand if switching to a prompt buffer for the REPL is a sound idea or not
- If it was, maybe put everything behind a config flag, so people can enable / disable it, at least until it's a bit more stable (not everybody wants to deal with this)
- Work around some of the usability issues mentioned above, like setting the current package, or changing the prompt string, etc.

Let me know what you guys think about this.

M.

Building a _local_ system with :TRIVIAL-BUILD

(This was posted on [ceramic/trivial-build/issues/2](https://github.com/ceramic/trivial-build/issues/2))

Currently, there are at least two different ways of dealing with locally defined systems, i.e. systems defined in the working directory:

1. Create a symlink inside ~/quicklisp/local-projects (or ~/common-lisp), pointing to the current directory
2. Add the current directory to ASDF:\*CENTRAL-REPOSITORY\* (`(pushnew '*default-pathname-defaults* asdf:*central-registry*)`)

Now, with the first option, everything works as expected: you call TRIVIAL-BUILD:BUILD, it spawns a new CL image, it runs ASDF:LOAD-SYSTEM in it, and since the current directory is inside ~/quicklisp/local-projects (or ~/common-lisp), your system will be loaded just fine.

Unfortunately the current implementation does not seem to play nicely with the second option, i.e. updating ADSF:\*CENTRAL-REPOSITORY\*; that's because the newly spawn CL image, the one in which ASDF:LOAD-SYSTEM is called, has ASDF:\*CENTRAL-REPOSITORY\* in its default state, i.e. without our customizations.

Is there any interest in supporting this use case, or instead you prefer to push people to use option 1 instead?  Because if there was, here is how I _patched_ LOAD-AND-BUILD-CODE (note the line right above the ASDF:LOAD-SYSTEM call):

- I serialize the current value of ASDF:*CENTRAL-REGISTRY*, in reverse order, so while loading them later with PUSH, the original order is preserved; note: this happens on the host image, i.e. the one where :CERAMIC is run
- For each entry, I push it back into ASDF:*CENTRAL-REGISTRY* -- this instead is run on the final app image, the newly spawned one

Let me know if you see any problems with this and most importantly if you find this somewhat interesting, in which case, I would not mind creating a pull request for this.

Ciao,
M.

Advent of Code: [2018/10](https://adventofcode.com/2018/day/10)

In today's problem, we are given a sky map: a list of stars, characterized by their position and velocity:

We are also told, that after some time, stars would align to form a message; that message will be the answer to our part 1.

Let's start by parsing the sky map; we are going to define a custom structure, STAR, having one slot for the star position and one for its velocity; we are also going to store all these stars into a simple list:

Now, how can to figure out when the stars are aligned? My idea is to take a look at the bounding box containing all the stars: as the velocity of the stars does not change, I would expect the size of this box to become smaller and smaller, until it starts getting bigger again.  Well, the state of the sky when the bounding box is the smallest, is probably the one in which all the stars are aligned; so dumping it on the standard output would hopefully show us the message!

FIND-MESSAGE accepts the sky map as input, and keeps on moving stars (see SKY-NEXT) minimizing the bounding box (I am using the area of the bounding box, SKY-AREA, as a proxy for its size); lastly, SKY-MESSAGE is responsible for analyzing the end sky map, and print `#` when the stars are:

Let's give this a go:

Good!  Now part 2:

We should be able to answer this quite easily, by slightly tweaking FIND-MESSAGE:

- Keep track of how much time has elapsed
- And return it, as second value (the call to 1- is to offset the fact that the first iteration is a dummy one, given that `sky-prev` and `sky` are the same)

Final plumbing:

And that's it:

Advent of Code: [2018/7](https://adventofcode.com/2018/day/7)

Given a list of steps and requirements about which steps are blocked by which other step or steps, we are tasked to find the order in which the steps are going to be completed.

Example:

Visually, these requirements look like this:

And the order in which the steps are going to be completed is: `CABDFE` (in the event of multiple steps being unblocked, we should select based on the lexicographical order).

We are going to parse our input into an association list, mapping from steps to their dependencies:

Feeding the example above into PARSE-INSTRUCTIONS, should result in the following alist:

Now, to find the order in which the different steps are completed, we are going to proceed as follows:

- We sort the instructions, placing entries with the fewest number of dependencies (ideally, 0) first, or lexicographically in case of ties (see SORT-INSTRUCTIONS, and INSTRUCTION<)
- We pop the first item -- this is the next step to complete
- We unblock any other instruction that might be depending on the step we just completed (see REMOVE-DEPENDENCY)
- We do this until we run out of instructions

Things are going to be a tiny bit more complicated for part 2:

- Each step takes a certain amount of time to complete: 60 seconds, plus a certain amount, depending on the step name (1 second for `A`, 2 seconds for `B`, ...)
- We are not alone in executing these instructions -- there are 4 elves helping us out, which means multiple steps can run in parallel

We are going to solve this by simulation; to do this, we are going to define a new structure, WORKERS, with the following slots:

- `'BUSY-FOR`, an array as big as the number of workers we have, to keep track of how much time each worker needs to complete the assigned step
- `'BUSY-WITH`, another array, this time keeping track of the step each worker is currently busy with

With this, the skeleton of our solutions is pretty simple: we initialize our WORKERS state, and until there are workers..._working_...we do another tick of our simulation; when done, we simply return the elapsed time:

Let's now take a look at the meat of this, WORKERS-TICK:

- We let all the workers progress on their assigned step, and keep track of the completed ones (as well as the workers that finished them)
- We keep the workers busy until there are workers available and unblocked instructions
- Finally, we return the updated list of instructions -- i.e. instructions we could not assign because either we run out of workers, or because active workers were still working on some dependencies

Final plumbing:

And that's it:

Advent of Code: [2018/12](https://adventofcode.com/2018/day/12)

Today we are given a bunch of pots, each containing (or not) plants; and some notes, describing how these pots change over time, based on the state of the adjacent pots:

>

>

Here is how our input is going to look like:

Anyways, as usual, let's get this input parsed; we are going to parse this into a list of 2 elements: in the first one, we are going to store the initial state of the pots; in the second, we are going to store all the notes describing how pots change over time.  I am going to be using a HASH-SET for both the initial state of the pots, as well as the set of rules; for the initial state, I am going to simply keep track of the positions of the pots that contain a plant; for the list of notes instead, I am only going to be storing the ones causing a plant to grow, or to stay unchanged (i.e. I am going to skip all the notes with a `.` on the left-hand side of the note...more to this later):

Now, for part 1, we are asked to evolve our array of pots over time, and see how things look after 20 generations:

>

>

As with most of the Game of Life problems, we are going to _evolve_ our state a fixed number of times (i.e. `iterations`), and then inspect the final state to come up withe the challenge's answer:

- We always start anew inside POTS-NEXT, as if all the pots were empty; this is the reason why we don't care about the notes resulting in the central pot to become empty, but only the ones resulting in pots with a plant in it
- As we keep track of plants using a HASH-SET, and not an array, we need to find the min / max positions first, and then iterate for all the values in between
- The `(- ... 4)` and `(+ ... 4)` is to make sure we catch changes happening on the _edge_
- SURROUNDING-POTS returns the state of the pots around a certain given position (this mostly makes up for the fact that we are using a HASH-SET instead of an array)
- SUM-PLANT-POSITIONS simply sums the positions of the pots with a plant (i.e. the answer to our problem)

Let's now take a look at part 2:

What?!  There has to be a loop involved...

I fed this to my FLOYD loop detector utility function, but unfortunately that kept on spinning forever:

Well, as it turns out, after a few generations the array of pots assume a certain configuration; a configuration which keeps on sliding to the right hand side, over and over again:

So how can we detect that?  Well, we could change SUM-PLANT-POSITIONS to count _relatively_ to the minimum position of a pot with a plant, instead of 0; and then tell FLOYD to use that to detect a loop:

Once we found our loop, all is left to do is figure out the number of cycles left to be done, how much SUM-PLANT-POSITIONS increases at each cycle, and then do some math to put together our solution:

Final plumbing:

And that's it:

Advent of Code: [2018/18](https://adventofcode.com/2018/day/18)

Game of life kind of problem today:

>

>

This is how our input is going to look like:

The only difference is that our input is going to be bigger, i.e. 50x50 instead of 10x10; let's parse this into 2D array:

Before taking a look at the rules governing how the area updates, minute after minute, let's see what exactly are we asked to do:

>

So we need to:

- Figure out how the area is going to look like after `10` minutes
- Count the number of acres with trees
- Count the number of acres with lumber
- Multiply the two together

To see how a given area is going to look like, after a minute we will have to:

- For each row
- For each column in the current row
- Inspect the surrounding 8 acres and count which ones are open, which ones have trees, and which ones have lumber
- Update the state of the current acre accordingly

Note: all the updates happen at the same time, so we need to make sure the original area is not updated as we process it.

As for the update rules instead:

All of the above, i.e. rules plus algorithm, nicely translates into the following, long-winded, function:

At this point, all is left to do is calculating the resource value of a given area:

Now, off to part 2:

_gulp_

Well, it turns out this _game_ is cyclic, i.e. after some time a given area configuration will keep on re-appearing over and over again; this means all we have to do is:

- Figure out when it starts cycling
- How big the cycle is
- How many iterations are left to be done if we remove the cycles

Easy peasy, especially if you already bumped into a similar problem before, and had an implementation for the [Floyd-Marshall](https://en.wikipedia.org/wiki/Floyd%E2%80%93Warshall_algorithm) algorithm handy:

Final plumbing:

And that's it:

Advent of Code: [2018/23](https://adventofcode.com/2018/day/23)

This problem's input is a list of _nanobots_, each representing a 3-d location, and a radius (more to this later):

We are going to put this into a structure with two slots:

- The 3-d location, stored as a list
- The communication radius

Now, let's take a look at the ask for part 1:

OK, easy enough:

Now, things are going to get messy with part 2:

OK, let's figure out what the bounding box of all the bots is, and then look for the point with the highest number of bots in range; except, the search space might be bigger that we thought:

That, and the fact that there will be a lot of overlapping (not only are bots well spread out into the 3d space, but they also have huge communication radius too):

We are going to need something clever than this, but what exactly?  Well, I originally solved this by [random walking the search space and drilling into the areas with the highest number of bots in range](https://github.com/iamFIREcracker/adventofcode/commit/75abd836d5502df6307c5c77ccc24b7d91d679e4#diff-e25508cbdc3137033eb7cc9d1a6d6c5f0a278b331eca80162a8defb74d5379a7L1255); however, that was not always guaranteed to work (yes, I got lucky for my second star), and after taking a good look at [r/adventofcode](https://reddit.com/r/adventofcode) and even reading the AoC creator [commenting](https://www.reddit.com/r/adventofcode/comments/aa9uvg/day_23_aoc_creators_logic/) on what he thought people should be implementing to solve this, I decided to give the "Octree scan" solution a try.

The basic idea is simple, and it relies on the recursive 3-d space subdivision logic that [octrees](https://en.wikipedia.org/wiki/Octree) implement when efficiently organizing 3-d objects in the space; what follows is an overview of the algorithm that we are going to implement to solve this:

- We start with the biggest bounding box possible, and we count the number of bots in range (all)
- Then we split this box in 8 equal parts, and count the number of bots in range of each
- We keep on doing this until the cubes becomes 3-d points
- We are going to need a way to prune non optimal branches as soon as possible, or chances are we are going to get stuck in this loop for quite some time (more to this later)

Let's start off by defining a BOX structure and create one instance covering for all the bots in our input:

(Note: we decide to make sure the box is actually a cube, and that each side is a power of 2, so we know the splitting will always be _even_)

Now, while waking through the search space, we would like to pick our next cube to analyze based on:

- Number of nanobots in range of the box: the higher, the better, as that's what we want to maximize, eventually
- Volume of the current box: the smaller, the better, as we want to converge to a solution (optimal or not) as soon as possible so we can use that to prune branching
- Distance from origin: again, the smaller, the better

We are going to create a new structure, for this, STATE, and customize its constructor as follows:

There are a lot of helpers function used here, so let's take a look at their implementations; COUNT-IN-RANGE first:

It relies on another helper function, NANOBOT-OVERLAPS-P, which all it does is calculating how far the nanobot is, from the box, and return T if that distance (i.e. it's a Manhattan distance) is smaller or equal than the nanobot radius itself:

Lastly, calculating one box's volume should be pretty straightforward:

Let's now take a look at the meat of this whole thing:

- We create the bounding box
- Initialize a sorted queue with it
- We start popping items from it until it's empty
- Now, until we have found _one_ solution (it could be the optimal one, or a sub-optimal one), or so long as the current box has a chance of containing a better solution (i.e. by having more nanobots than our current best solution)
- We split the box in 8, add those cubes to the priority queue, rinse and repeat
- Now, if we cannot split the cube further (i.e. it's a 3-d point), then we check for the number of nanobots covering this location, and if better than our best solution so far, we update that and carry on

Easy uh?! Yeah...

Let's take a look at those functions that we have never seen before; let's begin with STATE-BETTER-P, and as a reminder, this is the logic that we are going to try to implement:

- Number of nanobots in range of the box: the higher, the better, as that's what we want to maximize, eventually
- Volume of the current box: the smaller, the better, as we want to converge to a solution (optimal or not) as soon as possible so we can use that to prune branching
- Distance from origin: again, the smaller, the better

BOX-POINT-P instead, checks if the current box is actually a point (i.e. each range is `0` units wide):

BOX-SUBDIVISIONS finally, takes care of taking a box / cube, and generating all its 8 subdivisions; one thing to note here: we are going to check for the volume of the box first, and if it's `1`, it means we cannot split it any further, and we will go ahead and return 8 new boxes, each covering for one vertex of the cube; otherwise, we will find the mid point of each range, and create sub-cubes accordingly:

And that should be pretty much it.

Final plumbing:

Et voila'!

To get started with Sketch (the Common Lisp graphic framework, inspired by the Processing language), you will have to install SDL2 and some of its add-ons.

On a Mac, the most convenient way to do this is by using Homebrew:

With that done, you should now be able to load Sketch's examples just fine:

Note: as mentioned on this issue, [OSX Can't run hello world example #29](https://github.com/vydd/sketch/issues/29), when trying this out on SBCL, you will have to wrap the MAKE-INSTANCE call inside SDL2:MAKE-THIS-THREAD-MAIN, or most likely you will be presented with the following:

Alternatively, you can always switch to [CCL](https://ccl.clozure.com/) (another Common Lisp implementation) when playing with Sketch, as that one does not seem to be suffering from the same thread-related issue that SBCL does instead.

Advent of Code: [2018/20](https://adventofcode.com/2018/day/20)

We find ourselves into an area made up entirely of rooms and doors; the thing is, the Elves don't have a map for this area; instead, they hand us over a list of instructions we can use to build the map ourselves:

- `^` is the "start-of-instructions" marker
- `$` is the "end-of-instructions" marker
- `N` means you can go north (i.e. a door exists between the _current_ room, and the one _north_ to it)
- `E` means you can go east
- `S` means you can go south
- `W` means you can go west
- `(` marks a _fork_, meaning that multiple sub-paths can be started from the current room
- `|` marks the end of a sub-path
- `)` marks the end of the fork

A couple of examples will hopefully help understanding this; this simple list of instructions, `^WNE$`, can be used to build up the following map:

This longer instructions list instead, ` ^ENWWW(NEEE|SSE(EE|N))$`, can be used to create the following map:

Before figuring out how to create the map from the instructions, it's probably best to take a look at what we are asked to do for part 1, so here it goes:

OK, it seems like we are going to have to actually navigate through this map.  Let's parse the list of instructions into a HASH-SET of locations (i.e. COMPLEX numbers), referring to where the doors are; to do so, we are going to use a _stack_ of current positions, so we can keep track of every fork we step foot on; in particular:

- We skip the `^`
- If the current char is `$`, we stop and return the set of doors we went through
- If the current char is `(`, a new fork begins, so push the current position into the stack
- If the current char is `|`, a sub-path just ended, so let's go back to the room of the most recent fork
- If the current char is `)`, we visited all the sub-paths of a fork, so pop an item from the stack, and start from there
- Otherwise, i.e. one of `NESW`, move into the adjacent room and record the door we used to get there

All is left to do now, is to explore the complete map, figure out which room is the furthest away from us, in terms of number of doors to go through, and then return that number of doors; we can do this with an unbounded BFS:

- start point: `0,0` (or `(complex 0 0)`)
- no goal state / function -- it will stop when there are no more states to process
- from a given location, you can move into the adjacent room if a door exists in between -- see NEIGHBORS

For part 2, instead:

>

Easy:

Let's wire everything together:

And that's it:

Advent of Code: [2018/06](https://adventofcode.com/2018/day/6)

Today, we are given a bunch of coordinates (i.e. X,Y locations), representing what could be either be dangerous safe places to land on -- and yes, we are falling.

This is a sample input:

We are going to be parsing this into _tagged_ coordinates, i.e. coordinates with a tag information attached to it (more to this later); as usual, we would be representing coordinates as COMPLEX numbers:

For part 1, we are going to assume these to be _dangerous_ coordinates, and we are going to try and find which one is the furthest away (in terms of Manhattan distance) from all of the others.  How?

>

Here is how we are going to solve this:

- We find the bounding box, i.e. the smallest rectangle containing all the coordinates of the input -- see BOUNDING-BOX
- For each X,Y point of this bounding box
- We find the input coordinate which is _closest_ to that, being careful to ignore any point which is equally distant to 2 or more coordinates -- see CLOSEST-POINT
- Then if the we are _not_ on the border (see ON-THE-BORDER-P), we mark the location with the tag of the closest input coordinate (we are not actually marking it, but rather counting, but you get the idea)
- Finally, we find the input coordinate with the highest number of _closest_ locations

In code:

For part 2, we are going to assume these input locations to be _safe_ to land on instead, so we are going to try and find the region near as many coordinates as possible:

- For each X,Y location inside the same bounding box as part 1
- Sum all the distances with respect of all the input coordinates -- see TOTAL-DISTANCE
- Increment a counter if this sum is less than 10000

Final plumbing:

And that's it:

Advent of Code: [2018/04](https://adventofcode.com/2018/day/4)

December 1st is right around the corner, and we better get in "advent-of-code"-shape real quick; and what better way to do that than re-working some of my oldest solutions, i.e. the ones from 2018, when I was just trying to get started with Common Lisp?!  2018, day 4 it is!

For today's challenge we are tasked to sneak inside a supply closet so we can fix our suit; however, the closet is protected by a guard, so we need to figure out our way in without getting caught.  Lucky us, someone has been keeping tabs on guards shift (it's sleeping schedule, our input), and by the look of it it appears guards would fall asleep quite often, so hopefully we can figure out the best time to get in.

This is the kind of input that we are given:

We are going to parse all this into an ALIST having the guard ID as index; the value would be another ALIST having the minute as index (note: for each day, we are told to analyze the `00:00`-`00:59` time range only); the value, would be the list of days in which the specific guard fell asleep for the specific minute.  The example above would be parsed into the following:

Doing the actual parsing turned out way hairier than I originally anticipated, but whatever; anyways, high level:

- Sort entries lexicographically (yes, the input is out of order)
- Recursively
- Parse guard ID -- PARSE
- Parse "falls-asleep" time and day -- FILL-IN-SCHEDULE
- Parse "wakes-up" time and day -- FILL-IN-SCHEDULE
- For each minute in the time range
- Update the schedule accordingly -- ADD-ASLEEP-TIME-DAY

The rest is a bunch of selectors for writing / pulling data into / out of the schedule:

Now, let's get to the juicy part:

We find the schedule entry with the highest count of minutes asleep first; then, in that entry, we look for the _minute_ entry in the sleep table with the highest count of days; finally do the multiplication:

For part 2 instead:

We find the entry with the highest number of of days associated for any given minute (note: we don't want the minute but the number of days the guard feel asleep for that given minute, that's why we are using NTH-VALUE here); then we call SLEEPIEST-MINUTE on that; we do multiplication last:

Final plumbing:

And that's it:

Abusing Common Lisp feature expressions to comment things out! (another follow up) @vim @commonlisp

The simple syntax rules that I mentioned inside one of my previous [.plan entry](https://matteolandi.net/plan.html#day-2021-10-29) turned out to break quite easily in case of nested parentheses; so I decided to try a different approach instead, and after playing with Vim's syntax regions a bit, I came up with the following:

With this I was able to deal with nested parentheses just fine; however, if I there were `highlight` commands defined for any of the elements contained inside the `@lispBaseListCluster` cluster (and of course there are!), then Vim would end up coloring those elements; what I wanted instead, was the whole region to look like a `lispComment`.  This is where I got stuck; this is where I started questioning the whole approach altogether, and where I ended up asking for [help](https://www.reddit.com/r/vim/comments/qmn052/override_colors_based_on_the_surrounding_syntax/) on the /r/vim sub-reddit.

Anyways, long story short, one reply made me realize that I did not actually need all the definitions included inside the `@lispBaseListCluster` cluster, especially if then I would need to figure out a way to mute their colors; so what I did instead, was creating a new, simpler but recursive syntax region, to cater for my _excluded_ lists:

I then updated my original `lispExcludedFormWithNil` definition to _contain_ `lispExcludedList` instead of the `@lispBaseListCluster` cluster:

And that's it; with this, it all started to work as expected:

If I then were to add `lispExcludedFormWithNil` to the `@lispBaseListCluster`:

Then this would work even in case the _excluded_ expression was found nested inside another expression / list:

Sweet!

So how is my Lisp syntax file looking?  There you go:

PS. Yes, I created a script function, `createLispExcludedSyntaxRegion`, to make the process of creating new syntax regions a tiny bit less hairy.

(Trying to) Speed up Common Lisp Replit REPLs startup time -- or how to both install Quicklisp and cache *.fasl files in the current directory @commonlisp @replit

All of my Common Lisp Replit REPLs have the following defined inside '.replit-files/init.lisp' (that's the script I am loading when starting up SBCL):

This pretty much translates to checking if '~/quicklisp/setup.lisp' already exists; if it does, it means we already got Quicklisp set up, so we go ahead and load that file up; otherwise, we load 'quicklisp.lisp' from the local directory (it's a copy of the file available on [quicklisp.org](https://www.quicklisp.org/beta/)), and then install Quicklisp altogether.

After this, with Quicklisp installed, all is left to do is loading up our app (the following is an example from a [recent REPL of mine](https://github.com/iamFIREcracker/cl-face-mask-ce-verifier/blob/master/build/replit.lisp)):

Now, as you can imagine, the following two main activities will be slowing down the REPL startup time:

1. Bootstrapping Quicklisp, i.e. downloading it, installing it, fetching the latest dist
2. Loading / compiling the application system, and all its dependencies

Now, doing this once is perfectly fine, but can we configure things so that we don't have to do this over and over again, when Replit decides your REPL needs to be put to sleep or moved off to a new instance?

The answer to that question is of course: "yes!"; basically all we have to do is make sure that all the artifacts which were dynamically generated and which were needed by the REPL, are saved somewhere inside the REPL workspace (yes, your REPL workspace will pretty much always be kept around).

Alright; let's start off by changing our Quicklisp install script as follows:

Here, we look for Quicklisp's setup script inside '.quicklisp/setup.lisp' instead of the canonical '~/quicklisp/setup.lisp' (note how we are using *DEFAULT-PATHNAME-DEFAULTS* instead of `(user-homedir-pathname)`); we also pass `:path (merge-pathnames ".quicklisp/" *default-pathname-defaults*)` to `QUICKLISP-QUICKSTART:INSTALL`, effectively telling it to install everything inside the local directory, '.quicklisp'.  Nice!

Now, to change the location where ADFS stores compiled files to make sure it's in the current workspace, we will have to play with ADFS's [Configuration DSL](https://common-lisp.net/project/asdf/asdf/Output-Configuration-DSL.html) a bit; it took me some Googling around ([1](https://gitlab.common-lisp.net/asdf/asdf/-/issues/22), [2](https://www.mail-archive.com/asdf-devel@common-lisp.net/msg06372.html), [3](https://stackoverflow.com/questions/25323394/asdf-output-redirection), and [4](https://www.reddit.com/r/lisp/comments/23azqf/need_help_setting_asdf_cache_output_directory/)) and quite a few tries before I got this to work; but ultimately, this is what I came up with:

Again, you can read more about the DSL in the link above, but in general:

1. Using `:implementation` forces ASDF to use separate directories, inside '.common-lisp', based on the current Lisp implementation; this way, should we change the REPL to use CCL instead of SBCL, it would compile everything from scratch, instead of trying to load the artifacts generated while we were using the other implementation
2. Using `:disable-cache` tells ASDF to stop caching compiled files under '$XDG_CONFIG_HOME/.common-lisp'; this is the behavior that the previous rule is meant to override, so disabling this will hopefully make sure the default caching mechanism won't get in our way
3. Using `:ignore-inherited-configuration` tells ASDF to ignore any other _inherited_ rule; now, I am not entirely sure what this is for, but ASDF was complaining that I should use either `:inherit-configuration` or `:ignore-inherited-configuration` when calling `INITIALIZE-OUTPUT`, so here it is

Anyways, restart the REPL, and you should now finally see the '.quicklisp' and '.common-lisp' local directories being put to good use:

And that's it!  Until the next time...

TIL: You cannot use plain HTTP with a .dev domain; Google will force a HTTPS redirect! https://ma.ttias.be/chrome-force-dev-domains-https-via-preloaded-hsts/

Today I woke up to realize that I could not deploy anything to my VPN anymore:

Figured it had something to do with with the recent [Let's Encrypt's root certificate getting expired](https://techcrunch.com/2021/09/21/lets-encrypt-root-expiry), so I went on and upgraded my OS certificates (yeah, that plus all the other packages I had not upgraded in a while):

Then I tried to re-deploy again; it did not succeed, but at least the error message was different:

First I upgraded `pip`:

Then uninstalled a bunch of borked packages:

And re-installed them again:

And after this, it all went back to normal... Crisis averted!

Abusing Common Lisp feature expressions to comment things out! (a follow up) @vim @commonlisp

I posted a link to my previous [.plan entry](https://matteolandi.net/plan.html#day-2021-10-23) on [/r/Common_Lisp](https://www.reddit.com/r/Common_Lisp/comments/qfgci7/abusing_common_lisp_feature_expressions_to/) the other day, and a couple of things came out.

First off, an evil person could add `:nil` to *FETURES* and break hell loose:

Uh oh...

Then someone else suggested to use [unintenred symbols](http://www.lispworks.com/documentation/HyperSpec/Body/02_dhe.htm) instead, as that will not only keep you safe from the previously mentioned problem, but also give you the opportunity to _document_ why the specific form / element got intentionally excluded:

Again, let's try this out

Alright then, I think I like _uninterned symbol_ approach better, so I am going to update my Vim files as follows:

Right on!

Abusing Common Lisp feature expressions to comment things out! @vim @commonlisp

Today I realized that I can easily comment out a form by placing a `#+nil` in front of it, and this turned out to be quite useful and productive especially when throwing things out at the REPL.

Let's take a look at an example (this was taken from a [recent](https://github.com/iamFIREcracker/cl-face-mask-ce-verifier) small project of mine):

The bit to focus your attention to is the second line, which in words, pretty much translates to:

Now, while working on this, I realized FMCV:NB-SEARCH could sometimes take up to 3 seconds to return, and since there wasn't much I could do about it (i.e. it was the external service the function was calling behind the scenes, which was taking so long to reply), I decide to make the whole development experience a tiny bit more enjoyable by introducing a little bit of caching:

- call the API once
- save the response somewhere
- change the logic to read from the cached response until I was done with everything else

The above just works, 100%; however, it also makes it difficult to quickly switch between implementations.  For example, should I want to hit the external API again, I would have to put the FMCV:NB-SEARCH function call back in, and that would be a lot of typing /s

This is where [feature expressions](http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/sec_24-1-2-1.html) could come to the rescue:

- Keep both *cached-bodies* and the FMCV:NB-SEARCH call in place
- Want to use the cached response?  Place a `#+nil` in front of the FMCV:-NB-SEARCH call

- Want to hit the external service instead?  Place a `#+nil` in front of *cached-bodies*

Note: `#+` is a reader macro that operates on the next two expressions found in the stream; if the first expression evaluates to non-NIL, then the macro would emit the second expression; otherwise, it would swallow it.  Now, we are always feeding the macro with a NIL as first expression, so basically we are telling it to swallow the second expression, always!

Pretty cool uh?!

_All the Vim haters should stop reading here_

I was so excited by this that I ended up creating two Vim mappings to automate this:

- `gce` to add (or remove) a `#+nil` in front of the current element (_element_ in the [vim-sexp](https://github.com/guns/vim-sexp) sense)
- `gcf` to add (or remove) a `#+nil` in front of the current form

It's a bit hack-y to be honest, but whatever!

Also, you can even change the relevant syntax file (e.g. ~/.vim/after/syntax/lisp.vim) and make these regions look like comments:

What a joy!

Until next time...

How to verify the CE marking on your face mask?!

First off, what does the CE marking mean? From [Wikipedia](https://en.wikipedia.org/wiki/CE_marking):

It continues:

So, for example, when you read `CE-2233` on a product, `CE` represents the CE marking (duh), while `2233` refers to ID of the notified body involved in conformity assessment.

Now off to the verification part.

Note: the steps listed below will help you verify that the notified body involved with the assessment is..._legit_, i.e. can actually issue the specific conformity assessment certificate; however, these won't help with verifying that the specified notified body had indeed run a conformity assessment on a given product (i.e. the product seller could lie about this, but as the Wikipedia article states, this is considered a criminal offense and by consequence, and published by law).

- To sell face masks in the UE, you need the CE marking
- For this matter, notified bodies need to be competent with the '2016/425
  Personal protective equipment' legislation
- They also need to be entitled to issue specific conformity assessment modules for 'Equipment providing respiratory system protection' products (e.g. face masks)
- Luckily for us, an online database exists,
  [NANDO](https://ec.europa.eu/growth/tools-databases/nando/index.cfm), storing
  all this information about all the registered bodies

So, without further ado, navigate to: [Nando](https://ec.europa.eu/growth/tools-databases/nando/index.cfm) > [Free search](https://ec.europa.eu/growth/tools-databases/nando/index.cfm?fuseaction=search.main).

Take the CE numerical value (i.e. the `2233` part of `CE-2233`), populate the `Keyword On Notified body number` field with it, and press the `Search` button.

Now `Ctrl+F` for the CE numerical value (i.e. the `2233` part of `CE-2233`), and if you are lucky enough, you should find a match inside the `Body type` column:

Click on the link in the second column to open up the page listing addresses, contact details, and all the legislations that the notified body has scoped to assess and certify against.

>

>

>

>

>

>

>

>

Search for the `Personal protective equipment` entry inside the Legislations table, and click on the link labeled with `HTML`.  On this page you will find all the information the notified body has been certified for.

You should first confirm that there is a entry for `Equipment providing respiratory system protection`; without this, even the PPE certification notified body cannot engage in CE certification activities of protective masks).  Then, you will have to confirm the "conformity assessment" modules that the notified body is entitled to issue; in particular we are looking for:

- [Module B: EU type-examination](https://support.ce-check.eu/hc/en-us/articles/360019298431-Conformity-Assessment-Module-B)
- [Module C2: Supervised product checks at random intervals](https://support.ce-check.eu/hc/en-us/articles/360019507611-Conformity-Assessment-Module-C2-)
- [Module D: Quality assurance of the production process](https://support.ce-check.eu/hc/en-us/articles/360019191712-Conformity-Assessment-Modules-D-D1)

Note: that manufacturers can only enter the EU market legally after obtaining a Module B + Module C2 certificate or a Module B + Module D certificate

>

>

>

>

>

By the looks of the information shown above, it appears that this notified body have all it takes to properly run conformity assessments against face masks...Hurray!

Links:

- [Guide to using NANDO website to identify Notified Bodies PPE](https://yewtu.be/watch?v=ceCAceuDOhE)
- [Mascherine Ffp2, ecco i codici certificati CE non a norma e lo strumento di verifica Ue](https://quifinanza.it/info-utili/video/mascherine-ffp2-covid-codici-certificati-ce-non-a-norma/471686/)
- [How to Verify CE Certification?](https://verifyfull.com/how-to-verify-ce-certification%EF%BC%9F/)

Today I fucking figured out how to make Vim's * / # not suck! @vim

There is a lot of copy-pasta in there, but it gets the job done and given the amount of time I have already spent on this today, or in the past even, I think it's time to move on!

`ScratchThis`, a Vim command to make the current buffer a `scratch` one (see `:h special-buffers` for additional info):

Nice little vim/fugitive gem: use `!` to open a command prompt with the file under the cursor.

It's very handy if you want to delete an untracked file (see https://github.com/tpope/vim-fugitive/issues/23).

netrw comes with an identical mapping too!

Notes about reverse engineering Basecamp's Recording pattern

Before we begin: I never used RoR nor programmed in Ruby, so apologies if some of the things mentioned are inaccurate or completely wrong; I simply got interested in the pattern, and tried my best to understand how it could have been implemented.  So bear with me, and of course feel free to suggest edits.

Main concepts:

- Buckets are collections of records, i.e. _recordings_, having different types e.g. `Todo`, `Todoset`
- Recordings are just pointers, pointing to the actual data record, i.e. the _recordables_
- Recordables are immutable records, i.e. every time something changes, a new _recordable_ record is created and the relevant recording is updated to point to it
- Events are created to link together 2 recordables (the current version and the previous one), the recording, the bucket, and the author of the change
- This enables data versioning
- This enables data auditing (at the recording level, at the bucket level, and at the user level)

It all started with this [tweet](https://twitter.com/dhh/status/962156053461843968?lang=en):

This is how a Basecamp URL looks like: `/1234567890/projects/12345/todos/67890`

In it:

- `1234567890` is the account ID -- it identifies a company's instance, it represents a tenant
- `12345` is the bucket ID, pointing to a record whose `bucketable_type` is `Project`
- `67890` is the recording ID, pointing to a record whose `recordable_type` is `Todo`

Bucket is not a project, but links to one (project is the _bucketable_ entity):

Recording is not a todo, but links to one (todo is the _recordable_ entity):

Recordables are immutable, and do not usually have all the created-at, updated-at metadata...recordings do!  Also, multiple recordings can point to the same recordable, hence the `has_many :recordings` inside the `Recordable` concern.

Recordings have parents, and children; it almost becomes a graph database, with a tree structure:

- recording.recordable_type: Todo
- recording.parent.recordable_type: Todolist
- recording.parent.parent.recordable_type: Todoset
- recording.parent.parent.parent.recordable_type: Dock
- recording.parent.parent.parent.children.map(&:recordable_type): Chat::Transcript, Message::Board, Todoset, Schedule, Questionnaire, Vault

The above, i.e. the tree structure, is most likely implemented via the `Tree` concern:

Note: I don't assume the above to be correct, but it should get the job done; I question whether it would make sense to add a _type_ field on this parent/child relation, but maybe it's not strictly required (i.e. you always know that one todo's parent is a todolist).

As stated above, recordings are pointers, almost like symlinks, and when you update a todo, you don't actually update the record, but create a new one, and update the recording to point to that; since URLs are all keyed-up accordingly (i.e. they use Recordings IDs, and not Recordable ones), the URL does not change but the actual todo the recording point to does.

Controllers then look something like this:

While this is how `Bucket.record` looks like:

This enables you to do things like, "Copy message to a new project", way more efficient: previously you had to set up a new job that literally copied the message, the comments, the events onto the new project; while now, all you have to do is set up a new recording pointing to the existing _immutable_ recordable.

For example:

- Project has messages -- messages are recordables
- Messages have comments -- comments are recordables
- When you copy a message from one project to another, you will have to create a recording not just for the message to be copied, but for all its existing comments as well (that's what `children` inside `Bucket.record` is for)

Note: `children` inside `Bucket.record` is expected to be a list of recordables, and not recordings; this means to pass `children` to `Bucket.record` we will have to do something along the lines of: `message.recording.children.map(&:recordable)`.

Note: `Bucket.record` (at least the version above, which was [shown in the presentation](https://www.youtube.com/watch?v=tmWlm0M6JSk&t=3060s)) does not seem to recurse more than one level, which means you can only create recordings for the parent entity and its direct children, e.g., messages and comments, but not `Todoset`s `Todolist`s _and_ `Todo`s.

Note: is this more efficient, really?  Even though you will not have to copy the immutable records (i.e. the recordables), you will still have to recreate the same recordings tree, right?

After you copied a recording, you should end up with something like this:

Again, two pointers, i.e. recordings, pointing to the same immutable record, i.e. the recordable.

Note: a recordable has many recordings, not one; this is because the same recordable object can be pointed by two different recordings.

This Recording pattern works in tandem with `Event`s:

- They link to the newer version of the recordable, and the previous one
- They belong to a `Recording`: this way you can easily see all the times a recording was updated
- They belong to a `Bucket`: this way you can easily see all the times a bucket was updated
- They belong to a `Person`: this way you can easily see all the changes done by one user
- They have one `Detail`, i.e. a hash containing some additional metadata linked to the current event

and with the `Eventable` concern:

`track_event` here is the generic method, but more specific ones exist as well, for more common use cases so we don't have to manually plumb arguments.

We track an event every single time an eventable is created, or updated:

The private method `track_created` simply delegates to `track_event`:

A recordable has many events; again, the same recordable could referenced by multiple recordings, and since events are created when recordings are created, then that's how you end up with multiple events.

OK, great, nice, but what schema would enable such a pattern?  Again, not 100% accurate, but hopefully close enough:

- Buckets (id, bucketable_type, bucketable_id, ...)
- Recordings (id, bucket_id, recordable_type, recordable_id, parent_id, ...)
- Events (id, bucket_id, recording_id, recordable_id, prevous_recordable_id, user_id, ...)

Note: recordables are _untyped_ here, but the type information is actually one join-table away, i.e. it's available inside the linked recording

- Projects (id, ...)
- Messages (id, ...)

And this seems to be it really.

Note: this pattern heavily relies on Rails delegate types, i.e. sugar on top of polymorphic associations (see [rais/rails/pull#39341](https://github.com/rails/rails/pull/39341)), to automatically traverse the recording table to automatically get to the recordable entry.  My first thought was: how will this perform?  How is the extra join operation required to fetch any linked entity going to affect performance?  If it's working for Basecamp, hopefully it's working decently enough for other applications as well, but I guess it also depends on how much the different entities are linked together.

Note: in the end, this is not that different from 'time-based versioning' (read: [Keeping track of graph changes using temporal versioning](https://medium.com/neo4j/keeping-track-of-graph-changes-using-temporal-versioning-3b0f854536fa)), with recordings being the _identity_ nodes, and recordables being the _state_ objects.

Some references:

- [Basecamp 3 Unraveled](https://www.youtube.com/watch?v=tmWlm0M6JSk&t=3060s) -- where an overview of the Bucket/Recording pattern is given
- [On Writing Software Well #3: Using globals when the price is right](https://www.youtube.com/watch?v=D7zUOtlpUPw&t=653s) -- where `Eventable` concern, and the `Event` model are shown
- [On Writing Software Well #5: Testing without test damage or excessive isolation](https://www.youtube.com/watch?v=5hN6OZDyQtk&t=419s) -- where the `Recording` model is shown
- [GoRails: Recording pattern (Basecamp 3)](https://gorails.com/forum/recording-pattern-basecamp-3)

Grokking Simplicity notes

This page of the book says it all:

>

>

>

>

>

Where here is the list of primitives presented in the book to work with timelines.

Serialize tasks with `Queue`:

Example:

Serialize tasks and skip duplicate work with `DroppingQueue`:

Example:

Synchronize (i.e. cut) multiple timelines with `Cut`:

Example:

Make sure a function is called only once, with `JustOnce`:

Example:

Encapsulate state inside _reactive_ `ValueCell`s:

Example:

Derived values can instead be implemented with `FormulaCell`s:

Example:

Location sharing alternative to the Google built-in one @idea

- It would be fun
- You would not have to share data with Google (why would anyone share it with you instead? My friends and family probably would!)

Streamlining answering the donors questionnaire @idea

"Which cities have you visited during the last 4 weeks?"
"Which countries have you visited over the last 6 months?"

These are some questions donors get asked over and over again before they are are cleared for the donation, and it always catches me off guard.  Can this information be automatically pulled from Google?

What about my wife's data instead, would I have access to it?  During COVID, most of the time it's not just about the place you have visited, but the places other people you are living with had...

[The Lisp Curse](http://www.winestockwebdesign.com/Essays/Lisp_Curse.html)

Remote live coding a Clack application with Swank, and Ngrok

Today I would like to show you how to create a very simple CL Web application with Clack, and how to use Swank and [Ngrok](https://ngrok.com/) to enable remote [live coding](https://en.wikipedia.org/wiki/Live_coding).

Here is what we are going to wind up with:

- Clack application running on `localhost:5000` -- i.e. the Web application
- Swank server running on `localhost:4006` -- i.e. the "live coding" enabler
- Ngrok tunnel to remotely expose `localhost:4006` (just in case you did not have SSH access into the server the app is running on)

As usual, let's start off by naming all the systems we are depending on:

- `clack`, Web application environment for CL
- `ngrok`, CL wrapper for installing and running Ngrok
- `swank`, what enables remote "live coding"
- `uiop`, utilities that abstract over discrepancies between implementations

Now, `ngrok` has not been published to Quicklisp yet, so you will have to manually download it first:

...and then make sure it is QL:QUICKLOAD-able:

Now you can go ahead and load all the required dependencies:

Let's take a look at the MAIN function. It starts the Web application, the Swank server, and Ngrok:

For the Web application:

- We define a special variable, *HANDLER*, to hold the Clack Web application handler
- We start the app, bind it on `localhost:5000`, and upon receiving an incoming request we delegate to SRV
- Inside SRV, we delegate to APP (more to this later)
- Inside APP, we finally process the request and return a dummy message back to the client

You might be wondering: "why not invoking CLACK:CLACKUP with #'APP? Why the middle-man, SRV?"  Well, that's because Clack would dispatch to whichever function was passed in at the time CLACK:CLACKUP was called, and because of that, any subsequent re-definitions of such function would not be picked up by the framework.  The solution? Add a level of indirection, and so long as you don't need to change SRV, but always APP, then you should be all right!

Let's now take a look at how to setup a Swank server.  First we ask the user for a secret with which to [secure](https://github.com/slime/slime/issues/286) the server (i.e. it will accept incoming connections only from those clients that do know such secret), then we write the secret onto ~/.slime-secret (yes, it's going to overwrite the existing file!), and last we actually start the server:

Last but not least, Ngrok: we read the authentication token, so Ngrok knows the account the tunnel needs to be associated with, and then we finally start the daemon by specifying the port the Swank server is listening to (as that's what we want Ngrok to create a tunnel for) and the authentication token:

Give the MAIN function a go, and you should be presented with a similar output:

Let's test the Web server:

It's working.  Now open Vim/Emacs, connect to the Swank server (i.e. host: `6.tcp.eu.ngrok.io`, port: `12321`), and change the Web handler to return something different:

Hit the Web server again, and this time it should return a different message:

Note how we did not have to bounce the application; all we had to do was re-define the request handler...that's it!

Happy remote live coding!

PS. The above is also available on [GitHub](https://github.com/iamFIREcracker/cl-clack-swank-ngrok), and on [Replit](https://replit.com/@iamFIREcracker/cl-clack-swank-ngrok).

Web scraping for fun and profit^W for a registration to get my COVID-19 jab

Rumor says that in a few days everyone in Tuscany, irrespective of their age, could finally register for their first shot of the vaccine; that means "click day", i.e. continuously polling the registration website until your registration category is open.  I am sure a bird will eventually announce when the service will be open, i.e. the time of the day, so no need to stay on the lookout for the whole day, but I figured I could use this as an excuse to do a little bit of Web scraping in Common Lisp, so here it goes.

Dependencies first:

The next step is writing our MAIN loop:

- Wait for categories to be activated: new categories can be added, or existing ones can be activated
- Send an SMS to notify me about newly activated categories (so I can pop the website open, and try to register)
- Repeat

WAIT-FOR-ACTIVE-CATEGORIES is implemented as loop form that:

- Checks if categories have been activated, in which case the list of recently activated ones is returned
- Otherwise it saves the current timestamp inside *LAST-RUN-AT* and then goes to sleep for a little while

Let's now dig into the category processing part.  First we define a special variable, *CATEGORIES-SNAPSHOTS*, to keep track of all the past snapshots of services we scraped so far; next we fetch the categories from the remote website, see if any of them got activated since the last scraping, and last we push the latest snapshot into *CATEGORIES-SNAPSHOTS* and do some _harvesting_ to make sure we don't run out of memory because of all these scraping done so far:

Before fetching the list of categories we are going to define a few utilities: a condition signaling when HTML is returned in spite of JSON (usually a sign that the current session expired):

The URLs for the registration page (this will be used later, when generating the SMS) and for the endpoint returning the list of categories:

A cookie jar to create a _persistent_ connection with the website under scraping:

With all this defined, fetching the list of categories becomes as easy as firing a request to the endpoint and confirm the response actually contains JSON and not HTML: if JSON, parse it and return it, otherwise, simply try again.  The idea behind "trying again" is that when the response contains HTML, that will most likely contain a redirect to the home page with a newly created session cookie, and since the same cookie jar is getting used, the simple fact that we processed that response should be enough to make the next API call succeed:

Note: we retry only once, so if two consecutive responses contain HTML instead of JSON, that would result in the debugger to pop open.

Finding all the recently activated categories consists of the following steps:

- for each category just scraped
- compare it with the same in the last snapshot of categories
- a category is considered as _recently_ activated if it's active and it is not present inside the second to last snapshot, or it was present but either it was inactive or if its title has changed (yes, sometimes the title of a category is changed to advertise that new people with different age can now sign up)

Anyways, all the above translates to the following:

Harvesting is pretty easy: define a maximum length threshold for the list of snapshots and when the list grows bigger than that, start popping items from the back of the list as new values are pushed to the front:

Note: I could have removed "consecutive duplicates" from the list, or prevented these from getting stored in the list to begin with, but I am going to leave this as an exercise for the reader ;-)

Two pieces of the puzzle are still missing: RANDOM-SLEEP, and SEND-SMS.  For RANDOM-SLEEP we decide the minimum number of seconds that the scraper should sleep for, and then add some _randomness_ to it (like the remote site cared that we pretended to try and act like a _human_, but let's do it anyway):

For the SMS part instead, we are going to use Twilio; first we define all the parameters required to send SMSs:

- Account SID
- Auth token
- API URL
- From number
- To numbers (space separated values)

Next we assemble the HTTP request, fire it, and do some error checking to signal an error in case it failed to deliver the message to any of the _to_ numbers specified inside *TWILIO-TO-LIST*:

Last but not least, the SMS body; we want to include in the message which services got activated since the last time the scraper run, and to do so we:

- Take the latest snapshot from *CATEGORIES-SNAPSHOTS*
- Temporarily set *CATEGORIES-SNAPSHOTS* to its CDR, like the latest snapshot wasn't recorded yet
- Call FIND-RECENTLY-ACTIVATED effectively pretending like we were inside CATEGORIES-ACTIVATED-P and were trying to understand if anything got recently activated (dynamic variables are fun, aren't they?!)

Note: "Ora attivi:" is the Italian for "Now active:"

And that's it: give `(main)` a go in the REPL, wait for a while, and eventually you should receive an SMS informing you which category got activated!

Happy click day, Italians!

TIL: Untracked files are stored in the third parent of a stash commit.

Source: [stackoverflow](https://stackoverflow.com/questions/12681529/in-git-is-there-a-way-to-show-untracked-stashed-files-without-applying-the-stas#:~:text=Stash%20entries%20can%20be%20made,as%20part%20of%20the%20diff)

Few days ago Replit announced support for [every programming language](https://twitter.com/Replit/status/1396915485325860868)!

I never heard of [NixOS](https://nixos.org/) (that's what enables them to support "every programming language"), but I decided to give it a go anyway, and after a little bit of struggles I was then able to put together the following Repls:

- [Common Lisp](https://replit.com/@iamFIREcracker/Common-Lisp) -- of course the first one had to be one about CL
- [Common Lisp w/ SSL](https://replit.com/@iamFIREcracker/Common-Lisp-with-SSL) -- it turns out you have to mess with `LD_LIBRARY_PATH` to get SSL to work with `:cl+ssl`
- [Game of Life in Common Lisp](https://replit.com/@iamFIREcracker/Common-Lisp-greater-Game-of-Life) -- why not...
- [10 PRINT.BAS](https://replit.com/@iamFIREcracker/10PRINTBAS) -- ever heard of the famous one-line Commodore 64 BASIC program to generate mazes?  They even wrote a whole [book](https://10print.org/) about it!

This is pretty cool, well done Replit!

This is the famous one-line Commodore 64 BASIC program to generate random mazes (the Commodore 64 uses the [PETSCII](https://www.c64-wiki.com/wiki/PETSCII) character set, not ASCII):

While this is a Common Lisp equivalent:

If the above run a little bit too fast int he REPL (it most likely will, these days), then you can try with this other alternative:

Happy retro-hacking!

Example of how to use [AbortController](https://developer.mozilla.org/en-US/docs/Web/API/AbortController) to cancel an action when input changes:

Source: [twitter](https://twitter.com/jaffathecake/status/1395682545090633729)

Configuring lightline.vim to display the quickfix's title

In case anyone was interested in displaying the quickfix title while on quickfix buffers (works with location-list buffers too), all you have to do is loading the following into the runtime:

Before:

And after:

Related link: https://www.reddit.com/r/vim/comments/ej2bvx/change_the_quickfix_title/

Lack's Redis session store does not appear to be thread-safe

Steps to reproduce:

- Load the necessary dependencies:

- Setup a dummy "Hello, World" application:

- Setup the middleware chain, one that uses Redis as session storage:

- Start the app:

- Run `wrk` against it:

Expected behavior:

- The test runs successfully, and the number of requests per second is reported

Actual behavior:

- Lots of errors are signaled; from unexpected errors:

... to unexpected end of file:

A similar error was mentioned on `cl-redis` GitHub's space ([cl-redis/issues#19](https://github.com/vseloved/cl-redis/issues/19)), to which the author replied that one the reasons why this might happen is when trying to share the same connection between multiple threads.  So a took a look the implementation of the Redis store, and it looks like it is indeed sharing the same Redis connection between different HTTP requests (i.e. multiple threads).

The following seems to be fixing the problem though I would like to hear @fukamachi's view on this, before submitting a pull-request:

Andrew Sorensen Keynote: "The Concert Programmer" - OSCON 2014 ([link to video](https://www.youtube.com/watch?v=yY1FSsUV-8c))

Calling MAKE-INSTANCE with a class name which is only known at run-time

In CL, how can you instantiate a class (i.e. call MAKE-INSTANCE) if you had a string representing its name (and the package it was defined in)?

At first I gave INTERN ago (I am not exactly sure why though, but that's where my mind immediately went to), but then irrespective of the case of the string I feed into it, it would end up using quote characters (i.e. `|`s).  READ-FROM-STRING on the other hand seemed to get the job done, though I would like to avoid using it as much as possible, especially if the string I am feeding it with is getting generated _externally_ (e.g. sent over a HTTP request).

Well, as it turns out, if you have the strings in `package:symbol` format, then you can parse out the package and symbol names and use FIND-PACKAGE and FIND-SYMBOL to get the symbol you are looking for:

PS. @zulu.inuoe on Discord was kind enough to post this utility function that he uses:

Splitting routes into packages, with Caveman

If you use [caveman](https://github.com/fukamachi/caveman) to build your Web applications, sooner or later you will realize that it would not let you create an <APP> instance in one package, and use DEFROUTE in another.  Why? Because the library internally keeps a HASH-TABLE mapping <APP> instances to the package that was active at the time these instances were created, and since DEFROUTE looks up the <APP> instance in this map using *PACKAGE* as key, if the current package is different from the one which was active when <APP> was created then no <APP> instance will be found, and error will be signalled, and you will be prompted to do something about it:

Of course I was not the first one bumping into this (see [caveman/issues/112](https://github.com/fukamachi/caveman/issues/112)), but unfortunately the one workaround listed in the thread did not seem to work: it's not a matter of carrying the <APP> instance around (which might or might not be annoying), but rather of _changing_ *PACKAGE* before invoking DEFROUTE so that it can successfully look up the <APP> instance inside *PACKAGE-APP-MAP* at macro expansion time.

But clearly you cannot easily change *PACKAGE* before executing DEFROUTE, or otherwise all the symbols used from within the route definition will most likely be unbound at runtime (unless of course such symbols are also accessible from the package in which the <APP> instance was created).  So where do we go from here?  Well, if we cannot _override_ *PACKAGE* while calling DEFROUTE from within a different package, then maybe what we can do is _adding_ *PACKAGE* to *PACKAGE-APP-MAP* and make sure it links to the <APP> instance you already created!

Add a call to REGISTER-ROUTES-PACKAGE right before your first call to DEFROUTE and you should be good to go:

Ciao!

On adding Webpack assets to a server-side rendered view (in Common Lisp)

First you need to instruct `webpack` to save compilation metadata such as the paths of the assets being generated, into a file in a well-known location:

Run `webpack` and confirm the file is getting generated successfully:

Next, somewhere inside your server application, parse the metadata file:

...define a function to generate proper HTML to include the assets:

...and use it:

That's it!

Skip "symbol" regions when matching parentheses

Lisp symbols can contain parenthesis when surrounded by vertical bars (i.e. `|Symbol-Name|`), and in case of _unbalanced_ parenthesis matchparen.vim would fail to highlight the "right" pair:

After "symbol" is added to the list of regions to test against, matchparen.vim will highlight the _expected_ closing pair:

I know it's very unlikely for one to define a symbol with such a name, but should that ever happen, this fix will make matchparen.vim behave properly.

Anyways, I opened [PR#8079](https://github.com/vim/vim/pull/8079) for this...let's see what Bram and the others think about it.

Looking into a 3 months old PR that I opened to vlime to get it to properly handle char literals like `#\(` or `#\)`

First things first: _disable_ vim-lispindent, or otherwise you are going to start doubting yourself, because unable to reproduce the issue.  Open .vim/pack/iamFIREcracker/start/vim-lispindent/plugin/lispindent.vim, and replace the following lines:

with:

Restart vim, have vlime take over lisp files indentation, and you should be good to go (i.e. reproduce the issue the MR is trying to fix).

Now, let's have a look at one of the comments which were left on the PR:

These are the functions which make use of `searchpairpos()`:

- `vlime#ui#CurTopExprPos()`
- `vlime#ui#CurOperator()`
- `vlime#ui#SurroundingOperator()`
- `vlime#ui#ParseOuterOperators(3)`
- `vlime#ui#CurArgPos()`

Let's load the following into a buffer and see how each of the above behave:

Placing the cursor onto the `#\(` character literal, and running `echo vlime#ui#CurTopExprPos('begin')` correctly logs: `[4, 1]`; however, if we pass in `'end'` we get `[10, 17]` instead of the expected `[6, 17]`.  Similarly, if we place the cursor onto the `#\)` character literal and run `echo vlime#ui#CurTopExprPos('end')` we get: `[10, 17]`, but if we use `'begin'` we get `[4, 1]` instead of `[8, 1]`.  Switching to our `searchpairpos()` wrapper seems to be fixing the problem (see [6fe69f3](https://github.com/vlime/vlime/commit/6fe69f330999e392493a3d7164a3b93ca614bb58)).

Placing the cursor onto the `#\(` character literal, and running `echo vlime#ui#CurOperator()` returns an empty string, and interestingly enough adding `skip` to `searchpairpos()` does not seem to make much difference.  Why? Because the function calls `vlime#ui#CurExpr()` which returns `()` instead of the expected `(char= ch #\())`.  Why is `vlime#ui#CurExpr()` returning `()`? Because we are re-using the same logic of matchparen.vim, which intentionally does _not_ try to skip over certain syntax regions if the position the was in at the time the search operation was issued happened to be within one of those syntax regions already (i.e. it will highlight parentheses inside comments).

Question: is this the expected behavior, or should `vlime#ui#CurExpr()` return the actual surrounding expression instead?

In any case, since we have to deal with incomplete expressions anyway, I am proposing that we stop calling `vlime#ui#CurExpr()` here, and simply use the `searchpairpos()` wrapper instead (see [debdd92](https://github.com/vlime/vlime/commit/debdd924d8af2112f3d8a7afad0fe96a0e39f6f9)).

Off to `vlime#ui#SurroundingOperator()`; placing the cursor onto the closing parenthesis right after the `#\(` character literal and calling this function outputs an empty string instead of `char=`.  The same happens if we place the cursor at the closing parenthesis right after the `#\)` character literal of the second function definition.  Using our `searchpairpos()` wrapper here, seems to be fixing the problem (see [dac541a](https://github.com/vlime/vlime/commit/dac541a49414152353516e3c10d7f604479f6aea)).

The next one is `vlime#ui#ParseOuterOperators()`; placing the cursor onto the closing parenthesis right after the `#\(` character literal and calling `vlime#ui#ParseOuterOperators(3)` returns `[['', -1, [6, 15]], ['char=', 2, [6, 3]], ['', 1, [5, 45]]]` instead of the expected `[['char=', 3, [6, 3]], ['defun', 7, [4, 1]]]`.  Again, using our `searchpairpos()` wrapper fixes the problem (see [f8a8777](https://github.com/vlime/vlime/commit/f8a8777eafb3a0cd0a47eeec50dddea2d7278cd7)).

Lastly, for `vlime#ui#CurArgPos()`, let's use these function definitions instead:

Placing the cursor onto the `ch` symbol right after the `#\(` character literal and calling `vlime#ui#CurArgPos()` outputs `0` instead of the `2`.  Similarly, doing the same from the `ch` symbol right after the `#\)` character literal outputs `5` instead of `2`.  To fix this, not only we had to use our `searchpairpos()` wrapper, but also change the _parser_ to try to deal with character literals (see [5ea8f32](https://github.com/vlime/vlime/commit/5ea8f32fe74591c2cf42c09adf5629e440ce0027)).

[Syntax on a Post Card](https://richardeng.medium.com/syntax-on-a-post-card-cb6d85fabf88).

PS. Follows the transcription of that postcard:

PPS. Yes, lately I got curious about Smalltalk, mostly because its highly interactive development experience; having said that, I am not really sold on the idea of being forced into using an IDE to fully _experience_ the language, but who knows, maybe I am going to give it a try...

and:

These were taken from Discord, a while back.  Surely packages, and systems are one of the most confusing things new Common Lisp programmers need to get accustomed to.

Casually chatting on Discord (Lisp/#web) on the reasons why one would try to use React even for a 100% no-JavaScript site:

It kind of makes sense if you think about it:

- You use React because it will hopefully make it easier to maintain the different pages of the site, even if it's going to be 100% JavaScript free
- In the meanwhile, yourself/the team gets acquaintanced with the piece of technology that most likely you will end up using when adding some sprinkles of JavaScript to the client -- because it will happen...sooner or later you will want to add that to your "app"

Few pointers:

- [Server side rendering with React and NodeJs](https://aparnajoshi.netlify.app/server-side-rendering-with-react-and-nodejs)
- [How to Generate Static Websites with React](https://www.cloudsavvyit.com/5418/how-to-generate-static-websites-with-react/)

About playing with remote Node.js REPLs; I [recently](https://matteolandi.net/plan.html#day-2021-03-24) said:

Well, it turns out _there_ is a better way to make sure socket messages are communicated within a given asynchronous context; all you need is a combination of [`Stream.Transform`](https://nodejs.org/api/stream.html#stream_class_stream_transform) and [`Readable.prototype.pipe`](https://nodejs.org/api/stream.html#stream_readable_pipe_destination_options).  From [GitHub](https://github.com/nodejs/node/issues/37866#issuecomment-805578727):

>

Then the following snippets follow; the custom `Transform` class:

and how to use it to "properly" setup the remote REPL:

Amazing, I can now carry on with my REPL experiments.

Alright, I think I figured a way to make [this](https://matteolandi.net/plan.html#day-2021-03-23) work by using a combination of `AsyncResoruce.bind` and `Function.prototype.bind`.  First I use `AsyncResource.bind` to force the `socket.on` callback to run inside the "right" asynchronous context, and then I bind the first argument of that _hooked_ callback (i.e. `thisArg`); lastly, I call the _original_ `socket.on` implementation, passing the _hooked_ callback into it.

And with this, `AsyncLocalStorage` is not not losing its context anymore.

I am sure there might be better and more idiomatic ways of dealing with this, but at least it unblocks me for now.

I tried to update to the latest version of Node, but luck, it's still _broken_:

For the first snippet, the REPL one, from the remote client's terminal:

For the second snippet, the one without the REPL, the one with `socket.on(...)` only:

I read through the whole [#33723](https://github.com/nodejs/node/issues/33723) thread, and realized that if I create an instance of `AsyncResource` when the connection is established, and run the `socket.on` handler within the context of that resource, then the asynchronous state does not get lost any longer:

on the server's stdout:

I quickly hacked the first snippet again, the REPL one, and implemented a man-in-the-middle solution where the socket's input is pumped into the REPL's stdin from inside an `AsyncResource` context, and it's kinda working (i.e. the asynchronous context is _not_ lost, but of course all the evaluation results are dumped on the server's terminal:

If I run this I get:

Clearly the _wiring_ left something to be desired, but at least the context was not lost.

I guess I can work-around that ([eventemitter-asyncresource](https://www.npmjs.com/package/eventemitter-asyncresource) maybe?!), but I wonder if it wasn't somehow expected for the created REPL to be bound to the async context of the request.

`AsyncLocalStorage` losing state when used with `net.Server` and `repl.REPLServer`

I am poking around a tiny wrapper around `repl` to make it possible for someone interact with a running Node.js instance, remotely,  but when I tried to use `AsyncLocalStorage` to attach some state to the active session, such state gets gets lost as soon as the `REPLServer` takes over.

Save the following into a file:

and run it:

Now from a different terminal, connect to port `8081` to get your remote REPL:

Now, accessing `ctx` (well, its content) from the REPL should return the ID of the REPL itself (i.e. an increasing number), but `undefined` is returned instead:

I suspect it might have something to do with the underlying socket or `EventEmitter`, because when I try to access the content of `ctx` from within a `socket.on('data'...)` block, I still get `undefined`.

I filed a bug for this, [node/#37866](https://github.com/nodejs/node/issues/37866), so let's wait to hear back from the core developers.

Kent Beck, on [Twitter](https://twitter.com/KentBeck/status/250733358307500032)

Dynamic variables in Node.js (part 2)

The Node.js implementation of dynamic variables that I presented few weeks ago was a bit...lacking, as it did not support for an _external_ actor to interact with (and change) the dynamic environment of a _running_ application.

Imagine if your application exposed a REPL you could [remotely connect to](https://nodejs.org/en/docs/guides/debugging-getting-started/#enabling-remote-debugging-scenarios); now, if you had all the application settings loaded into the dynamic environment, wouldn't it be amazing if you could change those while the application is running and immediately see the effects of such change?  So do all that, connect to the REPL, run `var { env } = require('dynamic_variables.js')`, only to discover that the actual environment is empty...

That's a bit of a bummer, but it also kind of makes sense if you think about it: all the dynamic bindings are done asynchronously, and when you connect to the REPL you are starting off a completely unrelated execution context, and because of that: a) the dynamic environment turns out to be empty, b) there is no way for you to change it and give the application access to the newly created bindings.

To _fix_ this, we will have to change the internal representation of a dynamic environment, and define it in terms of a stack of _frames_, each containing a set of bindings: a _global_ frame, containing all the _top-level_ bindings (i.e. the ones happening outside of any asynchronous context, when the application boots up); and then a list of _dynamic_ frames to keep track of all the asynchronous bindings.

If we want an _external_ actor to interact with the running application and change its dynamic environment, we will also need a way of _mutating_ existing bindings, living in one of the existing frames, without having to create a new one.  In particular, when run by the external actor this new bind operation is going to affect the global frame; but when run inside an asynchronous context it's going to affect the frames in which those bindings were most recently defined / re-defined.  Hopefully the following Common Lisp snippet will help you understand what I am talking about:

Alright then, let's get to it.  We said the new `DynamicEnvironment` was going to need to keep track of _global_ bindings, as well as _dynamic_ ones; for the first we are going to be using an instance of `Bindings` (i.e. a wrapper around `Map`), while for dynamic ones we will be using an array of `Bindings` all wrapped up inside an instance of `AsyncLocalStorage`:

Note 1: we are not passing `[]` to `AsyncLocalStorage constructor` because reading it back from an _external_ process will result in an _empty_ context, and if we have to deal with `undefined` values anyway then why bother initializing it in the first place?!
Note 2: the `Bindings` type used here is a little bit different from the one I showed [last time](https://matteolandi.net/plan.html#day-2021-02-28); it has a new `Bindings.prototype.has` method to check if a binding for a given variable exists, its `Bindings.prototype.set` method is now a _destructive_ one (i.e. it mutates the current object), it implements the [iteration protocol](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Iteration_protocols) (it's going to come in handy later on):

Looking up a binding inside this new environment now translates to finding first the frame, dynamic or global, that _last_ defined a binding for that variable, and then pull the binding value out of it.

On the topic of setting a new binding: we previously said we wanted to enable users to _create_ new bindings (i.e. create a new frame), as well as _update_ existing ones, as that would enable an external actor to interact with a running application.  To do that, instead of creating two separate methods, we will be having `DynamicEnvironment.prototype.set` check the arguments it receives and figure out what to do based on its length: if it receives an even number of arguments, it means the user specified new bindings only with no body function, in which case the method will proceed and update existing frames; if on the other hand the method is provided with a body function (i.e. odd number of arguments), then a new frame with the specified bindings is going to be added to the stack of frames, and the body function will be executed inside that new dynamic context:

Lastly I figured it would be nice to make it possible to iterate over all the bindings of a dynamic environment, so the following implements that:

Alright, let's test this out and see if it works.  We are going to create a timer, and inside of it we are going to be logging the content of the dynamic environment:

(You should now start seeing a bunch of `false` messages getting logged in the REPL, every 2 seconds)

Next we are going to listen for incoming connections on port `5001`, and every time we receive one, set up a _remote_ REPL to let the external actor play with the running environment:

Let's poke around and see what we can do with it:

It looks like we can get hold of the dynamic environment (well, its global frame at least); let's try and change it:

If all worked as expected, you should now be seeing a series of `true` messages getting logged in the REPL; _that_ means were successfully able to poke with one application's dynamic environment, from the outside.

"You could have easily done that with global variables" one could argue, and they would be right, we could have.  Let's mix in some more dynamic bindings, to show what the system is capable of.

First we reset the environment and add an additional binding, then we change our timer to create some dynamic bindings and finally print the whole dynamic environment:

The messages logged in the REPL should now look like the following:

Let's go back to the remote REPL again, and change the value of the `debug` binding again:

Wait a couple of seconds, and the messages logged on the REPL should now look like this:

As we can see the dynamic environment from within the `setTimeout` handler properly reflects the changes done from the _remote_ REPL, as well as the ones triggered by the dynamic bind operation.

And that's it!  I have pushed all the above on [GitHub](https://github.com/iamFIREcracker/dynamic_variables.js), and in there I also added an [example](https://github.com/iamFIREcracker/dynamic_variables.js/tree/master/examples/express) showing how dynamic variables can be be used within an Express.js application.

Till next time.

From [Finding the Missing Bullet Holes](https://onebiteblog.com/finding-the-missing-bullet-holes/)

Am I the only one having a hard time understanding the implementation of Data-Directed Programming, presented in SICP?

A little bit of background first; we are shown how to _tag_ data ([2.4.2 Tagged data](https://mitpress.mit.edu/sites/default/files/sicp/full-text/book/book-Z-H-17.html#%_sec_2.4.2)):

...how to implement type predicates:

...how to implement _packages_:

...and how to implement _generic_ selectors:

Clearly it's not OK for REAL-PART, or IMAG-PART, or any other _generic_ selector, to require change every time a new implementation is added to the system, and this is where "Data-directed programming" is going to come to the rescue.

The idea ([2.4.3 Data-Directed Programming and Additivity](https://mitpress.mit.edu/sites/default/files/sicp/full-text/book/book-Z-H-17.html#%_sec_2.4.3)) is to construct a table mapping operations (e.g. REAL-PART, IMAG-PART) and types (e.g. POLAR, RECTANGULAR) to the actual function in charge of fulfilling the user need, and of course to provide a way to pluck the specific implementation out of the table.  In particular:

- `(put <op> <type> <item>)` will install `<item>` in the table, indexed by `<op>` and `<type>`
- `(get <op> <type>)` will look up the `<op>,<type>` entry in the table

Note: we are not given the actual implementations of PUT and GET.

With this in mind, we can then re-define the rectangular package as follows:

Here is where things get a bit confusing: why, we are _registering_ REAL-PART for the `(rectangular)` type, and not simply `'rectangular` like we are doing for MAKE-FROM-REAL-IMAG?

The only explanation I could think of is that we are giving the `<type>` argument of the PUT call different meanings:

- For REAL-PART, `<type>` represents the list of the types of the arguments expected by the registered procedure (i.e. one argument, of type RECTANGULAR)
- For MAKE-FROM-REAL-IMAG instead, `<type>` represents the type of the _returned_ instance

And why would we do that?  Because otherwise it would not be possible to dispatch to the "Right" implementation in case of generic functions with the same argument types (both the implementation of MAKE-FROM-REAL-IMAG inside the rectangular and polar packages expects 2 arguments of type NUMBER).

Anyways, a similar package for the polar representation is presented, and then finally we are shown the implementation of APPLY-GENERIC, the procedure responsible for invoking the "Right" procedure based on the _types_ of the arguments of the dispatched action:

Here more doubts come to my mind: how can we use this with the MAKE-FROM-REAL-IMAG?

Clearly we cannot simply run `(apply-generic 'make-from-real-imag 4 2)`, as that would fail when trying to apply TYPE-TAG to `(4 2)`.  I thought, maybe we pass `(attach-tag 'rectangular (list 4 2))` to APPLY-GENERIC, but then `(map contents args)` would evaluate to `((4 2))` and that is incompatible with the registered procedure, which expects two numbers and not a list of 2 numbers, right?

So where do we go from here?  There _has_ to be a way, but I just cannot find it.

Posted this on [/r/sicp](https://www.reddit.com/r/sicp/comments/ly7wj3/datadirected_programming_and_how_to_invoke/), let's see if anyone can help me out.

Dynamic variables in Node.js

For those of you unfamiliar with it, Common Lisp has this concept of "dynamic variables", which are nothing more than _global_ variables with _dynamic_ scope; but what does it mean for a variable to have dynamic scope? That you can bind a new a value to it, and all the _subsequent_ accesses to that variable (within the scope of the binding operation), will return _that_ new value instead of the _previous_ one.  Let's take a look at an example, as I hope it will make things a little bit easier to understand (the asterisks around a variable name indeed mark the variable as dynamic / special):

Step by step explanation:

- `*x*` was initially bound to `5`, so when we access it we get `5` back -- all good
- We call FOO, which all it does is returning the value of `*x*`, and without much surprise we get `5` back -- so all good
- We call BAR, which binds `*x*` to `42` before calling FOO and returning its return value, and interestingly enough we now get back `42` instead of `5` -- there it is the _dynamic_ scope I was talking about earlier
- Lastly, we access `*x*` and we get `5` back -- we are outside BAR's new binding scope, so the value of `*x*` has been restored to its previous value

Let's go back the definition that I gave earlier: _global_ variables, with _dynamic_ scope.  I know that the first rule of global variables is: "thou shalt not use global variables", but it's just that _sometimes_ they appear to be right tool for the job, especially in the context of Web applications; think about the following use cases:

- getting a hold of the currently logged in user
- automatically adding the content of the `X-Request-Id` header to each log trace
- querying the _right_ database, based on the logged in user's tenant

How would you implement these?  Either you shove all this information up into a context object, and pass it around, _everywhere_; or maybe you forget about all the bad things you read about global variables, and consciously and carefully agree to use them where it really matters, where it really makes a difference.

Anyways, enough talking about global variables, I do not want this to be an essay about its pros or cons (I am sure the Internet is full of material and opinions about it); instead, let's go back to our original goal: trying to implement dynamic variables in Node.js.

It all begins with the definition of a type representing a bag of bindings (we are going to wrap the standard `Map` type for this):

(Don't worry about that _ugly_ syntax for now, we will deal with it later)

Getting a binding (i.e. getting the value bound to a variable), should be as easy as calling `Map.prototype.get` (plus some additional logic to validate user input):

First we check that the name of the variable is indeed _valid_, then we confirm that a binding for that variable actually exists, and finally we return the value bound to that variable.  Let's play with it an confirm it's all working fine:

Lastly, to set new bindings, we will go about and create a new `Binding` object and initialize it with the existing bindings and the newly defined ones..._merged_ together:

Again, let's can play with this to confirm that it's all working as expected:

All good, great!  Before we dive into the details of the implementation of dynamic variables, let's first implement a couple of functions which will come in handy down the line.  The first one is to simplify the _syntax_ for creating new bindings; we don't want users to specify new bindings via nested lists (i.e. `[['a', 1], ['b', 2]]`); instead, we would like them to use a _flattened_ list instead (i.e. `['a', 1, 'b', 2]`):

Nothing crazy about this: we first confirm that the number of bindings is indeed even, and then wrap every pair of adjacent elements into a nested list.  Let's give it a go:

Perfect!  The second utility function might look a bit cryptic at first, simply because I am yet to show you what is the problem that it tries to solve, but hopefully soon it will all make more sense.  We want to feed it with a list of elements representing a flattened list of bindings followed by a callback function, and we expect it to return a list whose first element is a list of key-value pairs created from the list of flattened bindings, and the second is the given callback function:

Let's test it out:

Alright, it's all working as expected, and with all of this defined and taken care for, it's time we took a look at a possible implementation for a _dynamic environment_, i.e. environment getting a hold of a bunch of dynamic variables.

The biggest challenge in implementing dynamic variables in Node.js is figuring out a way to persist _state_ across changes of asynchronous context: you set `*x*` to a `5`, invoke `setTimeout`, and when the callback is invoked you expect `*x*` to still be bound to `5`.  Similarly, if two asynchronous operations happen to re-bind the same dynamic variable, you don't any of them to step on each others toes.

Luckily for us, the Node.js core team has been working on this _problem_ for quite some time now, and you can see the result of their effort in the [`async_hooks`](https://nodejs.org/api/async_hooks.html) module.  I am not going to bore you with its implementation details (mostly because I am not familiar with it myself), but for what we are trying to achieve here, all we need to know is that:

- Each piece of running code (_user_ code), can have an ID attached, identifying its asynchronous execution context
- Each piece of running code (_user_ code), can have another ID attached, identifying the asynchronous context that _triggered_, directly or indirectly, the current one (i.e. if you create three nested promises, each callback, when executed, will probably have a different `asyncId` value but same `triggerAsyncId` one)
- There is a low-level API, [`createHooks`](https://nodejs.org/api/async_hooks.html#async_hooks_async_hooks_createhook_callbacks), that can be used to get notified when an asynchronous execution context is created or destroyed; with it, one could think of attaching some _payload_ to the current execution context, and then expose another API for user code to access it
- There is a high-level API, [`AsyncLocalStorage`](https://nodejs.org/api/async_hooks.html#async_hooks_class_asynclocalstorage), that shields the user from all the above complexity, and offers a simple way of running user code with a given piece of _payload_ attached to the current execution context

It goes without saying it that `AsyncLocalStorage` is what we will use to implement our dynamic environment:

- Getting a binding translates to getting a hold of the current execution context's payload (i.e. the bindings), and returning whichever value is currently bound to the given variable name
- Setting a binding translates to creating a new set of bindings, attaching it to the current execution context, and running user code within it -- old bindings will be automatically restored after user code (synchronous or asynchronous) has finished running

Alright, let's get our hands dirty.  Let's start by creating a new type for the dynamic environment:

Here, all we do, is creating the asynchronous context object (i.e. an instance of `AsyncLocalStorage`), and then initialize it with some user defined bindings (e.g. `'a', 1, 'b', 2`).  Let's give it a go to see what happens when we call the constructor (note: `ctx.getStore()` is how you access the _payload_ of the current asynchronous context):

Let's now define a method to get the value of a specific binding (note how `Bindings`, our previously defined type, is doing all the heavy lifting here):

The last piece of the puzzle, is a mean of setting a new binding (or bindings), and run some user code within the scope of these new bindings; thanks to `Bindings`, `AsyncLocalStorage`, and the cryptic `parseDynamicEnvironmentSetArguments` I showed you before, this could not have been any easier to implement:

First we parse function arguments into key-value pairs and the callback inside of which the new bindings will be active; then we create a new `Bindings` object merging new bindings with any existing ones; lastly we tell `AsyncLocalStorage` to _do its magic_ (i.e. attach new bindings to the execution context, and run user code).  Let's try this out, and see if it works or not:

It seems like it _is_ indeed working; but what if we added some asynchronous operations within the scope of the `set` call?

Still working, great!  What about multiple asynchronous operations at the same time?

It works, and by the look of it it appears we were indeed able to implement "dynamic variables" in Node.js.

I added all the above into a new repository, [`dynamic_variables.js`](https://github.com/iamFIREcracker/dynamic_variables.js), so feel free to play with it in your REPLs and do let me know if anything breaks for you.

Also, it's worth remembering that `async_hooks` is still considered _experimental_, so its API might suddenly change with a new release of Node.js; well, that and the fact that the current implementation might still contain some nasty bugs that might cause your dynamic bindings to get lost across switches of execution context.  This might not be a big deal if you were just to messing around with this, or if you were just planning to use this to enhance your logging capabilities; but if instead, you were planning anything more _serious_ than that, like selecting the "right" database connection based on the logged-in user's tenant, then I would strongly recommend that you tested as many execution paths as possible and confirmed that no binding got lost in the process.  You know, it works...until it doesn't!

PS. For educational purposes, here I am going to show you a different implementation of a dynamic environment, one that does _not_ use `AsyncLocalStorage` to keep track of re-binds (it does that with a stack of _active_ bindings) and because of that, one that most surely is going to fail the expectations in case of multiple nested, asynchronous, re-binds:

If your Mac refuses to go to sleep, use `pmset -g assertions` to see who's preventing this from happening...and kill it -- the other day it was one of my browser tabs, and only God knows what it was doing it the background...welcome to 2021!

Relevant read: [Sleepless Mac](https://stuff-things.net/2017/05/10/sleepless-mac/)

The "earnmuff notation" (extracted from the Common Lisp Condition System)

The "earnmuff notation" in CL is the conventional notation for dynamic variables.

Here is a very poor an concise _refresher_ (I should have used _reminder_ there) about how dynamic variables work in CL:

On reporting custom conditions (extracted from The Common Lisp Condition System)

Condition objects are printed in their unreadable form if the dynamic variable `*print-escape*` is bound to T,  However, when that same variable is bound to NIL, printing a restart object causes its _report function_ to be invoked.  That report function accepts a pair of arguments: the condition object itself and the reporting stream that the the report should be written to.  This means that the report function is capable of querying the condition object for all the infromation that is needed for generating a proper report; it is goodf style for condition reporting functions to be self-contained, which means not to depend on any Lisp data other than the condition object itself.

On CERROR, and its signature (extracted from The Common Lisp Condition System)

An interesting feature of CERROR is that the optional arguments passed to the function are used _both_ for constructing the condition object _and_ as format arguments for the passed format string.  Let us analyze the following form:

 Executing this form will cause the system to signal a SIMPLE-ERROR; we expect the report of that condition object to be `A simple error signaled with 42.`. In addition, we expect a new restart to be bound around the error site; the restart will have a longer report form, reading `Continue after signaling a SIMPLE-ERROR with arguments: ` and then listing all the opotional arguments that CERROR was called with.

On the condition-restart association (extracted from The Common Lisp Condition System)

Let's take a look at the following code snippet:

Let us differentiate these two lists of restarts via SET-DIFFERENCE to find restarts which appear in the first list but don't in the other:

We can see that calling COMPUTE-RESTARTS _without_ passing it the UNDEFINED-FUNCTION condition has caused one more restart to appear -- the missing STORE-VALUE restart, with a report `Suppy a new value for *X*.`, which was bound by the STORE-VALUE form which we originally evaluated.  From this observation, we may induce that there must be some sort of relationship between condition objects and restart objects that is checked by COMPUTE-RESTARTS and FIND-RESTART, among other functions.  This relationship in CL is named _condition-restart association_.

On programmatically calling MACROEXPAND (extracted from The Common Lisp Condition System)

We can see that the macro definition has been expanded to include a special _environment_ object inside its lambda list; this object is not directly passed to it by the programmer, but is usually provided by the Lisp implementation as part of calling its macroexpander.  While we will not describe environment objects in detail, we will note their traits which are most relevant to us for the matter at hand.  This environment argument is available only in macros; it holds, among other things, information about local macro definitions -- information which is important for passing into the MACROEXPAND calls of our new functions.  Since these calls must perform macroexpansion of their own, it is important that they receive this environment argument to be able to expand macros correctly.  That is why RESTART-CASE passed the argument to EXPAND-RESTART-CASE, which -- in turn -- passes it into our yet-undefined functions RESTART-CASE-SIGNALING-FORM-P and RESTART-CASE-EXPAND-SIGNALING-FORM.

Refresher on generalized booleans (extracted from the Common Lisp Condition System)

In the second test, the function returned a non-NIL value, which in CL is "as good as" returning true.  CL has generalized booleans, which means that anything that is not NIL counts as a true value, evewn though the symbol T is designated to be the "canonical" representation of truth -- the standard type BOOLEAN, after all, is defined as `(member nil t)`.

From Hacker News: [Is Y Combinator worth it?](https://news.ycombinator.com/item?id=24616649)

Someone replied:

Is the second paragraph true tough?

Exactly, freedom from investors, chained to your customers.  The conversation goes on:

And eventually someone steps in and explain how things work:

The above finds me in absolute agreement -- and I could not have explained it in simpler terms.

[Reddit vs Wallstreet - GameStop, The Movie](https://www.youtube.com/watch?v=YFQ-v1jCpF0)

I wanted to fix some of the compilation warnings in my AdventOfCode-solutions-in-Common-Lisp [project](https://iamFIREcracker.github.com/adventofcode), and this one in particular caught my attention.

Given this function:

Try and evaluate in the REPL (SBCL/2.0.11 in my case) and you should get the following style warnings back:

I can avoid the implicit call to DESTRUCTURING-BIND (LOOP-DESTRUCTURING-BIND to be precise, as that is what the `with (rows cols) = ...` expression gets expanded into) by replacing ARRAY-DIMENSIONS with two calls to ARRAY-DIMENSION:

Now _that_ seems to have solved the problem (i.e. no style warning anymore).

What if I wrapped the original LOOP expression into a DESTRUCTURING-BIND form in which I initialize `rows` and `cols`?

This version too, does **not** cause the compiler to throw any style warnings.  What exactly is going on?

Let's try and find the minimal snippet to reproduce it:

When I send the above to the REPL I get:

Perfect.  Let's try and expand that LOOP expression, _recursively_, and see if anything stands out:

I am afraid the compiler is right, isn't it?

- LOOP's destructuring bind would not signal an error if the list you are destructuring bind against does not have enough elements; it would bind all the _extra_ variables to NIL
- This means that both `rows` and `cols` can be NIL
- `rows`, however, is used after the keyword `:below`, and because of that it is expected to be a NUMBER
- But NIL is not a valid NUMBER, hence the warning

Technically the compiler is right, but what a pain...

Anyways, I reported this as a bug to sbcl-bugs@lists.sourceforge.net, let's see if they think it's a bug or not.

SpaceX commenter, at the end of the [Starship SN9 flight test](https://mobile.twitter.com/SpaceX/status/1356699321840721920)

Here is a _legit_ use case for PROG2:

It turns out there is a library, `:cl-advice`, that exploits PROG2 in an almost identical way (check this out on [GitHub](https://github.com/szos/cl-advice/blob/3d8653da763ab67b8abda1dba8c7783806a10e64/cl-advice.lisp#L137-L142)):

When perceived in this way, PROG2 is a non-object-oriented `:before`/`:after`

Advent of Code: [2015/25](https://adventofcode.com/2015/day/25)

The task for today, i.e. Christmas, is to boot up the weather machine -- no idea what that is -- and all we have to do is to read a code from the instruction manual and insert it on the console.  Except, we don't know where the manual is, so need to generate the sequence of codes first.

We are given the rules of how this sequence has to be constructed:

First, let's begin by parsing the input to know the position in this _diagonal_ sequence where we will find the code to boot up the weather machine.

Next, let's implement a generator of all the positions of this _diagonal_ sequence:

- Return `(1 1)` the first time
- Then move `1` up, and `1` right
- If the current row is `0`, we need to wrap around, otherwise there we have the next position of the sequence
- Repeat

Next, let's implement a generator of all the values of this _diagonal_ sequence (i.e. all the possible codes):

- Start with `20151125`
- Then multiply it by `252533` and take the remainder from dividing that by `33554393`
- Repeat

With these two generators, finding the solution to part 1 should be pretty straightforward:

- Generate the next position
- Generate the next value
- If the position we are at, is what we are looking for, then the current value is our answer

No part 2 for Dec 25, so here goes the final plumbing:

And that's it:

Advent of Code: [2015/23](https://adventofcode.com/2015/day/23)

The problem description goes on by giving you details about the six instructions that this computer supports (i.e. `hlf`, `tpl`, `inc`, `jmp`, `jie`, and `jio`), the number of registers it has (two, `a` and `b`), how programs are run, and when should they halt (when they jumps to position _outside_ the program).

Given the input program, what's the value of the `b` register after the program has finished running?  Looks like we are going to write a little emulator here...

First off, we are going to need an instruction pointer, two registers, `a` and `b`, and some utility functions to operate on these registers:

The next step is to _parse_ our program:

- Split each instruction into its _operator_ and its _operands_
- Based on the value of the _operator_, return a function implementing the required logic, and taking care of updating the instruction pointer accordingly

All is left to do, is running the program until it _exits_, and as requested, return the value of register `b`:

For part 2, we are asked to run the program again, this time with register `a` initialized to `1` instead of `0`:

Final plumbing:

And that's it:

Advent of Code: [2015/24](https://adventofcode.com/2015/day/24)

We are given a list of the weights of each package, and we are asked to split them into three groups so that each group weights the same; well, not just that, of course we also want to find the combination that:

- Has the fewest **number** of packages in the first group
- (and in case of ties, the one that) Has the smallest "quantum entanglement" (i.e. the product of the weights of the packages in the group)

The input is a set of lines, each representing the weight of a package; a simple call to PARSE-INTEGERS should do just fine.

Now back to the actual problem solution.  Since we are asked to find the configuration that minimizes the number packages in the first group, I figured I could simply focus on that group alone, and find our solution as follows:

- Try and look for all the packages whose weight is equal to the _target_ value (i.e. total weight divided by `3`)
- If none is found, try and look for all pairs of packages whose total weight is equal to the target value
- If none is found, try and look for all triplets of packages whose total weight is equal to the target value

And so on, and so forth, until one or more solutions are found; at which point, I would calculate the "quantum entanglement" of these _winning_ configurations, and return the minimum value.


First let's take care of the easy parts: finding the target weight, and calculating the quantum entanglement of a configuration of packages:

Now we have to find the configuration for the perfect balance; we know we will iteratively try to find configurations, with increasing number of packages.  But how to find a configuration of `n` packages, whose total weight add up to a specific value?  With a bit of recursion and backtracking:

- If we can select only one package, see if one with the target value exists in the pool of remaining packages, and if it does, then we found ourselves a partial solution
- Otherwise we have to options: add the first available package to the current solution and see if with the remaining packages it's possible to find a solution that adds up to the target value minus the weight of the selected package; or we skip the first available package and try with the next one

This (and some other details that I did not bother mention) translates into the following function:

With this, all we have to do for part 1 is calling FIND-PERFECT-BALANCE with the input weights, and the number of groups we want to divide our packages into:

For part 2, we are asked to repeat the exercise with `4` groups instead of `3` -- turns out we forgot about the trunk of the sleigh:

Final plumbing:

And that's it:

Note: I made a big assumption here, which is once I find a possible solution for the first group I take it for granted that the remaining packages can be split into 2 groups (3 for part 2), each adding up to the target value.  This assumption got me my 2 stars today, but I guess I got lucky ;-)

Advent of Code: [2015/22](https://adventofcode.com/2015/day/22)

Another day, another RPG to play (err, implement); this time however, the game logic is a bit more complicated than the one we implemented for [2015/21](https://matteolandi.net/plan.html#day-2021-01-13), with lots of tiny details that if you get wrong, no way you are going to be able to get your 2 stars for the day.

In this game the player does not have any equipments, but only spells; spells cost mana; spells can protect you, deal damage to the boss, or both; spells can have an _effect_ that lasts more than one turn.

Let's have a look at the list of spells available:

I decided to parse this catalog into a LIST of LISTs; LIST of _structured_ types actually, but let's not get lost in the details:

Let's have a look at the game, and focus on the player first (i.e. you).  The `player` has some _life_ points, _mana_, and certain _effects_:

By looking at the list of _active_ effects it should be quite easy to calculate one's total armor, mana, and damage:

One's total mana is equal to the mana the player has, plus all the mana given by any active effect:

Similarly, one's total _dealable_ damage is equal to the total damage of any active effect, plus the damage of the spell they might be about to cast:

Rest is generating a new `player` object, as a result of playing a turn (i.e. casting a spell, or defending an attack):

- Update life points based on the healing power of the spell, or the boss attack
- Update mana taking into account _recharging_ effects, plus the cost of the spell to cast
- Update the list of active effects:

Now...let's move on to the boss logic: we will first define a structured type for the boss, and some parsing functions to extract our boss specs from our input:

The amount of damage the boss can deal is equal to their damage points minus the player's armor; however, since we play by the boss' rules, the boss is always going to deal at least `1` damage point, irrespective of the player's armor:

Updating the boss state after a turn is pretty straightforward:

Alright, now it's time to actually implement the game:

- A _turn_ consists in the player casting a spell **and** the boss attacking us
- There might be multiple _castable_ spells at a given time; we should pick one, cast it, and see where this takes us
- If after the boss' move, the player turns out to be dead, then we should backtrack and try with a different spell
- The list of _castable_ spells is obtained by looking at the player's mana, and the already active effect
- Note: you can cast a spell whose effect is already active, if and only if this is the last turn the effect is active

Lastly, the recursive function responsible for playing the game, and backtrack when it reaches a dead end:

Easy uh?! Anyway, for part 2 we are asked to play a slightly different version of the game, where the player loses 1 life point at the beginning of his turn:

- LIFE-IS-HARD takes care of inflicting the damage to player
- PLAY-HARD stops the game the moment the player has no more life points (note: we need this to happen before any effect takes place)
- PART2 is equal to PART1, except that it calls PLAY-HARD instead of PLAY

Final plumbing:

And that's it:

Advent of Code: [2015/21](https://adventofcode.com/2015/day/21)

Today, we treat ourselves with a simple RPG game to play with:

- It's you versus the "boss"
- The boss starts with 100 hit points and with some pre-defined attack power and armor (all this comes from the input)
- You start with 100 hit points, bare-handed, and without a armor
- There is a shop selling weapons, armors, and rings, and each has a cost (this is not in the input, but part of the description, so I assume this to the same for everybody)
- To fight, you need a weapon, and you can optionally wear an armor, and one or two rings
- The game is played in turns -- you start first -- and the amount of damage dealt is equal to your attack power minus the defendant's armor

What's the minimum you have to spend, to beat the boss?

Let's start with the shop: I am going to use 3 different parameters (one for the weapons, one for the armors, and one for the rings), and inside I will store items as LISTS having the name of the item as first argument, its cost as second, its damage as third, and armor as fourth:

Then we will parse our boss specs:

I am going to join the lines back into a single string (DEFINE-SOLUTION would already parse the input file into a list of strings, so I need to _undo_ that first), then extract all all the numeric values from it:

Now, the solution I have in mind for "finding the minimum you have to spend to beat the boss" is pretty simple:

- generate all the possible combinations of items you can buy; for each...
- equip your player with those items, and play against the boss
- if you win, keep track of the amount you spent, and minimize it

Let's begin by generating all the possible combinations of items you can buy:

- you need at least one weapon -- or otherwise you are bound to lose, always
- you may or may not wear an armor -- can't have more though
- you may or may not wear one, or two rings -- you can have no rings, one ring, or two

If we consider _optionality_ as an item with no cost, and no damage nor armor, then the above nicely translates to the following function:

Now, equipping our player with an items combination should be as simple as appending the overall items damage and armor to the user hit points (i.e. `(list 100 damage armor)`).

What about playing the game and see if the player won?

- Calculate how many turns it will take the player to defeat the boss (note: damage / armor stats don't change throughout the game)
- Calculate how many turns it will take the boss to the defeat us
- We win the number of turns it take us to the defeat the boss, is smaller than or equal to the turns it takes to the boss (note: we start first, hence the _or equal_ before)

All there is left to do at this point is iterate all the combinations, play the game, see if we win, and minimize the cost of the game:

For part 2, the shopkeeper can trick you into buying anything they want, and we are asked to find the maximum we can spend and still be defeated by the boss!

That should be pretty easy:

- generate all the possible combinations of items you can buy; for each...
- equip your player with those items, and play against the boss
- if you lose, keep track of the amount you spent, and maximize it

Final plumbing:

And that's it:

Elon Musk, Starship Update, September 2019 - https://www.youtube.com/watch?v=sOpMrVnjYeY

Advent of Code: [2015/20](https://adventofcode.com/2015/day/20)

Today it's about the elves delivering presents by hand, door to door, and us trying to figure out how many presents each house is going to get.  We have an infinite number of houses, numbered: `1`, `2`, `3`, `4`, `5`, and so on; then we have our elves, each with an assigned number, wandering around and delivering presents as described below:

Knowing that each elf will deliver at every house they visit presents equal to **10 times** his or her number, what's the first house which is going to receive at least `36000000` presents?

Input parsing was a no-brainer: single line, one integer:

Now, to solve this, I thought about a very naive brute-force:

- For each house, starting from `1`
- Find all the elves which are going to visit it (i.e. find all the _divisors_ of the house number)
- Sum it, and break out of the loop as soon as the sum, times `10`, is bigger than or equal to the input number

Well, calculating all the divisors for all the house numbers turned out to be a very inefficient solution -- simple, but very inefficient:

Interestingly, _simulating_ this, actually made for an even simpler and definitely more efficient solution:

- For each elf
- For each house the elf is going to visit
- Increase the number of presents it will receive by the elf number times `10`
- At the end, find the first house that got _that_ many presents

With this:

For part 2, we are asked to answer the same question, except that this time each elf will visit a maximum of `50` houses.  Thanks to CL powerful LOOP macro, all we have to do is adding a `repeat 50` to our inner loop:

Final plumbing:

And that's it:

Advent of Code: [2015/19](https://adventofcode.com/2015/day/19)

Rudolph (the Red-Nosed reindeer) is sick, and Santa needs your help to cure him; what exactly are you supposed to do? Come up with a medicine.  We are given a molecule (i.e. a string of chars), and a bunch of _replacement_ rules (e.g. `H => OH`); our task for part 1 is to count all the _distinct_ molecules you can obtain by applying any of your _replacement_ rules to the given molecule.

As usual, let's begin by parsing our input:

- The replacement rules we will parse them into an ALIST
- The molecule, well, that would be a STRING on its own

As per the actual solution to the problem, the following approach should do just fine:

- For each replacement rule `(from . to)`
- For each match of `from` inside our input molecule, replace it with `to` and accumulate the result
- Finally remove all the duplicates, and count the number of distinct molecules you are left with

Things get a bit more complicated for part 2:

I tried "the" very naive approach first, but it did not take me long to realize that replacement rules were recursive and that a basic _unbound_ search would have taken **forever** to find all the possible solutions.

My next try was: start from the medicine molecule, then recursively apply rules, _backward_ (e.g. given `(from . to)` replace all the occurrences of `to` with `from`), until you get to `e`.  This too was taking forever, even get to the _first_ solution...

I tried to sort replacement rules and process first the ones that were reducing our molecule the most, but that too did not seem to help much.

Then I thought: what if I processed first, the rules with the least number of matches? My idea was that this could help and minimize the branching factor, to a point where I could actually find a solution -- and if I have a solution, then I can find others by pruning the search space.

Apparently this heuristic seemed to work: I was indeed able to generate few solutions to the problem.  However, generating them **all** would still take forever.

Kind of hopeless, I let the program go for a while, logging each solution encountered so far, and interestingly enough it started logging the same number over and over again -- and guess what, that happened to be the right solution to the problem.

What's going on, exactly? I believe that my input (as well as others') is generated in such a way that all the possible solutions are indeed the same one (i.e. the _same_ in terms of number of steps to get from `e` to the medicine molecule).

Anyway, the solution I am presenting here assumes that all the solutions are equal, and will stop after the first one -- I know, it's not _generic_ in the sense that technically it does not solve the described problem, but it works well with few other users input ([1](https://topaz.github.io/paste/#XQAAAQCzAwAAAAAAAAAgmwAD0h7yydDUnDAkkUzzn2xSRG8GwalWWqou+BD+9mCfhiVF9YMUm1erCKIIOtVpJOTyxBy9CekYRr3r15uwhhFR0xa+k24YkOl2M/AFQHg2hFFyQ1DRqQVxPHOLvDY33XmfR8NUSqtn6caW7O4d5Tf90unTYACfaysDxiG6OopBeGSNGFaNAd85XU8e60kTaPTihi9orqjeHh2pqeU4S4j9pVYovdi/Iv4/Ggv3GNIeSXS7YFYdnwEcklMNIuc7vL6kpIaOGPThW7qW3RD7Q//HNtOd31s7l5XNBTsXuFncUzZeNM9SaF6NK0wSuIG5jO/TaSBVAelcB/Olu8/tkjlLAjyOUlAwyKXtAwVYg5W/iJ067tfw4AVblSdfhip9OVAhzsxD4zfSEUn9BaGOZ4n+Q68OgmysZOkeF0Pkjew7zwnXKyxegU6FrMvTJd/8HfKO6X+/AxF60++RYDqXJ/+DOBgA), and [2](https://topaz.github.io/paste/#XQAAAQDHAwAAAAAAAAAgmwAD0h7yydDUnDAkkUzzn2xSRG8GwalWWqou+BD+9mCfhiVF9YMUm1erCKIIOtVpJOTyxBy9CekYRr3r15uwhhFR0xa+k24YkOl2M/AFQHg2hFFyQ1DRqQVxPHOLvDY33XmfR8NUSqtn6caW7O4d5Tf90unTYACfaysDxiG6OopBeGSNGFaNAd85XU8e60kTaPTihi9orqjeHh2pqeU4S4j9pVYovdi/Iv4/Ggv3GNIeSXS7YFYdnwEcklMNIuc7vL6kpIaOGPThlaCjJRP6mX3vm2DiW3VjWFksMaEgXONssD3iNtoq3uQVPbFpSyovVwj942gIKq/iPaoqz7rOxll8LGYrcSpYhT+RHkDnxWSorTjt/juvXPYr4LaQMF5WwM9DVUa9c09HFRx466lmUEVLfHdKe3nJUsNzbGvQ47/MgLC0LEiv7i0dglb4KYq1MKyjzIUdWhGRuzlly5fJosTTAnB2WW2vWPf/RqnVAA==)), so I can live with that.

Final plumbing:

And that's it!

Advent of Code: [2015/16](https://adventofcode.com/2015/day/16)

You are very lucky because you have your "My First Crime Scene Analysis Machine" with you, and you can use it on the gift to detect what's it made of; with that (i.e. the scan result) and a list of all the things you could remember about each of all the 500 aunt Sues, you hope you will be able to figure which aunt sent the gift to you.

The scan result is given -- not part of the _input_, but known upfront anyway -- and I decided to model it using an ALIST mapping each compound to the detected quantity:

The actual input instead is the list of things we remember about each aunt:

We are going to parse these into a single ALIST mapping aunts (i.e. their name), to the list of compounds we can remember for them (`:cl-ppcre` to the rescue):

With all the input mangling taken care of, we need to figure out which aunt sent the gift to us; we are going to to that iteratively:

- For each compound from our scan result
- For each _remaining_ aunt
- See if what we remember of that aunt matches or not the result of the scan
- If it does, then _keep_ the current aunt in the set of candidates, otherwise, remove it

Note: the list of things we remember for each aunt is **not** complete (we don't remember everything), so when filtering out candidates, we only want to exclude those aunts that have a value for the given compound which is different from the scanned one (if we don't remember, we cannot make any assumptions, so we will keep that aunt in the list in the list of candidates).

Anyway, all this _nicely_ translates to:

In part 2 we realize the scanner is not as _precise_ as we thought it was, and that for certain compounds it's only able to tell us if the detected amount is above / below a given threshold:

Here we create a new function, ABSENT-OR-MATCHES-WITH-RANGES, to properly read the new scan result; rest is pretty much unchanged:

Final plumbing:

And that's it!

Advent of Code: [2015/17](https://adventofcode.com/2015/day/17)

The elves bought too much eggnod (`150` liters to be precise), and you are asked to help them put it into smaller containers (your input). How many different _combinations_ of containers can you come up with, to fit all that eggnod?

The input is a list of integers, one per line, so I am just going to use my utility function PARSE-INTEGERS for this.

For the actual solution of this problem, I am going to generate all the possible combinations of containers which add up to `150`, in a recursive fashion:

- Until you have containers left to use, or the remaining eggnod is greater than zero
- Try to use the first available container, and recurse
- Or skip the first container, and recurse
- When the remaining eggnod is zero, there we found a possible solution -- save it somewhere

With this, the solution to part 1 simply becomes applying LENGTH to the result of invoking SOLVE with the given list of containers:

For part 2, we are asked to count the solutions that use the least number of containers:

Final plumbing:

And that's it!

Advent of Code: [2015/18](https://adventofcode.com/2015/day/18)

Looks like we got a little [Game of life](https://en.wikipedia.org/wiki/Conway%27s_Game_of_Life) problem today:

- Given a grid of `1000x1000` lights -- for each, whether it's on or off
- Given a set of rules telling if a specific light should turn on or off based on the state of its 8 adjacent lights -- it turns out the given rules match Conway's

How many lights will be on, after 100 iterations?

Let's begin with parsing the input grid into a bag (i.e. HASH-SET) of coordinates, representing the lights which are on.

With this, and thanks to my utility system, [:gameoflife](https://topaz.github.io/paste/#XQAAAQAbCQAAAAAAAAAUGQimgulVkMqJePdJ12sdAxC/GfcryUc62cNZO2Y9F49pcnga9KUiRymDklgNdDlqcv2dhjGOqX7N8ovjj8SaUTGvr5mN0/ulEICo5hK0220UqGzQVBykFN8pav/Pr4ITd4I3DKGyJRgy7/3T0ryWzgCloLL3GRvf/oikkYBmCALRghWKKt02J3vWavnPlqpnVW/0CYFBYT1CImg7lRpoFmbiwrr4lqIjkFF9HDELYMnxDSBE0fJlw3dgFW6rFaM4YMs0HVdk4wfjJRHUXLkZWm86TDvx+uDMnFWtXK7opquIKAqfRlRKnMzX1aTKqoNyJK/nZ4PRBS+eNkePip+rIxtmHT44/OMoMw+Ib0OR1tm/Wvc0JRb08vblxbpHcX0LLcGntGNYVBxdrKwjoDdRwe8bzTXy8x4o2tL8qyMSWHwsxyAsMwBJQCJSrGjWf0T4E9gkEPAyX8RiAJzcdL9UQDKNSyefq3naHa4/l+bFQlDabeLjVJYh/GDZpW/a5384/Vi/gIFqtFc/5Tlweqwvms+KrkC6ertm0ycdLUNug96wUPyZdA5LkQUb8sCujjboX6FNGfXgLclCf7vmKPj9osR4YueiK9a0DR1q2MvSF3JeFcv/5rLKlt3GY8dSpl9Rbe5fceaQ2pJ2ukOE1pFFqYzHnaSBr+Bf0PMpbba/VoViIzSHb+c3qM1/5PLCtjBPeCvazHVnOU4cI+N3nuzTRnoVItUWvIq4MWAVX6xtnpeRb/s+hq6VImuzAdgpyfUHBzlBq61pCK/qg5h9w+q7plvUXoB35EgDVikCU6wBFIlHz43SAZkaBHBxdNmpb7VKwuL0plBwewcZswzb9cyQnEkJo1Ec67BVaLc05c4mj/rGw+NbA5AL1glqawnAwQUmzKLxgb/sDbSfQcmEMH32YFW5ybZ8v9qkU9KL435TKdPfw8fMzt3teS1QBVFfpP246FC1C2g3clAOnwDNWKNeQ4BgoiXZlpK1S42WA7fM2yT+GC8//i0MgbL/tYtgI+Vl7ILQ9ALTARWez7Pjk9qZnPvA3pVeddhKzy++jwCXP4PP0nQjvoNrQnx5/eSMVasKElJQkV6G+7bfFGQDCh9NgiyD5/2/I+wuvlmCWmMDxCpBsiKhZhGq5rEgPxkAjJU2SxFtd2fLkrsSZJ8ZH9PGfhfTe6clCMmLmrotGQRXtb6LVaTVv3pnhuK+KxKUdzOT3AomFQ1wJyKAIbrMqbeUJrqNBTAKBnzLuEiBXW9HjLz7dJ/oN423vajgAWKyfmoRSIIbbLoozU8/bXZdhzEC3pO4qUAuJpCsQQcnnvb6zeq6ogzuppcq3VjSacH1VaU0czL6LFXVRBZQroPuRol2kHRnjoCpyw8ijSboqRkn117BvJhCOg4P//hNZK8=), that I created to model game of life dynamics, solving this problem should be pretty simple (the only difference with the _classic_ game of life is that here the grid is limited, hence my custom NEIGHBORS function to filter out of bounds positions):

For part 2 we notice the lights placed at the four corners of the grid are _always_ on; how many lights will be on after 100 iterations?  All we have to do, is set those 4 corners on, after each iteration of the game:

Final plumbing:

And that's it!

Advent of Code: [2015/15](https://adventofcode.com/2015/day/15)

Given a list of ingredients (each listing their properties like `capacity`, `durability`, or `calories`), and knowing that there are only `100` teaspoons worth of ingredients left to complete the recipe, which ingredients you are going to use, to maximize the _quality_ of the cookie.

As usual, we will start by parsing the list of ingredients (e.g `Sprinkles: capacity 5, durability -1, flavor 0, texture 0, calories 5`) into -- guess what -- a LIST of properties (note: `capacity` is always the first property, `durability` the second, and so on and so forth, so that makes the parsing a bit easier):

We only have `4` ingredients, and a maximum `100` teaspoons to play with, so I am going to brute-force this.

The first step is to list all the possible recipes:

- How many teaspoons of `Sprinkles`? From `0` up to `100`
- How many teaspoons of `PeanutButter`? From `0` up to `100 - sprinkles` (we might have used some teaspoons for sprinkles already, so we need to account for that)
- How many teaspoons of `Frosting`? From `0` up to `100 - sprinkles - peanut`
- How many teaspoons of `Sugar`? `100 - sprinkles - peanut - frosting`

For each of these recipes, make a cookie out of it and calculate its _total score_ (i.e. product of all its _non-negative_ properties, ignoring `calories` for now).  The solution to part 1 will be the maximum of all these scores:

For part 2, we are asked to consider only those cookies that turn out to have `500` calories -- they want to use these as meal they say -- so all we have to do, is change our base case condition and have it return the cookie score if the number of calories is `500`, or `0` otherwise (we will be maximizing the result, so we know `0` would not get in the way):

Final plumbing:

And that's it!

Advent of Code: [2015/13](https://adventofcode.com/2015/day/13)

Today, we are challenged with finding the _optimal seating arrangement_ that minimizes those awkward conversations.

Given a **round** table, a list of guests, and how much each of them would love / hate to sit next to every other guest on your list list; what's the seating arrangement that maximises the happiness of the table?

Let's start by looking at the entries of the input we are expected to process:

We will first parse each entry into 3 elements lists (e.g. `("Alice" "David" -75)`), and then store them all into an association list mapping from guests, to how more / less happier they would be if they were to sit next to another guest:

How can we find the optimal arrangement? Well, it turns out there are only 8 people in our guest list, so we might as well try all the possible arrangements and find the best one.

First we define functions to calculate the positive/negative delta in happiness, if two given people happened to be sitting next to one another...

...and to calculate the total happiness associated with a specific seating arrangement:

With this, all there is left to do is generating all the possible seating arrangements, and pick the best one (i.e. the one that maximises CIRCULAR-TABLE-HAPPINESS):

For part 2, you realize you forgot to add your name to the guest list, so you are asked to find the new best seating arrangement, knowing that you would not make anyone happier/sadder by sitting next to them.

At first I thought about literally implementing this: add a new guest to the list, change LOOKUP inside DELTA-HAPPINESS to return `0` if called for the new guest, and try all the possible combinations (there would be `9!` of them, which is still OK); but then I realized that since nobody is neither positively nor negatively affected by me sitting next to them, we can remove the new guest from the picture, and simply imagine the table not to be _circular_ at all!

Say you have this table arrangement: `A B C D A` (it's a circular table, hence the two `A`s), and wanted to see what would happen to the happiness of the table if I, the new guest, were to sit in between `B` and `C` (i.e. `A B C @ D A`); well, since neither `C` nor `D` will be positively / negatively affected by me sitting next to them, we can then calculate the happiness of the arrangement `D A B C`, without the wrapping around part (in a sense, the table has now become linear).

So we don't have to add ourselves to the list, but we simply have to change how the happiness of the table is calculated!

Final plumbing:

And that's it!

Advent of Code: [2015/14](https://adventofcode.com/2015/day/14)

This is the kind of input entries we will be dealing with:

We will parse these into lists listing:

- The name of the reindeer (not really needed, but whatever)
- How fast the reindeer is
- How long it can run for
- How long it has to rest for before start running again

Each reindeer seems to have a _period_ (given by the sum of how long it can run and how long it has to rest after the run), and during this period they will travel a distance equal to their speed; with this, knowing how far a given reindeer would have traveled in a given amount of time, should become a matter of figuring out the number of activity _cycles_ that fit into the given amount of time, and then multiply that by the reindeer speed (you will also have to deal with partial cycles, but you get the idea):

For part 2, Santa wants you to tell not the reindeer that traveled the most, but the one that scored the highest number of points (every second, the leading reindeer(s), would get `1` point).

I could not figure out a way to solve this _mathematically_ (I am not even sure such solution exists), so I went on and implemented a _simulation_ of this game:

- `scores` represents the score of each reindeer
- `distances` represents the distance each reindeer has traveled
- `run-fors` represents how long each reindeer has been running for (in the current running activity)
- `rest-fors` represents how long each reindeer has been resting for (again, in the current running activity)
- for each simulation _tick_, see which reindeer can move (and have it move), which one needs to rest (and have it rest), and finally assign `1` point to the leading reindeer or reindeers

Final plumbing:

And that's it!

Advent of Code: [2015/10](https://adventofcode.com/2015/day/10)

Today's task, is to implement the [Look-and-say sequence](https://en.wikipedia.org/wiki/Look-and-say_sequence); in particular, given an initial list of digits, we are asked to "play" this game for 40 rounds, and to return the length of the result.

We start off by parsing the input into a list of digits (I am using `(cl-ppcre:split "" ...)` to split the input string into its signle character values):

Then we go ahead, and implement the rules of the game (the careful reader would have noticed by now that this is exactly the same as implementing [run-length encoding](https://en.wikipedia.org/wiki/Run-length_encoding)):

With this, the answer to part 1 becomes a simple:

For part 2 instead, we are asked to apply the same process 50 times. Ok...

Final plumbing:

And that's it!

Advent of Code: [2015/11](https://adventofcode.com/2015/day/11)

Santa's password has expired, and we are asked to help him find the next one to use; we know Santa is a lazy guy, and will try _increase_ the current password, one step at a time (i.e. `ay`, `az`, `ba`), until he finds one that matches certain requirements:

I think a brute-force approach will do just fine:

- Generate the next password
- Check whether if it violates or not, any of the policies
- If it does, repeat, otherwise, there you have Santa's new password

Let's start by implementing functions that will aid with the generation of the next password (note: given how the next password has to be generated, I opted for reversing the character of the password first, that way I could come up with a nice _recursive_ solution):

The next step is to implement functions to check the 3 different requirements (note: since the characters in my password are in reverse order, the first requirement, three _increasing_ straight characters now becomes checking for three _decreasing_ straight characters instead):

Some final glue, and we should be all set:

For Part 2 we are asked to find the next new password, after the one we just found, so a simple simple `(new-password part1)` will get the job done.

Final plumbing:

And that's it!

Advent of Code: [2015/12](https://adventofcode.com/2015/day/12)

Given a string with some JSON in it, what is the sum of all numbers in the document?

I believe you should be able to answer this with the use of regular expressions only, but since I never dealt with JSON in CL before, I figured I would use this as an opportunity to play with [some libraries](https://sabracrolleton.github.io/json-review), and ultimately decided to go with [st-json](https://marijnhaverbeke.nl/st-json/).

`:st-json` conveniently ship. with READ-JSON-FROM-STRING, so parsing the input (i.e. a single JSON string) turned out to be ridicolously easy to do:

Now that I have my JavaScript object, in memory, I need a way to sum all of its numeric values (nested ones included); I am going to solve this recursively, as follows:

- If the current object is a STRING, then return `0`
- If the current object is a NUMBER, then return the object itself
- If the current object is a LIST, then recurse into each element, and sum the result
- Otherwise (it's an object), iterate all its values, recurse into them, and sum the result (note: MAPJSO is to JavaScript objects what MAPHASH is to HASH-TABLEs):

For part 2, we are told to ignore any object (and all of its children) which has any property with the value `"red"`.  This translates to the following (not the call to RETURN-FROM to break early out of MAPJSO):

Final plumbing:

That's it!

Advent of Code: [2015/09](https://adventofcode.com/2015/day/9)

Given a list of locations and the distances between every pair (of locations), what's shortest distance you have to travel to visit them all?  This smells like classic [TSP](https://en.wikipedia.org/wiki/Travelling_salesman_problem), and by the look of the input file it appears we are dealing with just 8 different locations, which means testing all the possible combinations will not take years to complete.

Anyway, as usual, let's start with parsing the input.  We are given a bunch of lines representing the distance between two locations (e.g. `London to Dublin = 464`), and we would like to store them in such a way that answering questions like: "what's the distance between a and b" would be easy and quick at the same time.

I am going to use an association list (the input is small and I don't think using a HASH-TABLE will make much of a difference) and since the distance between `a` and `b` will always be the same as the distance between `b` and `a`:

- When adding a new a new entry in the alist, we will use the one with the lexicographically smaller name as key, and the other (plus the distance) as value
- When querying for the distance between two locations, we will use the lexicographically smaller location name as alist key

Anyway, the above translates to:

Like I said earlier, we are going to brute-force all the possible paths, and find the shortest one.  First we need a way to extract the list of locations from the alist of connections:

Then, all we have to do is:

- Generate all the possible routes
- For each, calculate the total travelled distance
- Find the shortest one, and return its total distance

In part 2, Santa wants us to find the longest path instead (don't ask why).  Anyway, a simple change from `#'min` to `#'max` should do just fine:

Final plumbing:

And that's it!

Advent of Code: [2015/07](https://adventofcode.com/2015/day/7)

We are are given a _circuit_ (i.e. wires, gates, and the values of some input signals), and we are asked to figure out the signal being transmitted on a specific wire, `a`.

As usual, let's begin by parsing our input:

Each line represent a connection between a signal and a wire (e.g. `123 -> x`), or a gate and a wire (e.g. `NOT y -> i`); signals are numeric inputs (e.g. `123`), while wires are _alphabetical_ ones (e.g. `x`); finally, gates can have one or two inputs (e.g. `NOT x` and `x LSHIFT 2` respectively).

My plan is parse each line into a list having as elements:

- the output wire -- since gates can have 1 or 2 arguments, I figured I would move the output wire first in the list
- the boolean function the _connection_ is describing (i.e. a function implementing the specific boolean operation)
- the arguments of the function

How are we going to measure the signal on a given wire? (`a` in our case) I think a _recursive_ solution will do:

- Find the instruction listing our target wire as its output
- Evaluate the left-hand side of the expression (i.e. first recursively get the signal at its input(s), then apply the boolean function)
- I suspect the input circuit was created in such a way that the same gate would need to be evaluated multiple times, so I am going to keep track of the already processed gates, and their output signal (i.e. memoization)

For part 2 we are asked to override wire `b` with whichever signal we measured on wire `a` for part 1, and then measure wire `a` again, and luckily for us, we did not have to change anything except for the input:

Final plumbing:

And that's it!

Advent of Code: [2015/08](https://adventofcode.com/2015/day/8)

In today's problem we are given a list of strings having specific characters _escaped_, and we are asked to calculate the difference, in bytes, between the escaped and unescaped versions of these strings:

Our input will come in as a list of strings already, so no additional effort will be required to parse the input.

The next step is to calculate the length of a string, knowing that certain characters will come in escaped, and hence need to be _unescaped_(i.e. `\\`, `\"`, and `\x` followed by 2 digits).

My idea was to keep an index, `index`, pointing to the next two characters in the string we should look at, `ch` and `ch1`, and:

- If `ch` is `\` and `ch1` is `x`, move `index` ahead `4` positions
- If `ch` is `\`, move `index` ahead `2` positions
- Otherwise, move `index` ahead `1` position

Count the number of times we do this (i.e. `sum 1`) and at the end of this subtract `2` corresponding to the surrounding quotes:

With this, calculating how much the literla string representation differs from the in memory one should be as simple as:

Part 2 instead asks us to escape input strings first, and then calculate the difference between the escaped and unescaped versions (note: the unescaped version of a string in this case, is equal to the string itself, without modifications).

As it turns out, all we have to do while escaping a string, is:

- Surround the whole thing with quotes
- Escape `\` and `"`

This nicely translates to the following:

Final plumbing:

And that's it!

Advent of Code: [2015/05](https://adventofcode.com/2015/day/5)

Given a list of strings, which ones are _nice_ and which ones are _naughty_?  A string is _nice_ if:

There is not much we need to do to parse the input, as it will come in as a list of STRINGs already; rest is implementing a function to check the above rules, and then count which ones of input strings test positive to this predicate.  Note, I am going to use regular expressions (i.e. `:cl-ppcre` to implement the rule checking logic):

Part 2 is similar to part 1, except that the rule set is different:

Again, pretty easy to implement using regular expressions:

Final plumbing:

And that's it!

Advent of Code: [2015/06](https://adventofcode.com/2015/day/6)

Simulation problem: given a 1000x1000 lights grid, and a set of instructions to turn certain lights on or off, or to toggle their state, how many lights will be turned on at the end, after having executed all the instructions?

We start off by parsing the list of instructions, which can be any of the following:

- `turn on 1,2 through 3,4`
- `turn off 5,6 through 7,8`
- `toggle 9,10 through 11,12`

I am going to be using regular expressions again (note: `?:` is the syntax for [non-capturing groups](https://stackoverflow.com/a/3513858)):

This will take care of parsing instructions like the ones we have seen above, into:

- `(:on 1 2 3 4)`
- `(:off 5 6 7 8)`
- `(:toggle 9 10 11 12)`

The next step is to run the _simulation_.  I am going to use a two-dimensional ARRAY for the grid, storing T for when the specific light is turn on, and NIL otherwise.

The last step is to count the number of turned on lights (i.e. the number of T in the 2d array):

For part 2, it turns out each light has adjustable brightness (it's not just on and off), and the instructions assume a slightly different meaning:

- `:on` means increasing the brightness by 1
- `:off` means decreasing the brightness by 1, without going negative
- `:toggle` means increasing the brightness by 2

After having executed all the revised instructions, what's the total brightness of the grid?

We are still going to use a two-dimensional array for the grid, but this time we will store numbers in it (i.e. the brightness value of the specific light):

Final plumbing:

And that's it!

Advent of Code: [2015/04](https://adventofcode.com/2015/day/4)

AdventCoins mining!

Unfortunately there is not much we can do here except for bruteforcing (and before you ask, I did **not** implement MD5 myself...I found a package that did it for me):

Part 2 is pretty much the same, except that now we are asked to find a hash with 6 leading `0`.

Final plumbing:

And that's it!

Advent of Code: [2015/02](https://adventofcode.com/2015/day/2)

We are given a list presents/boxes dimensions (i.e. `12x34x45` with `12` being the length of the box, `34` being the width, and `45` the height), and we are asked to calculate how much paper is going to be required to wrap them all:

We start by parsing input lines into 3-element lists (I am using `:cl-ppcre` to do the splitting, but `:split-sequence` would have done just fine):

Then we define a function to calculate the amount of required , apply it to each input set of dimensions, and sum each result.

What present box is it, without some ribbon? For part 2 we are asked to calculate how much ribbon we will need knowing that:

Again, we define a function to calculate how much ribbon is required for each box, apply it to each input set of dimensions, and sum the result:

Final plumbing:

And that's it!

Advent of Code: [2015/03](https://adventofcode.com/2015/day/3)

Here we are given a list of instructions Santa is going to follow while delivering the presents to the village houses, and we are asked to figure out how many houses will receive at leat one present (yes, following the instructions might bring Santa back to an already visited house).

Anyway, the input is a list of characters (i.e `^` for north, `v` south, `<` for west, and `>` for east), and I am going to parse these into COMPLEX numbers again, like we did for day 1:

Next, starting from position `0` we are going to move santa around, and keep track of the unique list of houses he visited (note: I could have used a HASH-TABLE, but given the input size I figured using a LIST and PUSHNEW would have done just fine):

For part 2, the elves decide to pair Santa with a Robot (starting at position `0` with Santa), and split instructions amongst them:

- First instruction to Santa
- Second instruction to the robot
- Third instruction to Santa...

Final plumbing:

And that's it!

Finally fixed some weird indentation problems with my Vim/CL setup

Every time one of my files included a `#\(`, _bad_ things will happen:

- matchit's `%` mappings would land me on the the closing parenthesis immediately _after_ the expected one
- vim-sexp's `vaf` and `vaF` mappings would end up selecting _partial_ forms
- vlime's would start suggesting positive indentation levels even for toplevel expressions

As it turns out all these plugins use `searchpairpos()` behind the scenes to find pairs of matching parentheses, and since that function already supports skipping over configured syntax regions, I _simply_ had to figure out a way to tell it which region to skip:

- matchit: I added `let b:match_skip = 's:comment\|string\|escape\|symbol'` to my vimrc
- vim-sexp: I had to create a [PR](https://github.com/guns/vim-sexp/pull/28)
- vlime: I had to create a [PR](https://github.com/vlime/vlime/pull/64)

No more `(char "(" 0)` hacks!

Advent of Code: [2015/01](https://adventofcode.com/2015/day/1)

We are given a string containing a bunch of `(` and `)` characters representing "move one floor up" and "move one floor down" instructions respectively:

- `(())` means go up two times, and then go down two times
- `(((` means go up 3 times
- `()(` means go up 1 time, then down 1 time, then again up 1 time

We are asked to find the floor we find ourselves at, after having followed all the instructions.

We start off by converting the input into a sequence of _floor movements_ (`(` becomes `1`, and `)` becomes `-1`):

With this, part 1 simply becomes a matter of summing all the read instructions together:

For part 2 instead, we are asked to find the first instruction (i.e. the instruction's _position_ in the list) that takes us to floor `-1`.  Not a big deal; instead of using REDUCE and +, we execute all the instructions inside a LOOP form so we can break out of it as soon as the current floor is `-1`:

Final plumbing:

And that's it!

TIL: the first LOOP's `:thereis` non-NIL form is also going to be the return value of the LOOP form itself

What if you wanted to return return the first _odd_ element, and not just whether such element exist?  You can use AND:

Is it possible pass to CHECK-TYPE  a _parametric_ type? i.e. a type that depends on the run-time value of some other function argument?

An example: say I have a DIGITS-TO-NUMBER function accepting as arguments:

- the digits of the number -- i.e. list of integers, each less than...
- a given base

Is this _possible_? I think it should, especially because we are talking about run-time checking, but maybe there is something else I am not properly taking into account.

Anyway, first I defined the predicate/type for this:

Then I tried to add this to DIGITS-TO-NUMBER, `(check-type digits (list-of-digits base))`, but if you have a look at what CHECK-TYPE expands to, it's clear my attempt would not work:

I was able to achieve what I wanted with the following:

But then I would need to re-implement the restart mechanism which is already in place if you use CHECK-TYPE right?

Well it turns out you can not:

This translates to:

And yes, if you want the restart functionality, then you'll need to modify the code a bit.

Advent of Code: [2020/25](https://adventofcode.com/2020/day/25)

Solution:

- Bruteforce the "loop-size" param for one of the 2 inputs
- _transform_ the other input with the found "loop-size"

And that's it, folks!

PS. I started with AoC in 2018, to learn Common Lisp, and I have been using it since.
PPS. This is the first year that I managed to a) get all the 50 stars by the 25th, b) complete all the problems within 24 hours.
PPPS. I did not know you had to rush and click on the link to get your second star, so basically my part 2 completion time tells you something about how fast/slow I am at reading things ;-)

Advent of Code: [2020/24](https://adventofcode.com/2020/day/24)

Solution:

- [Pointy topped](https://www.redblobgames.com/grids/hexagons/) hex grids
- Parse instructions into list of steps, i.e. COMPLEX numbers pointing to the next, adjacent, tile
- Part 1: iterate all the instructions, execute all the steps, and flip the state of the tile you find yourself in at the end
- Part 2: another game of life <3 -- my utility libraries (i.e. [:hset](https://topaz.github.io/paste/#XQAAAQBWAwAAAAAAAAAUGknC0wGe+rxWxGbsuM8XKlXe+zDDeRr4lNRd45fFnhvNSenyD67lPZMOacbfl1vMLbImXQNGkRGm0LFaP9G10YtnY4Zaf8bWX8Td4J0uic8xm16hYOSoVvk8BIkKChEqlP7kbfGlKN9jE/jRjtUMzeK1gyEVQNY+RUDoIYDJANFNu1SZhTUGuQnFKdMGTqLAvG13qGropmbb8XSlBVNxNYatfyPAWFxOvGvcPQ3csBNV9Lu0Ko6fp9yALeEc0SXrRItn9ra7r5RsK6PXuKHSlV9cX8P5+jc4z1RDqgFWSaH/tytsU+skUEWp/akDGwakswDIuMN3HNrjU9UP02bs3FFSMZPm9xkNui00uEY9X0Mv/03HzZiPbzu7dmgSy4su/3sSJpozm9pGsNndqDHw1+NWwNPlH1d76RN2/E3pUBUFKlfkvx5mADArsx1+w8YT48cODPJn1xhJ3oci4Etp5lws5JmT0SM4RKZeC37j1mJ5xfNk1pTCQh/Epa8PbQvCU8gzcIy0A4jgQc9Vz7lUMjyhVaGrxSD0ETVSJs4Ja9ZP7T+W6okQd/t4hTg=) and [:gameoflife](https://topaz.github.io/paste/#XQAAAQAbCQAAAAAAAAAUGQimgulVkMqJePdJ12sdAxC/GfcryUc62cNZO2Y9F49pcnga9KUiRymDklgNdDlqcv2dhjGOqX7N8ovjj8SaUTGvr5mN0/ulEICo5hK0220UqGzQVBykFN8pav/Pr4ITd4I3DKGyJRgy7/3T0ryWzgCloLL3GRvf/oikkYBmCALRghWKKt02J3vWavnPlqpnVW/0CYFBYT1CImg7lRpoFmbiwrr4lqIjkFF9HDELYMnxDSBE0fJlw3dgFW6rFaM4YMs0HVdk4wfjJRHUXLkZWm86TDvx+uDMnFWtXK7opquIKAqfRlRKnMzX1aTKqoNyJK/nZ4PRBS+eNkePip+rIxtmHT44/OMoMw+Ib0OR1tm/Wvc0JRb08vblxbpHcX0LLcGntGNYVBxdrKwjoDdRwe8bzTXy8x4o2tL8qyMSWHwsxyAsMwBJQCJSrGjWf0T4E9gkEPAyX8RiAJzcdL9UQDKNSyefq3naHa4/l+bFQlDabeLjVJYh/GDZpW/a5384/Vi/gIFqtFc/5Tlweqwvms+KrkC6ertm0ycdLUNug96wUPyZdA5LkQUb8sCujjboX6FNGfXgLclCf7vmKPj9osR4YueiK9a0DR1q2MvSF3JeFcv/5rLKlt3GY8dSpl9Rbe5fceaQ2pJ2ukOE1pFFqYzHnaSBr+Bf0PMpbba/VoViIzSHb+c3qM1/5PLCtjBPeCvazHVnOU4cI+N3nuzTRnoVItUWvIq4MWAVX6xtnpeRb/s+hq6VImuzAdgpyfUHBzlBq61pCK/qg5h9w+q7plvUXoB35EgDVikCU6wBFIlHz43SAZkaBHBxdNmpb7VKwuL0plBwewcZswzb9cyQnEkJo1Ec67BVaLc05c4mj/rGw+NbA5AL1glqawnAwQUmzKLxgb/sDbSfQcmEMH32YFW5ybZ8v9qkU9KL435TKdPfw8fMzt3teS1QBVFfpP246FC1C2g3clAOnwDNWKNeQ4BgoiXZlpK1S42WA7fM2yT+GC8//i0MgbL/tYtgI+Vl7ILQ9ALTARWez7Pjk9qZnPvA3pVeddhKzy++jwCXP4PP0nQjvoNrQnx5/eSMVasKElJQkV6G+7bfFGQDCh9NgiyD5/2/I+wuvlmCWmMDxCpBsiKhZhGq5rEgPxkAjJU2SxFtd2fLkrsSZJ8ZH9PGfhfTe6clCMmLmrotGQRXtb6LVaTVv3pnhuK+KxKUdzOT3AomFQ1wJyKAIbrMqbeUJrqNBTAKBnzLuEiBXW9HjLz7dJ/oN423vajgAWKyfmoRSIIbbLoozU8/bXZdhzEC3pO4qUAuJpCsQQcnnvb6zeq6ogzuppcq3VjSacH1VaU0czL6LFXVRBZQroPuRol2kHRnjoCpyw8ijSboqRkn117BvJhCOg4P//hNZK8=)) are finally paying off

PS. I woke up early today because I have errands to do (who doesn't, these days...), and figured I did not want to ruin today as well, especially the ridiculous amount of time I spent solving yesterday's problem. Guess what? You wake up early, the problem is easy, and you end up with a new personal score:

TIL: you cannot freely use `and`s inside LOOP `for` expressions.. you need to be careful!

So it seems like you can use `and`s when chaining assignments of the _same type_ (i.e. sequence iterations with sequence iterations, number ranges with number ranges...).  From the Lisp Discord server:

Advent of Code: [2020/23](https://adventofcode.com/2020/day/23)

Solution:

- Create a _circular_ list -- let's thank Quickutil's [NCYCLE](http://quickutil.org/list?q=ncycle)
- Part 1 (play the _damn_ game)
- select the _next_ three cups
- find the destination cup -- it's a circular list, so MEMBER here will do just fine
- update the list -- I used PSETF to update multiple places...in _parallel_
- Part 2 (play the _damn_ game, again, with 1M cups, and this time stop after 10M moves)
- it's _clear_ our calls to MEMBER are the bottleneck we should try to get rid of
- how? create a HASH-TABLE mapping cup labels to their _places_ in the circular list
- fuss around with LIST pointers

How fast does this run?

It's probably not the fastest thing in the world, but it gets the job done!

Advent of Code: [2020/22](https://adventofcode.com/2020/day/22)

Solution:

- Nothing crazy, just do as told -- I thought about using a deque to implement a deck, but as it turns out a LIST will do just fine
- Part 1: pop, pop, compare, append, until one of the decks is empty
- Part 2: not as _simple_ as part 1, but close enough
- ALREADY-SEEN-P returns `t` if the current game (i.e. the two decks) has already been _played_ before
- MARK-AS-SEEN marks the current game as played
- PLAYER1-WINS-TURN-P is where most of the logic for part 2 lies (i.e. check if players have enough cards to recurse, then recurse or check the top of their decks)
- The rest is plumbing

PS. I finally found a use case for [MULTIPLE-VALUE-CALL](http://clhs.lisp.se/Body/s_multip.htm)
PPS. I know this seemed easy, but it took me forever to solve part 2:

- I forgot to pass :test 'equal to my call to MAKE-HASH-TABLE -- making the "already played game" logic useless..
- Fixed that, I still got the "already played game" logic wrong; I know it was clearly stated in the text description, and I remember paying attention to it, still, I ended up caching across all the played games!
- Lastly, when preparing the decks for the nested game, I had a typo that caused my algorithm to use all the remaining decks and not just as many as the value of the card we just read (e.g. I had `(subseq (rest deck1) 0 n1)` instead `(subseq (rest deck1) 0 c1)`, where `c1` is the last read card, and `n1` is the size of the remaining deck), and because of that I started blaming on the used data structure and tried to implement this using a deque (and halfway through the newer implementation, I realized the silly mistake I had made...)

Advent of Code: [2020/21](https://adventofcode.com/2020/day/21)

Solution:

- Parse food into a list having the list of ingredients as first element, and the list of allergens as second -- i.e. `'((mxmxvkd kfcds sqjhc nhms) (contains dairy, fish))`
- Then find the `ingredient -> allergen` mapping, using backtracking
- Start with all the foods, and an empty mapping
- For each remaining food, for each of its ingredients, `i`, for each of its allergens, `a`, see if `i -> a` is valid mapping; if it is, update foods by removing all occurrences of `i` and `a` and carry on, otherwise, backtrack
- A new mapping is valid if, for each remaining food, either `a` is not one of its allergens, or if it is, then `i` **has** to be in the list of ingredients
- The stop condition is when there are no more allergens to try
- Part 1: I had my FIND-MAPPING function return the list of foods without a clear mapping, so I went on and counted the remaining ingredients
- Part 2: do as told -- sort the mapping by the allergen name, and concatenated the ingredients
- PS. This naive solution could take forever to complete if you are not careful at selecting which of the remaining foods to try first; I thought it would make sense to try first the foods with the smallest number of ingredients / allergens (see SORT-FOODS), and apparently that did the trick

Time to mop up [2020/16](https://matteolandi.net/plan.html#day-2020-12-16)'s solution.

Let's start with part 1:

- For each "nearby" ticket
- For each of its values
- See if it's in range range with any of the defined rules -- and if not, sum these values

It's that simple: no arrays, no trying to be clever, KISS!

Now let's move on to part 2:

- First we filter out any _invalid_ ticket
- Then we find the mapping; how? Backtracking
- Start with a _table_ mapping each rule to the ticket positions for which **all** the "nearby" tickets have valid values for that rule, and an empty field mapping
- For each remaining rule `n`, try to use that at one of the _compatible_ ticket positions `p` -- remove `n` from the list of remaining rules, and remove `p` from all the remaining rules _compatible_ positions
- If the new set of rules is invalid -- i.e. there is at least a rule without _compatible_ ticket positions -- it means we reached a dead end, and we need to backtrack
- If we run out of rules to try, it means we found our mapping
- Otherwise, repeat
- PS. To speed things up, of all the remaining rules we will try and evaluate the ones with the least number of _compatible_ ticket positions first

That's it!

Advent of Code: [2020/20](https://adventofcode.com/2020/day/20)

Solution:

- Parse input tiles into LISTs having the id as first element, followed by the content of the tile (first row of data, second row of data...) -- `(list 1234 "...#....." ".#.#..#.." ...)`
- Define functions to rotate a tile counterclockwise, and to flip it -- these are enough to generate all the possible transformations...you just have to apply them in sequence: rotate, rotate-flip, rotate-flip-rotate, rotate-flip-rotate-flip...
- Part 1
- Backtracking solution
- place a tile in the top-right corner; what remaining tiles (and their transformations) can be placed to its right?
- try one; what remaining tiles (and their transformations) can be placed to its right?
- carry on until you can, back track when reaching a dead end (i.e. no more compatible tiles)
- Caveat: when placing a new tile you have to check not just the tile on its left, but also the one at its top
- Optimization: before running the algorithm I indexed all the input tiles (and their transformations) by their top border, left border, and top and right border combined, hoping that that would speed things up -- and I guess it did
- Part 2
- Re-assemble the image -- I got this part wrong initially, but only realized it at the end...
- Brute force
- For all the possible transformations of the sea monster pattern -- I accidentally added an extra character in one of its lines, and because of that my pattern matching algorithm was not matching anything at all...
- Generate all the image tiles with the same size as the sea monster _pattern_ we are trying to match...
- Try to _match_ the pattern against the tiles -- yes, I did indeed use regexps for this...I replaced all the whitespaces in the pattern with `.`s
- Lastly, count all the `#`s in the reassembled image, and subtract `15` times the number of matching sea monsters -- correct, I assumed that there would be no overlapping matches, and I guess I was right

Not the _cleanest_ implementation (lots of hard-coded stuff!), but at that point I was just rushing for the second star -- and believe it or not, today I scored my best placement ever:

Advent of Code: [2020/19](https://adventofcode.com/2020/day/19)

Solution:

- Use input rules to generate a _massive_ regexp -- it took me a couple of hours to realize I could indeed solve this using regexps!
- Match the regexp against the input messags, and count the ones which test positive
- The regexp is created _recursively_
- The regexp for a given rule can be calculated by calculating the regexps of its sub-rules first, and _combining_ them (i.e. `a|b` where `a` is the regexp for the first sub-rule, and `b` is the regexp for the second one)
- The regexp for a given sub-rule can be calculated by _concatenating_ the regexpes of its rules (i.e. `ab` where `a` is the regexp for the first sub-rule, and `b` is the regexp for the second one)
- To make the matching operation more efficient we are compiling the regexp into a scanner first (i.e. `(cl-ppcre:create-scanner regexp)`)
- Part 2 makes two of the input rules recursive, and to avoid my recursive solution to spin forever, I added a `depth` parameter to my MAKE-REGEXP function and decremented it on every recursive call -- and a recursion limit of `20` seems to be enough to generate the right regexp for part 2

PS. My [original solution](https://topaz.github.io/paste/#XQAAAQBcEAAAAAAAAAAUGQimgulVPYrJhMVjyYOkoNMRrSkEDb+VhGpjZScfl0vQffPIveu6zou42QlYi3oXP009ZBKb+73pdKhOT5C+sOCPTrLLxmKoZfx/upwjyRQJVK5QxpWmzVUWY5qy/01i9v9CB49xj+0sI8P96rG17oQR/UE1GaYDQq7CW3x8lQViBxKC0ikxVHqmfbRp7RdQHHBFH3UbsI6Su5ohIHBG4UA9H14+wCjb/qNcyqOQLNlEwX0V8k6JaO24dy2bp/46mg2DlY8nz/WVAcMUGXRZWL6bkK49UKEsediwu46KxfywY5aP/X56cNVSNUEI/CM1TZxuAzw8hZXa237l7P+KP2+tlsHisWpC4LkeKzSIFVSPoSZqALrAHjysHtbirktMiHX3nH2w56zcA0mtHTLWTeU9PyRxKp+UndXzjmlklCRJT5ytgdFJAm/nDgLwe5JdBn1wwMekZEf9yuOGA+I3S7V2e1Pmwhm9LuWjBFAcCabpRLrIgcM16lv1bix8dRVC9l/pnWcME0jJCL6WWAZYoSSDb9TeeduuLH9a14RrHR5x5fK7LIhLVUy7w87lts1yzFkvgwV96z0CndZEluIaqLqiSqtZwcLoqPN3NsAAeSTIFN7hZ2HKAUgUWvtkGV4DXJmTD9MsBGbdM9oPkO7hOE4kD+vL3HFLEIOr5wQPUzLPc3fLZkPJr66RnQN7CuJWddqQaEDf0vdCEMPLA8fKNlUmxl6nJemRYVGFO2YaAWHAMOPqZQ+CKe104YUyB0rTd8MVmBcPsN/jX3P3LfiwSUcnWOOCSV1X5RTMFMnFs+nrD91DTn+inrq3DEuGL3S8nm73l/kN68SA3H4YrhNSz07MUJLrmRzlmvZXoUplaQKiN9DyPMJMXsLpOsSB+iBXOo1/hBmga+cGExX7k4P69Dbg+3J+JINzvwaLRclkrpXkWomgthb5G7/kBd44T+LuquziC7e0sBfFMhJnUyGjmBlsf/G/LCNS+ZjTWf1XIj8XiqhLJmmE/T56I34xPQgnAQlCm3N1+uid2+RQ9Ml/m0Vc0JqFkBM3Cr+7iVEuQIi+/LWDiKzDX1F+XEkp+LpRDzUOjWcFBc2Cmhbg2IkKqd3eytEiQ0QPJZHYtFe5kACz2v1seeU84fGpW+BM11QBn2pLy0tEGoSmnRzuE8Nnk209tXGs2DUhkP13iP07nV1Swdkk9cAR54SbbV0pC+ddPEvznwnigCpV9GRX4Z2N0Sxk7GC6tFRmVYZ4VRtAMEqyL1w9Qs1Y8l7QdJ31F/8jrpo4t6Ad+djOlGRa/ykunLWlu5aoM3wKMRrmbZP/qnzRxaZyDyeOgxlwaU2wActcyKlXvYV7Hjs9I//wCx9Wk8FZvEfcc4lvti3NlF3m3L53CdJCLBpOLc1hZM8Nwn0HI5mFLx5qK6IiXb1LvuK96u7/roJdoqT8HVT2YCCY0vejpFmX8IKj7POD+hYQmj+csMe5Lpu4sjfWwNW/9gB6CGHxWT3lC7D1jUUHgbH3c/FvalIzhj3FdTjAWF3//DZ69g==) implemented the final regexp using a bottom-up approach: start from terminating rules, generate regexps for their parents, then generate regexps for their parents... For part 2 intead, I modified the regexp creator so that, for rule 8 it would output: `(regexp42)+`, while for rule 11 it would output: `((regexp42){1}(regxp31){1}|(regexp42){2}(regxp31){2}|...|(regexp42){10}(regxp31){10})`.
PPS. Clearly I like the recursive solution better!
PPPS. It would be interesting to solve this implementing a [Context-free grammar](https://en.wikipedia.org/wiki/Context-free_grammar) parser.

Advent of Code: [2020/18](https://adventofcode.com/2020/day/18)

Solution:

- Parse each expression into an [S-expression](https://en.wikipedia.org/wiki/S-expression)
- Feed each to EVAL
- Sum the results

I implemented the parsing logic by combining together three different parsers:

- PARSE-OPERATOR, responsible for converting the next available character into a symbol (i.e. `+` or `*`)
- PARSE-OPERAND, responsible for parsing a single digit number, or an _expression_
- PARSE-EXPRESSION, responsible for ... the rest

Clearly the bulk of the work is getting done inside PARSE-EXPRESSION:

- First we parse an operand
- Then an operator
- If the operator needs to be evaluated immediately, then parse another operand and create an S-expression (i.e. `'(rator rand1 rand2)`)
- Otherwise, the rest of the expression needs to be evaluated first, so call PARSE-EXPRESSION recursively, and finally create the S-expression (i.e. `'(rator rand1 expr1)`)
- Repeat

PS. apparently this is the exact same problem the [Shunting-yard algorithm](https://en.wikipedia.org/wiki/Shunting-yard_algorithm) was designed to solve.

I am finally finding myself with some time to clean up some of my recent Advent of Code solutions, so let's have a look at [2020/09](https://matteolandi.net/plan.html#day-2020-12-09) again.

For part 2, given a list of numbers, we were asked to find a sub-sequence such that the sum of its elements would be equal to the solution for part 1.  This is what I came up with back then.

In words:

In code:

Well, it turns out a way simpler solution exists, and it goes like this; given a subsequence (defined in terms of its `start` index, `end` index, and the sum of its elements):

- When `sum` is less than `target`, move the `end` index ahead (and update `sum`)
- When `sum` is greater than `target`, move the `start` index ahead (and update `sum`)
- When `sum` is equal to `target`, then we found our subsequence!

Take care of initialization details, and you should end up with something like this:

Advent of Code: [2020/17](https://adventofcode.com/2020/day/17)

Solution:

- Classic [Conway's Game of Life](https://en.wikipedia.org/wiki/Conway%27s_Game_of_Life) (even the rules were the same); the only difference is that the game evolves in 3 dimensions for part 1 -- cells are cubes! -- and in 4 dimensions for part 2!
- I modeled the game is a set of alive cells, and at each iteration I...
- Get the full list of cells, adjacents to the active ones, without discarding duplicates...
- For each unique cell, count the number of its occurrences (the idea is, if `(x y z)` is mentioned twice, it means two of its adjacents cells are active)
- Use this information (i.e cell position, the number of its neighbors) and the _previous_ cell state, to mark the cell as dead or alive
- PS: Kudos to [Christophe Grand](http://clj-me.cgrand.net/2011/08/19/conways-game-of-life/) for coming up with this nice and concise way of implementing Conway's Game of Life (in Clojure)
- PPS: I was afraid of using LISTs as SETs, so I went on and created a new type, HSET

Advent of Code: [2020/16](https://adventofcode.com/2020/day/16)

Solution:

- Parse rules into LISTs having the name of the rule as first argument, and two _ranges_ as second and third element (a range is just an improper list containing two numbers: the min and max values of the range)
- Parse tickets into ARRAY of numbers
- Part 1
- Create an ARRAY of 1000 elements (all my tickets numbers were smaller than 1000)
- Iterate all the rule ranges and mark each possible value of those ranges as valid
- Iterate all the tickets numbers, and sum the ones which are not valid (i.e the numbers which are not in the array above)
- Part 2
- For each _position_ inside a ticket, pre-calculate the list of _compatible_ fields (e.g. the first position is compatible with the "class" rule, the second is compatible with "row" and "seat" rules)
- Find the mapping using backtracking...
- What fields are compatible with the first first position in the ticket? Pick one...
- What fields are compatible with the second position in the ticket, knowing what we fixed the mapping for the first position? Pick one...
- If you reach a dead end, back-track...
- If you manage to place them all, you found your mapping

All good...except it takes 30 seconds to generate the answer for part 2:

Surely if CL implemented SETs with trees instead of flat LISTs, things would run a bit faster; however, the problem here is that we are trying to create the mapping, in order, from first position to last, while instead we should pick the next position trying to reduce the branch factor (i.e. if there is a position compatible with a single field only, we should try that immediately).

Advent of Code: [2020/15](https://adventofcode.com/2020/day/15)

Solution:

- two HASH-TABLEs
- one to keep track of the last time a given number was spoken
- one to keep track of the second-to-last time a given number was spoken
- for each spoken number:
- if we did not see this before (i.e. the number does not exist in `seen-at-2`), then the next spoken number is `0`
- otherwise, calculate the number _age_ (i.e. `turn-1 - turn-2`), and let that be new new spoken number
- lastly, _rotate_ from one HASH-TABLE to the other: `seen-at-1` into `seen-at-2`, and `turn` (i.e. the current turn) into `seen-at-2`

That's it -- not the most performant solution, but not that astronomically slow either!

Advent of Code: [2020/14](https://adventofcode.com/2020/day/14)

Solution:

- Parse each "mask = ..." input line into a pair of bit-masks: one for all the "0"s, one for all the "1"s
- "mem[...] = ..." lines instead are parsed into pairs containing the location of the memory to update, and the value to write
- Part 1: mask the value before writing it into memory
- To write 0s, we LOGNOT the _zeros_ mask first, and then LOGAND the value to write with this
- To write 1s instead, we simply LOGIOR the result of the previous step with the _ones_ mask
- Part 2: we generate the list of _masked_ addresses, and then update those memory locations. How? A little bit of dynamic programming
- `dp[i]` represents all the _masked addresses_ considering only the first `i` bits of our mask (the least significant ones)
- Base case: `dp[0] = [0]`; knowing `dp[i]`, `dp[i + 1]` can be calculated as follows
- For each element of `dp[i]` -- let's call it `number`
- If `i`-th bit in the mask is 0, then copy the `i`-th bit of the address into `number`, and append the result to `dp[i + 1]`
- If `i`-th bit in the mask is 1, then set the `i`-th bit of `number` to 1, and append the result to `dp[i + 1]`
- Otherwise, append two new values to `dp[i + 1]`: the first, `number` with its `i`-th bit set to 0, the second with its `i`-th bit set to 1
- Note: each step uses the result of the previous step, so we don't need a LIST/ARRAY to store all the intermediary states

Advent of Code: [2020/13](https://adventofcode.com/2020/day/13)

I knew the `x`s in the input were going to be used for part 2, so I decided to _manually_ parse the input and try to solve this directly from the REPL.

If we take the input timestamp and run the modulus of the timestamp and one of the bus periods, we obtain the time, prior to timestamp, the specific bas was last seen at the bus station; to know when the bus will be back again, we need to subtract this number from the bus period.  Do this for all the buses, find the min, and there you have your solution for part 1:

For part 2, as expected, things got really complicated... I immediately tried a _naive_ brute-force solution, but that did not take me anywhere (well, it might have, eventually):

Tried to probe solutions using the _slowest_ bus instead, but that solution too was not converging fast enough:

Then I tried with pen and paper, and after a bit realized that all I was trying to do, was solving the following system of equations:

Searching on DuckDuckGo for "system of modular equations" brought me to this YouTube [video](https://www.youtube.com/watch?v=-hUldZiDUj8) with a very interesting title; I stepped forward a little bit as I had no idea what the guy was talking about, and eventually at [1:38](https://youtu.be/-hUldZiDUj8?t=98) I saw what kind of equation system this theorem is helping you solve, and then I knew that "Chinese Remainder Theorem" was going to help me solve part 2.

I immediately looked for an online solver but the first one I found did not support more than 8 equations, and guess what, our problem had 9!  Luckily, the [next one](https://comnuan.com/cmnn02/cmnn0200a/cmnn0200a.php) did not have such limitation, however, I had to _massage_ my system a little bit before I were able to use the online solver.

First I had to move "time offsets" to the right side of the equation:

Next I had to make all _negative_ values, _positive_, by adding the bus frequencies until the result were positives:

Lastly, convert the above into the solver's _expected_ input:

Click "Calculate", and you should be presented with the following message:

Well, the first number right there, `905694340256752`, would be the solution to your part 2 problem!

PS. I want to come back to this, and _implement_ a proper solution, but not today!

Advent of Code: [2020/12](https://adventofcode.com/2020/day/12)

Solution:

- Use complex numbers to represent the position and the bearing of the ship
- Turning left by 90 degrees means multiplying your bearing by _i_ (i.e. `#c(0 1)`)
- Turning right by 90 degrees means multiplying your bearing by _-i_ (i.e. `#c(0 -1)`)
- Part 1: movement instructions (e.g. `N`, `S`, `W`, `E`) apply to the ship itself (that was a bit confusing at first, that the the ship could [strafe](https://en.wikipedia.org/wiki/Strafing_(video_games)), but whatever)
Part 2: movement instructions apply to the bearing of the ship

Advent of Code: [2020/11](https://adventofcode.com/2020/day/11)

Solution:

- Parse the seating layout into a HASH-TABLE (I thought about using a 1D or 2D ARRAY, but figured the HASH-TABLE would make things a bit easier as I would not have to worry about reading out of bounds positions)
- Seat positions are COMPLEX numbers
- Each step I copy the old state, update it based on the problem rules, return the new state
- If the new and the old state are EQUALP, then we found our end state
- Part 1: for each position, simply count the adjacent ones which are occupied
- Part 2: recursively check in the neighboring direction until we find a `#`, `L`, or get out of bounds

This works, but it's not that _efficient_ (see later), so whenever I get a chance I would like to try to a) cache recursive calls inside IN-SIGHT-OCCUPIED, b) see if [changing how the problem is modeled](http://clj-me.cgrand.net/2011/08/19/conways-game-of-life/) might help or not.

Advent of Code: [2020/10](https://adventofcode.com/2020/day/10)

Solution:

- Part 1
- Sort connectors
- Calculate deltas between adjacents connectors
- Part 2
- Top-down dynamic programming (i.e. recursion + memoization)
- Start from joltage of 0, and call it `p`
- Look at the next adapter `n`: if `n` and `p` differs by less than 3 jolts, then you can...
- Take it, and count all the possible ways you can combine the remaining adapters, knowing that `p` is now `n`
- Or skip it, and count all the possible ways you can combine the remaining adapters, knowing that `p` has not changed
- Stop when there are no more adapters to play with

Alternatively, one could still use dynamic programming but go with a bottom-up approach:

- `dp[n]` represents the solution to our problem, considering only the adapters up until `n`
- Base case, the charging outlet: `dp[0] = 1`
- Transformation function: knowing `dp[0]...dp[n]`, the next value `dp[n + 1]` can be calculated simply by summing together the solutions for the 3 previous adapters, as those are the ones in range (i.e. `dp[n]`, `dp[n - 1]`, and `dp[n - 2]`)

I think I like this last one better!

Advent of Code: [2020/09](https://adventofcode.com/2020/day/09)

Solution:

- Part 1
- Implement a sliding-window HASH-SET of 25 elements
- For each number after the 25th, check if it's valid, and if not, remove the oldest element from the set, and add the current one
- Checking if a number `n` is valid is simple: for each element `x` in the sliding-set, if `n - x` exists in the set as well then `n` is valid
- Part 2
- BFS + prefix sums -- I encoded my state as `(psum . seq)` (e.g. `(15 2 3 10)`)
- For each number in the input, try to add it to each of the current states
- If the sum is greater than the target value, discard it
- if the sum is smaller than the target value, add it to the next set of states to evaluate
- If the sum is equal to the target value, there you have your subsequence

Advent of Code: [2020/08](https://adventofcode.com/2020/day/08)

Solution:

- Instructions are parsed into a plist, e.g. `(:jmp -1)`
- The whole program is an array if instructions -- array, not a list, so I can quickly jump around
- RUN-PROGRAM returns 2 values: the last value of the accumulator, and whether the program exited normally or not
- Part 1: run the program and return the accumulator value
- Part 2: brute force -- toggle instruction, run, on clear exit return the value, otherwise toggle the instruction again and try with the next one

Regarding my 2020/07 solution:

It turns a more efficient solution is to:

- Invert the _bag-x-contains-these-many-bags mappings_ (and get a _bag-x-is-contained-inside-these-other-bags_ mapping)
- Start from `:shiny-gold` and see what's the number of _distinct_ bags you can get to

With this, the solution to part 1 simply becomes: `(length (collect-containing-bags :shiny-gold (invert rules)))`

Advent of Code: [2018/17](https://adventofcode.com/2018/day/17)

Solution:

- Simulation (i.e. let the water spill and see what happens)
- Start from the position of the spring of water and (recursively) try to spill water down, to the left, or to the right
- Base case 1: the position we are at has already been visited
- Base case 2: the position we are at is _below_ the lowest point of the input map
- Mark the current position as _dripping water_ (i.e. `|`)
- Recurse down, and on the way up try to see if any dripping water at the level below can be marked as _still_ (i.e. `~`) -- this is achievede by going left/right, until we reach a block (`#`) or still water
- If the position we just came _up_ from (after we recursed _down_) turns out to be a block or still water, then we recurse to the left or the right, effectively filling up the reservoirs)

Advent of Code: [2020/07](https://adventofcode.com/2020/day/07)

Solution:

- Parse the input into a list of _rules_, where each rule looks like: `(:muted-white ((:posh-chartreuse . 1) (:dim-silver . 1) (:posh-bronze . 4) (:striped-black . 1)))`
- Part 1: For each bag type, recursively unfold its content and see if we can find a `:shiny-gold` bag in it
- Part 2: Starting from the `shiny-gold` bag, recursively unfold its content and count how many bags are in it

Advent of Code: [2020/06](https://adventofcode.com/2020/day/06)

Solution:

- Parse groups of answers using similar logic used for 2020/04 -- a group of answers is a list of list of characters
- Part 1: reduce the answers of each group using UNION to get all the distinct answers
- Part 2: reduce the answers of each group using INTERSECTION to get all the unanimous answers

Advent of Code: [2020/05](https://adventofcode.com/2020/day/05)

Solution:

- Intuition 1: boarding passes are just binary numbers (e.g. 'F' -> '0', 'B' -> '1')
- Intuition 2: seat ids are just the binary numbers mentioned above -- _seat-row times 8 plus seat-col_
- Convert boarding passes into seat IDs
- Part 1: take the max of these IDs
- Part 2: sort the IDs, iterate through them, in pairs, and find the _missing_ value

PS. Of course I did not realize about intuition 1 and 2 until after I got my 2 stars and started reading other solutions on Reddit.  For part 1 I originally used binary search to figure out where the boarding passes would take me to; for part 2 instead, I marked as seen all the seats that I encountered, and then iterated through them again looking for the missing one (i.e. first find a row with at least one used seat, then look for another one that has one free).

Advent of Code: [2020/04](https://adventofcode.com/2020/day/04)

Solution:

- Parse the passports into a plist of fields, skip "cid" ones completely
- Part 1
- Count the passports that have 7 fields (i.e. 14 elements)
- Part 2
- Implement _validators_ for each field type
- Count the number of passports from part1, that also pass these new checks

How to programmatically create keywords in Common Lisp?

All I am trying to do is re-implementing what the _evalutor_ would do when presented with an expression like `:foo`; the thing is, you need to take into account the _reader_ as well, and in particular remember that by default it would STRING-UPCASE all the symbols it reads.

Say you had the following function, responsible for programmatically creating a keyword symbol:

Also say that you wanted to use the generated keyword like this (`name` contains the keyword generated with MAKE-KEYWORD above):

If you did not STRING-UPCASE your input (e.g. `(make-keyword "byr")`), the _evaluator_ would end up comparing symbols with different case (e.g. `:|byr|` and `:BYR`), and because of that none of the CASE clauses would match.

To make things work one would have to:

- Simulate what the _reader_ would do (i.e. `(make-keyword (string-upcase "byr"))`)
- Change CASE clauses to use bars (e.g. `:|byr|`, `:|iyr|`)

Good stuff!

Someone on [StackOverflow](https://stackoverflow.com/questions/211717/common-lisp-programmatic-keyword) suggested to set the value associated with the newly created symbol to the symbol itself, but the [standard](http://www.lispworks.com/documentation/HyperSpec/Body/11_abca.htm) seems to say that this is already automatically done:

Few weeks [ago](https://matteolandi.net/plan.html#day-2020-10-25) I started looking for ways to synchronize my dotfiles / Workspace across multiple computers without being forced to push new changes to the underlying repositories, and I think I might have found a workflow for this.

As I did not particularly like [the way](https://help.dropbox.com/files-folders/restore-delete/ignored-files) Dropbox wants me to tell which directory should be synchronized, and which one should not (mostly because on different OSes the commands to run differ), I started looking for alternatives and stumbled upon `unison`, the file synchronizer ([user manual](https://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html)):

- Has clients for MacOS, Windows, and Linux... check
- Supports ways of ignoring directories... check
- Supports ways of ignoring files... check
- Terminal UI... check

`unison` is mostly meant to keep two roots in sync (i.e. the dotfiles on my laptop always in sync with the dotfiles on my work laptop), but what if I wanted my dotfiles synced with a third machine too?  From the user manual:

Great!

What if that _hub_ node was... Dropbox?! We would get our unsaved changes to automatically propagate _for-free_ (so long as you have Dropbox installed of course).  This is exactly what I tried:

- Clone your dotfiles locally -- as you normally would
- Add your laptop / workstation to your Dropbox account -- so it can sync
- Install `unison` -- it's highly recommended that you run the same version across all your clients, even though I am not 100% sure it's a requirement with this setup
- Use `watch` to periodically fire `unison` and sync up your replicas

That's it! I am still experimenting with this, but it seems to be working.

Few tips if you want to start this journey:

- Don't bother syncing .git directories -- manually clone the repositories on each client and sync the files of the working directory instead
- Try not to sync symbolic links (on MacOS at least), or Dropbox might start abusing of your CPU
- If you tell `unison` to skip links (i.e. `-links false`), it will effectively skip them but still exit with a non-zero value
- `watch` seems to [error out](https://stackoverflow.com/questions/62536396/linux-cli-watch-switch-e-errexit-unexpected-exit-with-command-exit-with-a-n) when the program you told it to run generates more lines of output that the current terminal height, even though its exit code is 0
- Lastly, if you intend to start syncing multiple directories, you might want to create your own `unison` wrapper fixing some of these annoyances, and also containing your favourite settings, common `-ignore` rules -- here is mine

You can then easily "wrap this wrapper" into another script responsible for synchronizing two specific replicas:

And then periodically synchronize replicas as follows:

That's it for today!

Advent of Code: [2020/03](https://adventofcode.com/2020/day/03)

Solution:

- Parse the input into a 2D array
- Start from `row=0,col=0`
- Move as per the given delta, wrapping around when horizontally moving outside of the map
- While doing so (i.e. moving inside the map), count the number of trees you hit

Advent of Code: [2020/02](https://adventofcode.com/2020/day/02)

Solution:

- Parse the input into `(n m ch text)` lists
- Part 1
- count entries for which the number of occurrences of `ch` in `text` is between `n` and `m`
- Part 2
- count the entries for which `text[n] == ch` and `text[m] != ch` or `text[n] != ch` and `text[m] == ch`

Advent of Code: [2020/01](https://adventofcode.com/2020/day/01)

Solution:

- Part 1
- iterate the list of numbers
- for each, see if in the remainder of the list there is one element such that the sum of both is 2020
- Part 2
- iterate the list of numbers
- for each, see if in the remainder of the list there are two elements such that their sum is "2020 minus the currently selected element"

Advent of Code: [2016/24](https://adventofcode.com/2016/day/24)

Solution:

- First precompute the best path between any two sites (i.e. cells with numeric values) of the map -- this is done using A*
- Next run another A* trying to get the robot to visit each site
- The state is codified as the current position of the robot (i.e. which site it's at), and a bitmask representing what other sites have already been visited
- Part1: no heuristic, and return the final cost
- Part2: use the cost to go back to position 0 as heuristic, and return the final cost plus the gost to go back to position 0

Advent of Code: [2016/25](https://adventofcode.com/2016/day/25)

Solution:

- Brute-force
- Use/abuse CL condition system (the new "out" instruction simply SIGNALs the value up, so we can use HANDLER-BIND to inspect the output without unwinding the execution stack)
- For each emitted value
- ...if it's not part of the clock signal sequence, signal an error, and restart the program with the _next_ input (we use HANDLER-CASE here, as we want to unwind the stack and move on)
- ...if it's part of the clock signal sequence, and it's been like that for the last 10 emitted elements (it's an heuristic), then we found our magic input

Advent of Code: [2016/23](https://adventofcode.com/2016/day/23)

Solution:

- Started from the solution of 2016/12
- Made dynamic variables for the instruction pointer and the program being run, so I can easily access them both from the body of the new instruction, `tgl`
- Implement the new instruction, `tgl`, to use `*ip*` to figure out which program instruction to _toggle_, and then update `*program*` accordingly
- Note 1: as the example shows, `jnz` now supports reading the jump offset from a registry, so its implementation needs to be updated
- Note 2: not just its implementation, but it's parser too! I wasted too much time figuring out why my program was looping...and it turns out it was because I forgot to update PARSE-JNZ
- Part 1: set register `a` to `7`, and run the program
- Part 2: set register `a` to `12`, and run the program...and after only a couple of **minutes** it should spit out the corrent answer

Clearly there is a more clever solution to this, especially for part 2, but I did not feel like optimizing my input / implementing a new `mul` instruction (as hinted in the problem description), so I am going to leave that to my future self for now!

Advent of Code: [2016/22](https://adventofcode.com/2016/day/22)

Solution:

- Part 1
- nothing crazy, compare each node with every other one and count the pairs which are _viable_
- Note to future self 1: read the text carefully
- Note to future self 2: read the text carefully
- Note to future self 3: read the text carefully
- Note to future self 4: don't make up any additional constraint
- Part 2
- intuition 1: to move data from disk a to c passing from b, you need to create some space on disk b first, move data from a to b, create some space to disk c, and finally move data from b to c
- intuition 2: you can only move data on disks which are _compatible_ with the whichever disk in your input happens to be unused (what in my solution are called: interchangeable nodes)
- A*: starting from the _target_ node, try to move its data to `0,0` -- the state object keeps track of where the target data is at, and which node is empty
- the cost of moving the target data into one of its adjacents disks is `1` plus the cost it takes to _empty that disk first_
- The cost of emptying a specific disk is implemented with another A* in which we _move_ the empty disk to the target location
- Note: when _moving_ the empty disk, make sure you don't touch the node where the target data is currently located at

Advent of Code: [2016/21](https://adventofcode.com/2016/day/21)

Solution:

- Implement scramble operations (tried to be smart about it, and failed...so please don't be me, do the simplest thing possible)
- Parse the input
- Part1: scramble the input
- Part2: almost stared _inverting_ each function, then noticed there were only `8!` possible inputs to try, so I went on and bruteforced it (i.e. generate all inputs, scramble them, and find the one that's equal to "fbgdceah")

I am not quite happy with how long/verbose the solution turned out to be, but whatever...

Advent of Code: [2016/20](https://adventofcode.com/2016/day/20)

Solution:

- Merge overlapping ranges
- At first I thought about using union-find, but ultimately opted for...
- ...sort ranges (smallest start value first, then smallest end value)
- ...scan the sorted list of ranges and merge the _overlapping_ ones
- Part1: take the smallest non-overlapping range, and return `end + 1`
- Part2: iterate non-overlapping ranges, and start from `4294967295` keep on subtracting the size of the current range

Advent of Code: [2016/19](https://adventofcode.com/2016/day/19)

Solution:

- I thought I could map the _staling_ operation with some mathematical formula, so then I tried the _naive_ approach (i.e. simulate it), and it just worked!
- Create a _circular_ list containing the index associated with each elf
- Keep a pointer to the _next_ element to be removed
- At each iteration remove such element, update the pointer, and repeat until only one elf is left
- Part 1: the _next_ element to be removed is simply the second element of the circular list
- Part 2: we start from the _middle_ of the list (i.e. which elf is sitting _in front_ of...), remove the _next_ element, and update the pointer _accordingly_
- ...if the size prior to the latest removal was odd, then we move our pointer one step forward (to skip the other elf that happend to be sitting in front of ...)
- ...otherwise, we don't update the pointer (i.e. the next element to remove is right after the current pointer)

Advent of Code: [2016/18](https://adventofcode.com/2016/day/18)

Solution:

- Initially thought about solving this using numbers and bit masks, but then opted for the simpler string-based approach
- Nothing crazy with the implementation, except:
- added two extra "." (i.e. gutters) to the input so I won't have to deal the _edges_
- for the logic to decide whether a tile is safe or it's a trap -- thanks to [Karnaugh](https://en.wikipedia.org/wiki/Karnaugh_map) I was able to simplify the original set of rules to: _are left / right chars the same? then it's safe, otherwise it's not_

PS. Even with all these string operations, part2 runs in around around 1.5 second; 8 seconds instead, if we did not apply any Karnaugh magic.

Alright, alright, the waiting is _almost_ over: a couple of weeks ago [Eric Wastl](http://was.tl/) (creator of Advent of Code) [tweeted](https://twitter.com/ericwastl/status/1328254144545763328) that the 2020 [site](https://adventofcode.com/2020) is finally up -- don't get too excited though, for the first problem you will still have to wait until December 1st, midnight time (EST/UTC-5)!

For those of you not yet familiar with this (taken from the site's [about](https://adventofcode.com/2020/about) page):

What do you think?

- Will you participate?  (Yes)
- What programming language would you use? ([Common Lisp](https://github.com/iamFIREcracker/adventofcode) of course)
- Editor / IDE?  ([Vim](https://github.com/iamFIREcracker/dotfiles/tree/master/.vim), the only text editor)

It's going to be fantastic...and brutal at the same time (too many smart cookies here, waking up at 6 am to get ahold of their stars as quickly as possible), but that's the beauty of it!

Speaking of waking up early, it [turns out](https://twitter.com/ericwastl/status/1329683037651673089) they got a DJ to play a live set with a big drop at the exact time the first problem will be revealed, so if you planned on waking up early, or simply happen to live on the right part of Earth, you might want to [tune in](https://t.co/9r8pd95G8v?amp=1).

_In bocca al lupo!_

Advent of Code: [2016/17](https://adventofcode.com/2016/day/17)

Solution:

- BFS
- A state is a combination of the current position, and how we got there (e.g. "RLRLDU...")
- Try to move up, down, left, right if
- ...it's not off the map
- ...the door is open
- To see if a door is unlocked, run md5 of the path so far, and extract the first 2 bytes -- nothing crazy, I simply followed instructions
- Stop when you made it to the bottom-right corner -- for Part 1 at least
- Part 2: BFS + pruning
- ...don't stop when you made it to the bottom-right corner
- ...instead check the size of the path, and then _prune_ the result

Advent of Code: [2016/14](https://adventofcode.com/2016/day/14)

Solution:

- Cache md5 hashes -- you don't want to calculate the same hash over and over again
- Implement the cache with a ring buffer -- you don't want to use a hash-table, as there is no need to keep around previously processed hashes
- Rest is implementing logic for finding triplets, and quintets (done using `cl-ppcre`)

Good, except when we set key-stretching to 2017 as part 2 requires, this implementation takes like _forever_ to generate the _correct_ solution:

Instead of:

- Find triplet char
- For each of of the next 1000 hashes, find one that contains a quintet with that char

What if we pre-calculated all the possible quintet characters, and searched the triplet one inside of it?

Let's run it and see how long it takes:

Well, that's _something_, though it's still taking a bit too much time.

I suspected my dumb `HEXADECIMAL-STRING` might have had something to do with it, so I took a look at [ironclad](https://quickref.common-lisp.net/ironclad.html)'s `BYTE-ARRAY-TO-HEX-STRING` function, and gut the following out of it (did not feel like neither copying that over, in its full length, nor adding an additional dependency):

Run the program again, and:

Not bad, I can live with that!

PS. For the curious ones wondering how badly `HEXADECIMAL-STRING` might have been implemented: very badly (for this use case at least)

Advent of Code: [2016/15](https://adventofcode.com/2016/day/15)

Solution:

- Disk #1 has 5 positions and starts at 4, meaning it will be at position 0 at time: 1, 6, 11, 16...
- It will take the capsure 1 second to get to the first disk, which means the button should pressed at any of the instants above, minus 1 second: 0, 5, 10, 15...
- Disk #2 has 2 positions and starts at 1, meaning it will be at position 0 at time: 1, 3, 5, 7...
- The capsule will take 2 seconds to get to disk #2, so in order for the disk to be at position 0 when the capsule reaches it, is at time: -1, 1, 3, 5...
- For each disk, we can then create _generators_ (i.e. returning all the times the disk will be at position 0)
- We start pulling values out of these, until we find a common value
- Note: start pulling from the generator with the lowest value

Advent of Code: [2016/16](https://adventofcode.com/2016/day/16)

Solution:

- Pretty much do as instructed
- Generate random data using an expandable VECTOR...
- ...pre-load it with the input
- ...at each step append "0"
- ...then walk back to front, appending the opposite of the current element
- Calculate the checksum by _reducing_ adjacents elements, until the length is odd...
- ...do all this on the _same_ array, so we don't waste memory

Advent of Code: [2016/12](https://adventofcode.com/2016/day/12)

Solution:

- Implement the 4 functions, one per each defined instruction (need to be careful to support value and register arguments)
- Parse the input into an array of functions + respective arguments
- Run the _program_ using a LOOP, `ip` starting from 0, and 4 registers...
- At each iteration, fetch the istruction at `ip` position, and execute it (each instruction returns the offset `ip` should be updated with)
- Stop when `ip` is bigger than the input program

Advent of Code: [2016/13](https://adventofcode.com/2016/day/13)

Solution:

- Part 1: A*
- Part 2: BFS, with prune enabled after 50 steps
- State: position we are in (implemented as COMPLEX)
- Neighbor function: try up, right, down, left, if coordinates are not negative, and the they refer to an open space

Changing the message `git` uses when merging branches...is not something you can easily [configure](https://stackoverflow.com/questions/3148863/how-can-i-customize-gits-merge-commit-message); your best bet, is to _override_ it completely.

Place the following somewhere in your `$PATH`

`chmod +x` it, and that's it:

Advent of Code: [2016/11](https://adventofcode.com/2016/day/11)

Solution:

- BFS
- a state contains: the floor the elevator is at, the elements located at each floor
- from a given state, all the _neighbor_ ones can be generated by:
- ...moving the elevator up **or** down
- ...picking 1 **or** 2 items from the current floor (my input contains 5 generators and 5 microchips, so this _naive_ implementation should work just fine)
- ...confirming that no microchip would fry on the floor we are leaving, as well as the one we are getting into
- stop when all the items are at the 4th floor
- Part 2 is the same Part 1, with 4 additional items on the first floor -- and that will sloooooow things down

Easy right?!  Not really, implementing this took me way too long, so let's try to tackle this in steps.  First things first, let's define our _state_ object:

- Two properties, `elevator`, `floors`
- `elevator` is an integer
- `floors` is a LIST containing 4 numbers, bit-sets, each representing which element is currently located at that floor
- we have to deal with 10 items for part 1, and 14 for part 2, so bit-masks of 10/14 bits respectively will get the job done
- in particular, the least significant 5/7 bits will be used for microchips, while the rest for the generators

Previously we said that a state is _valid_ if no microchip at each floor is frying; and again, that translates to:

- No generators are on the given floor, or...
- For each microchip on the floor, its generator is there too

Stop condition: all the items are at the fourth floor... or the fourth floor contains 10 items for part 1 and 14 items for part 2

Let's now try to generate all the neighbor states starting from a _known_ one; again, we said that:

- We can go up, or down
- We can pick one, or two items
- So long as nothing fries the floor that we are leaving
- and nothing fries at the floor we are entering into

Let's add some final plumbing:

It works...

...a bit slow, but it works.  Well, that does not surprise me, as NEIGHBORS is very dumb in what it does -- it blindly moves items around, without trying to immediately prune sub-optimal steps.

Anyway, I am fine with this...for now!

[Codeflows 2020](https://codeflows.io/) qualification round: post-mortem

It was a total disaster: I did not manage to _fully_ finish any of the 6 problems, and ended up scoring 40 points only (I believe 400 points were required to make it to the second round).  I knew I sucked at programming competitions... I just did not know how **badly** I did.

Too many mistakes from my part:

- I took this too lightly: "you have more than 24h to complete this, but we don't anticipate it will take you more than 2 hours" said the email that I received, and since the town where I am living was about to pull another lock-down due to the increased number of COVID cases, I figured I could spend a few more hours outside and start working on this later...in the end, it's just a qualification round, right?!
- I had never used CodeChef before (I did not even have an account when I read the first problem's statement), and it took me a bit of time to get myself acquainted with the platform: _read-from-stdin-and-write-to-stdout_ vs _implement-this-function-that-accepts-these-arguments-and-returns-this-value_ (a la LeetCode), inability to debug failures, _funky_ error messages (see later), lack of commonly available libraries like `SPLIT-SEQUENCE`
- I spent almost an hour trying to figure out why one of my solutions was throwing a [NZEC](https://discuss.codechef.com/t/why-do-i-get-an-nzec/1775), and as am I am writing this, I still have no clue whatsoever of what did I do wrong: I changed my parsers to account for trailing whitespaces in the input (someone suggested it might happen), I changed my input parsing logic to minimize consing, I tried forcing the garbage collector in between runs (I remember I had to do or the Google Code Jam grader would not accept my solution)...but none of these seems to have made any difference
- Kept _switching_ problem the moment I realized the solution I was getting at was not as _straightforward_ as I initially anticipated; this is not new with me (i.e. "it cannot be that complicated, there has to be an easier way..."), and between the clock ticking and the lack of solved problems, I suspect things got even worse as I desperately looked for a low hanging fruit problem with which to build up some confidence
- I was not white-boarding (e.g. pen and paper, Gimp) as much as I should have: "oh, this is easy", I kept saying, and then immediately switched to the editor to hack something up...when clearly I should have spent more time _validating_ the solution, thinking about edge-cases, input constraints, etc.

Let's take a look at the problems, so you can gauge their complexity: the first one, had something to do with an array of integers, and commands that operate over it:

- Increase the values of a given range L-R, by X
- Sum values stored in odd positions of the array
- Sum values stored in even positions of the array

Easy right? Apparently not, as the grader keep on throwing NZECs at me.

In retrospect, one could have implemented this way more efficiently by simply keeping track of the odd/even buckets, and keep them up to date when tasked to increase the values in a given range, but shouldn't the grader have flagged my solution with a different error message in case it run out of memory, or simply took too much time to complete?  I guess we will never know...

With the second problem, you were given an array containing 0s, 1s, 2s, and were asked to find the maximum number of partitions so that the sum of the numbers in each partition would be divisible by 3.  The realization that I had about this problem was that:

- It takes a 0 to make a partition that is divisible by 3
- It takes a 1 and a 2 to make a partition that is divisible by 3
- It takes three 1s to make a partition that is divisible by 3
- It takes three 2s to make a partition that is divisible by 3

I came up with the following recursive solution, but the grader did not seem to like it (another NZEC error):

I am not sure what the grader was complaining about, but I can only speculate that with big values of `s1` or `s2` my recursive solution would very likely exhaust the stack space.

Do we need to solve this iteratively/recursively, or can we solve this mathematically?

- Under the assumption that the fewer elements we use, to create a group, the better, when you have a chance we should create groups with one 1 and one 2 first
- How many of these groups can we create? `min(s1, s2)`
- With the remaining 1s, `s1 - min(s1, s2)`, we can create groups using three 1s each
- With the remaining 2s, `s2 - min(s1, s2)`, we can create groups using three 2s each

This led me to this other more _efficient_ solution:

Unfortunately the grader did not like this either -- this time, the error message was WA (i.e. wrong answer).  I figured my approach was flawed, so I gave up and moved to the next problem.

Before we do that though, did you spot the _silly_ mistake that I had made? I forgot to pass `3` to the second call to `TRUNCATE`, and unfortunately none of my local tests did catch this...

Would the grader like this solution? Hard to say...

The third problem felt more of a mathematical problem, than a programming one: given an array of integers `[A1, A2, ... AN]`, you had to find an array `[B1, B2, ... BN]` such that:

- Each `Bi` is smaller than a very big number
- Each `Ai` divides `Bi`
- Each `Bi` divides `Bi-1 x Bi + 1` (imagine the array is circular, so `Bn+1` is `B1`)

I thought I could manually _solve_ these equations and find the relation between these different constants, but even though I managed to _simplify_ some of these, I did not know how to search for the _correct_ set of values amongst the _possible_ ones, so I gave up on this pretty quickly too.

The fourth problem was about finding two partitions of a binary string (all "0"s and "1"s) such that:

- The first one, is a palindrome (i.e. `s = rev(s)`)
- The second one, is an _antipalindrome_ (i.e. `s = rev(flip(s))`)

I could not immediately _see_ how to solve this, so I tagged this as _too-complicated-for-now_, and moved on...

Fifth problem: you are given the implementation of an inefficient function that, recursively, calculates the **bitwise OR** of the elements of a given array (see later); your task was to permute the input and minimize the total number of function calls.

The function calculates the result starting from the tail of the array and _slowly_ moving to the first element; in particular, the _extra_ recursive call is avoided if `calculate_or(i+1) == A[i]`, so if we want to minimize the number of recursive calls, we would have to arrange elements so that the ones with wider 1s mask come firs.

Anyway, since I had to return the minimum number of function calls, I figured I would start with that:

Next: how could we _smartly_ shuffle the input array to minimize the number of recursive calls?  The first solution that I tried, was to sort elements by the number of raised bits:

The grader did not like it.  What about sorting by most-significant bit first, and then by the number of raised bits?

I am not sure why I thought this one; was I high or something? Anyway, of course the grader did not accept this too.  Lastly, I came up with the idea of solving this with DFS + memoization, but I could not finish this in time:

- Implement a recursive function to return the minimum number of calls required to calculate the bitwise OR (i.e. the solution to the problem), as well as bitwise OR mask
- I used a bitset to keep track of which element of the input array still had to be processed
- Base case: if a call is made with the same `remaining` bit-mask, return the cached value (memoization)
- Base case: when all the elements have been visited, return `(0 0)` -- 0 remaining function calls, 0 is the bitwise OR for the remaining items (none in this case)
- At each step, try to add one of the elements which are not part of our solution already, and see which of these additions minimize the number of recursive calls
- How? Each recursive calls returns the number of remaining function calls, `fcalls`, as well as the bit-mask of all the remaining elements, `or-suffix`; if the currently tried element is equal to `or-suffix` than we would only call the recursive function once, otherwise twice; this means that adding the currently tried element will require `fcalls` or `2 * fcalls` total function calls respectively

This seems to return the **right** value -- for the inputs I tried this with, at least -- however, it took more than a second to output the answer for `#(1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 29)`, so I hardly believe the grader would accept this...

Anyway, the sixth problem? It had something to do with doing some mathematical calculations on a given input array, but I was immediately put off by the double multiplication at the beginning of the problem description, so ended up not spending much time on this -- I bet this was the easy problem I was desperately looking for...

And this was the last one...what an epic fail ;-)

So much for a _reality check_, uh?!

I was having a hard-time figuring out the **name** of one of the running applications on my Mac -- I wanted to create a [shortcut](https://github.com/iamFIREcracker/dotfiles/blob/c46cc374d2053d47a0f6664650786f3af7783fd9/.hammerspoon/init.lua#L35) for it, using Hammerspoon -- and it turns the project's [FAQ](https://www.hammerspoon.org/faq/) page had exactly an entry for people facing this problem:

Advent of Code: [2016/10](https://adventofcode.com/2016/day/10)

Solution:

- Parse input and return a hash table containing all the _bots_
- A _bot_ is a struct containing `id`, `logic` (i.e. low-value-microchip goes to bot/output, high-value-microchip goes to bot/output), `microchips` (i.e. list of microchips in the bot's hands)
- Find the first bot which is _unblocked_ (i.e. has 2 microchips)
- Move microchips to other bots/outputs
- Repeat until there are no more bots which are unblocked

Interesting Rework podcast about PTO policies:

Link: [Take Some Time Off (We Mean it!)](https://share.transistor.fm/s/0000e516)

Vim/vim-sexp were acting _weirdly_ when working on a file that contained the following form:

It turns out the plugin was tripping over the `#\)` literal; I could have used `#\right_parenthesis` instead, but unfortunately that's not a portable solution.

So I asked this on the Lisp Discord server, and one suggestion that came in was:

That's clever, I had not thought about using the compile-time evaluation syntax for this.

Anyway, if you are wondering: yes, that did actually fix my problem, and now Vim is not behaving weirdly anymore -- I am still on the fence whether this looks more readable or not.

Advent of Code: [2016/08](https://adventofcode.com/2016/day/8)

Solution:

- Parse instructions
- Implement the screen as a 2d array, and implement _drawing_ functions not caring much about performance (rotate ones in particular, could be implemented without allocating an extra array for the column/row, but I was too lazy to implement that)
- Run all the drawing instructions.  At the end
- Part 1: count lit pixels
- Part 2: _print_ the screen, and _visually_ OCR it :D

Advent of Code: [2016/09](https://adventofcode.com/2016/day/9)

Solution:

- Part 1: reconstruct the uncompressed message, implementing a recursive descent parser
- when parsing a marker means, one should extract the `size` of the repetition, and the number of `times` the message should be repated -- reconstruct that, and move on
- when parsing _everything else_, simply process until the next marker

- Part 2: as the problem statement suggests, a _naive_ solution would not work with this new version of the format
- The intuition is that we don't really care about the message... we only care about its length
- Recursive solution
- The size a compressed portion (i.e. one starting with a marker), is equal the size (i.e. recursive call) of the message after the marker that needs to be repeated, _times_ the number of times that needs to be repeated
- The size of an uncompressed portion is... well the size of that portion

- This works, and we can easily adapt this solution to work for Part 1 too
- The difference is that for part one, we don't _recurse_ when calculating the length of a compressed area

Advent of Code: [2016/05](https://adventofcode.com/2016/day/4)

Solution:

- Brute-force it
- Let someone else deal with [md5](https://quickref.common-lisp.net/md5.html)
- Check if a hash is _good_ (first 5 characters of the string representation are "0"), then accumulate...
- Part 1: accumulate the 6th character
- Part 2: if 6th character is below "8", write the 7th character on the _right_ spot
- PS: this solution is slow... on my laptop it takes around 40 seconds to run

Advent of Code: [2016/06](https://adventofcode.com/2016/day/6)

Solution:

- Parse input
- Part 1: iterate by columns, run `FREQUENCIES`, and return the most frequent char
- Part 2: use the least frequent char instead

Advent of Code: [2016/07](https://adventofcode.com/2016/day/7)

Solution:

- Parse IPs into splits, where the even ones represent the hypernet sequences
- Part 1
- ... iterate each split (odd splits **might** contain an ABBA, even ones **should not**)
- ... if it **does** contains an ABBA in an odd split, and **not** contain an ABBA in an even one, then count the entry

- Part 2
- ... it's a bit tricker, because there could be multiple ABA inside odd splits, but only one of them might have a BAB in one of the hypernet sequences
- For each ABA inside any of the odd splits, check if the same BAB exist inside any of the hypernet sequences

- This works, but I think we can try and simplify the implementation a bit
- Let's **always** partition splits into _normal_, and _hypernet_ (not just for part 2)
- Part 1: count IPs with an ABBA inside the _normal_ part, and **not** an ABBA inside the _hypernet_ part
- Part 2: count IPs having at least one ABA part inside the _normal_ part, and a complementary BAB inside the _hypernet_ part

Advent of Code: [2016/04](https://adventofcode.com/2016/day/4)

Solution:

- Parse room specs
- Part 1: calculate the frequency of each character in the encrypted name (dashes excluded)
- ...sort frequency tuples by most frequent first (use lexicographical order to break tie)
- ...find the entries for which the order of the most frequent characters matches the letters defined inside the checksum
- ...sum their IDs
- Part 2: [Caesar cipher](https://rosettacode.org/wiki/Caesar_cipher)

Advent of Code: [2016/01](https://adventofcode.com/2016/day/1)

Solution:

- Nothing crazy: start from `#c(0 0)`, heading `#c(0 1)`, and apply each instruction one after the other
- A left rotation is implemented by multiplying `heading` by `#c(0 1)`; a right rotation is implemented by multiplying `heading` by `#c(0 -1)`
- Part 1: apply all the movements, and finally apply `(MANHATTAN-DISTANCE POS 0)`
- Part 2: apply all the movements, _one step at a time_, and when you land on an already seen position, return `(MANHATTAN-DISTANCE DUPLICATE 0)`

Advent of Code: [2016/02](https://adventofcode.com/2016/day/2)

Solution:

- Create a 2d array representing the keypad, and start from `i = 1`, and `j = 1`
- Move the current position until its out of bounds
- Collect the value on the keypad at the end of each single-key instruction
- Part 1: use the standard 3x3 keypad
- Part 2: use the funky shaped keypad, still represented as a 2d array, with some cells marked as _invalid_

Advent of Code: [2016/03](https://adventofcode.com/2016/day/3)

Solution:

- Not much to do, expect for do the needed
- Parse the specs into a tuple
- Part 1: count which spec is valid, i.e. `a + b > c` and `a + c > b` and `b + c > a`
- Part 2: _rotate_ the specs first, then count which ones are valid

On _small_ design differences between Android and iOS platforms (and the importance of sticking with OS specific guidelines):

Source: [Disclosing a Few Thoughts on Facebook’s UI Design](https://daringfireball.net/2020/11/disclosing_a_few_thoughts_on_facebooks_ui_design)

Here is a short CL function to _clear_ the screen (handy when periodically printing a board or something):

Reference: [StackOverflow](https://stackoverflow.com/questions/37774983/clearing-the-screen-by-printing-a-character)

TIL: with [vim-surround](https://github.com/tpope/vim-surround), `cs([` will introduce an additional whitespace when swapping `(` with `[`, while `cs(]` will not.

Finally gave [vim-fugitive](https://github.com/tpope/vim-fugitive)'s `:Gclog` command a try, and I think I am going to stick with it.

Here is a bit of wrapping logic that I built around it:

- The function, `DiffWithMaster()`, returns "master.." when the current branch **is not** "master", or nothing otherwise -- this will come in handy when working on a branch, and willing to list all the commits that have not made it into "master" yet
- The first mapping, `<leader>gl`, runs `:Gclog!` to show the most recent `12` commits _of the current branch_ (i.e. `:Gclog! -12` if on "master", `:Gclog! -12 master..` otherwise)
- The last mapping, `<leader>gL`, _prepares_ a command similar to the one above, except that a) it does not set a limit to the number of commits to show, and b) it waits for you to press enter to run it -- so you can customize it however you want

Finally gave up, and restored some old `*` / `#` mappings that I have -- I cannot stand the position of the cursor jumping around... I usually want to highlight things first, and then jump around using `n` or `N`.

Finally got around to fix some issues with my Javascript's "select-top-level-expression" mapping (previously, it was tripping over when trying to evalute top-level array definitions).

Before:

and after:

I whish I had known about matchit operators before (i.e. `:help [%`).

Paul Graham on [Twitter](https://twitter.com/paulg/status/1314260316134531075) quoted the below a couple of weeks ago, with a comment: "Every startup founder should read this..."

I think I tend to agree with him on this: ultimately, this _ritual_, is meant to keep you on track, focused on what really matters.  However, I am just afraid that, if abused, it would result in _unnecessary_ pressure for both the product, and the development departments.

Yesterday, someone on the Lisp Discord server while talking about [CLOS](https://en.wikipedia.org/wiki/Common_Lisp_Object_System), mentioned a pretty cool **practical** example that I really think might help people undederstand the concept: Mixins.

From the [Mixin](https://en.wikipedia.org/wiki/Mixin) Wikipedia page:

Now jump to the Examples section of that Wikipedia page, and under Common Lisp you should find the followin.

`object-width` is a generic function with one argument that uses the `+` method combination. This combination determines that all applicable methods for a generic function will be called and the results will be added.

`button` is a class with one slot for the button text.

There is a method for objects of class button that computes the width based on the length of the button text. `+` is the method qualifier for the method combination of the same name.

A `border-mixin` class. The naming is just a convention. There are no superclasses, and no slots.

There is a method computing the width of the border. Here it is just 4.

`bordered-button` is a class inheriting from both `border-mixin` and button.

We can now compute the width of a button. Calling `object-width` computes 80. The result is the result of the single applicable method: the method `object-width` for the class `button.`

We can also compute the width of a `bordered-button`. Calling `object-width` computes 84. The result is the sum of the results of the two applicable methods: the method `object-width` for the class `button` and the method `object-width` for the class `border-mixin`.

Pretty neat.

TIL: `git rebase` supports _auto-squashing_ of "squash! ..." and "fixup! ..." commits, and _automatic-stashing_ of local changes.

Add the following to your .gitconfig, and that should be it:

I can finally use [vim-fugitive](https://github.com/tpope/vim-fugitive)'s fixup/squash mappings without `git` getting in the way because my local repository is _dirty_.

Additional reading:

- [automatically stash save/pop changes on git rebase?](https://stackoverflow.com/a/27117335)
- [Auto-squahsiung Git Commits](https://thoughtbot.com/blog/autosquashing-git-commits)

I have been thinking about moving my dotfiles directory into Dropbox, lately, but I am still not sure whether that's a good idea or not.

Let's have a look first, at the problem I am trying to solve.  Too frequently I find myself playing with some config file tweaks on my laptop, then ssh into my work virtual machine expecting these config files to include the changes I was just testing out few minutes ago; except, I never pushed those changes to my Git repository to begin with, so I am not sure how would that work -- for the guest to pick up the changes...automatically.  Anyway, every time this happens, I usually go ahead and either commit the changes on my host, push, go back to the guest and pull, or I simply re-apply the changes, manually; clearly none of the mentioned solutions seems to be ideal, so what if there was a better way to deal with this?  What if I moved my dotfiles repository, inside Dropbox, and only pushed changes to GitHub only when actually ready to do so? (i.e. when I am happy with the config changes I am playing with).

As appealing as this solution might be, one biggest problem I see is making sure it all works across different OSes (i.e. MacOS on my personal laptop, Windows 10 on my work laptop, and Linux/Ubuntu inside VirtualBox).  Now, my config files already have OS specific switches, but what about _supporting_ libraries/binaries? For example, I depend on `js-langserver` as LSP server when editing JavaScript files; currently, I simply `npm install` it, but I don't want its node_modules directory to end up getting uploaded on Dropbox as that will be a waste of space/bandwidth, and most importantly, it will very likely not work (e.g. running `js-langserver` from MacOS won't work if I previously run `npm install` from Linux, or even worse, from Windows/Cygwin).

It seems this solution _could_ work if there was a programmatic way for me to tell Dropbox which files to sync, and which files to ignore.  Well, lucky me, there is indeed a way to [tell Dropbox that](https://help.dropbox.com/files-folders/restore-delete/ignored-files), so I guess the next step would be to figure the list of files/directories to exclude from the sync:

- All the node_modules directories
- All the venv directories -- that's the name I usually use for `virtualenv` directories
- Vim's temp/backup files maybe?
- Something else?

At work, over the weekend we had to deal with an outage of our PROD environment, and here is a summary of what had happened:

- Few weeks prior to the outage, our IT department accidentally disabled one of ours distribution lists (unfortunately, the one we were using to receive notifications about the state of our servers)
- At about the same time, the disk usage patterns of our database server had increased -- interestingly, disk usage was increasing faster than we were able to clean up, with our periodic jobs
- Disk usage gets past the warning threshold, triggering some notifications that we never see because the distribution list got accidentally disabled
- Few more days go by, and we get past the critical threshold; more notifications that unfortunately we never get to see
- Eventually, over the weekend, the server runs out of disk space and pretty much all the services hosted on the server stopped working (in particular, for Neo4j, one of the hosted databases wound up with a corrupted transaction log)

Now, after a bit of fire-fighting we were able to:

- recover the corrupted transaction log and unlock that database
- re-enabled the distribution list used for notifications
- lowered notification thresholds even more (more breathing space, should things ever escalate again)

Still we were wondering if there wasn't something else Neo4j could have done to prevent itself from filling up the disk and paint itself into a corner.  What if Neo4j implemented a mechanism that would put the database instance in read-only mode, when disk usage went above a pre-configured threshold?  Elasticsearch implements [something similar](https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-cluster.html#disk-based-shard-allocation), and I think it would have come in really handy if it had been there for us to use.

I appreciate it should be responsibility of whoever manages the server that the server itself never runs out space; but bad things happen, and if a service, Neo4j in this case, was able to monitor the situation and defensively shut itself down / enter read-only mode, I believe that would have avoided a lot of pain down the line.

Anyway, brought this up with the Neo4j folks, so let's see what they think about this enhancement.

I have been poking around with `winston`'s API lately, mostly to look into some unexpected behaviors where the `File` logger would stop writing in case of uncaught exceptions / unhandled rejections, and here is what I found out.

First things first, `winston` ships with some _transport_ settings that can be used to instruct the logger to deal with (or not) uncaught exceptions, and unhandled rejections:

- `handleExceptions`: tells winston to catch and log uncaught exceptions (e.g. `process.on('uncaughtException', log)`)
- `handleRejections`: tells winston to catch and log unhandled rejections (e.g. `process.on('unhandledRejection', log)`)

Previously, unaware that such API existed, we used to manually deal with this as follows:

But why keep on doing this, if a library you are already linking and using can deal with this on your behalf?  Exaclty, there is no reason, so we immediately got rid of this custom logic.

Now, annother interesting setting worth mentioning, is `exitOnError`; when set to `true`, winston will fire a `process.exit(1)` and cause the whole application to halt (the idea being... something _unexpected_ happened, so better to exit immediately than continuing in an _unknown_ state).  We have been setting this to `false`, but I wonder if we shouldn't stick with the default value instead -- in the end, should something bad happened and because of that our app crashed, the process manager used to keep the app running should immediately restart it.  Also, we still have to deal with the fact that the `File` transport seems to be shutting itself down in case of uncaught exceptions, and whether this is a bug or expected behavior, `exitOnError: true` seems to be the only workaround available (at least until winston's maintainers don't get back to us on [this](https://github.com/winstonjs/winston/issues/1855)).

Last point, which unfortunately we haven't got around to implement yet: don't bother with on-disk logging, just do all your logging to standard output, and let the process manager (`docker` in our case), deal with that.

TIL: Express will automatically handle exception thrown inside defined middlewares:

I am not sure why this surprises me, in the end the exception is thrown in stack, so that's the **right** thing to do; somehow I was under the impression that `throw`-ing from within a middleware would result in the _uncaught_ exceptions being triggered, instead I was wrong: Express will take care of it, and convert it into 500 response.

Cool -- again, if you think about, it definitely makes sense.

Source: http://expressjs.com/en/guide/error-handling.html

TIL: you can force a case-sensitive search on vim, by adding `\C` anywhere on the search pattern (`:help \\C`):

Few other small things read inside 'Eloquent JavaScript' which I think are worth a note:

The first was about Node.js, the `fs` module in particular, and the fact that not only it ships with the classical callback-based asynchronous interface and with a sycncrhonous version of it, but that since `Promise`s got hot a while back, the core team decided to ship a new promise-based API, with identical names to the callback-based one, but all bundled inside a `promises` namespace.  What's interesting about it? I don't know... it made me think about how difficult it becomes to keep up with new user needs (e.g. `Promise`s are cool, everyone loves them, so we should add support for them) and at the same time supporting an existing product / API: they could have changed the existing API to be promise-based, but that would have introduced a big regression, so they ended up packaging the new API into a new _namespace_ (of course the new package would be less _discoverable_, but it seems like a good trade-off to me).

HTTP Request Method: [MKCOL](http://webconcepts.info/concepts/http-method/MKCOL) -- never heard of it, which I think it suggests it might not be a widely used HTTP method, but I would definitely add this to my TIL list.

Swapping bindings in JavaScript can nicely be done using [destructuring assignment](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment): `[b, a] = [a, b]`

I was reading [Eloquent JavaScript](https://www.amazon.com/gp/product/1593279507/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1593279507&linkCode=as2&tag=marijhaver-20&linkId=d8642c0457954f03e27c02b0034d0d60) the other night, and learned an interesting and scaring thing about regular expressions:

This happens with both `.exec()` and `.test()`, meaning that further calls to `.test()` will resume searching from `lastIndex` (which will continue to increase each time `test()` returns `true`).

Links:

- [RegExp.prototype.exec()](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/RegExp/exec)
- [RegExp.prototype.test()](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/RegExp/test): scroll to the "Using test() on a regex with the "global" flag" paragraph

TIL: on Vim you can `set number` and `set relative number` at the same time, and have the current line number displayed instead of `0`.

With `set relativenumber`:

With `set number` and `set relativenumber`:

JSON Web Tokens Suck (https://www.youtube.com/watch?v=JdGOb7AxUo0)

Stateful JWT
 
- All the user information (username, first last names, email) are stored in the JWT
- Server receives token, validates it, reads it, and uses the information to reply back to the user
 
Stateless JWT
 
- We only store a Session-ID inside the JWT
- Server receives token, validates it, looks up the session (DB, cache, whatever), then uses the information to reply back to the user
 
Session cookies
 
- Cryptographically signed session identifier stored in a cookie.  Data is stored server-side, and retrieved from a database
- Pretty much similar to Stateless JWT
 
What's the difference?
 
- Encoding
- One uses JSON as data format, the other just sends the session ID as a plain string
 
Cookies:
 
- HTTP headers
- Key/value storage
- Limited in size (4kb)
- Server uses `Set-Cookie` header to set cookies on the client (e.g. `session=signed(12345)`)
- Flag `HttpOnly`: prevents user code (Javascript) from accessing cookies
- Flag `SameSite=strict`: prevents cross-site request forgery
- Flag `secure`: don't store this date unless we talking on SSL
 
Local storage:
 
- Browser based API to implement key/value store
 
Myths about JWT:
 
- JWTs are easier to use (than Session cookies): JWTs actually require additional libraries, while session cookies are nowadays supported by all the web servers/frameworks around
- JWTs are more flexible: actually, anything you can define in a JWT, you can also define as a session cookie (the payload would even be more succinct, resulting in less bandwidth usage)
- JWTs are more secure: again, both cryptographically signed, both can be encrypted, except JWT specification is more complicated, and different libraries support/implement it in different ways.  Session cookies on the other hand, have been battle tested for years, and no vulnerabilities have been found so far, so....
- JWTs don't require "cookie consent" -- false... the law requires to put the notification on your application if you are tracking user behavior
- JWTs prevent CSRF (because JWT are usually stored on local storage) -- well, you can still store JWTs with cookies.  If you are using local storage though, you are are opened yourself up to Cross-site scripting (XSS)
- JWTs are better for cross domain (e.g. authentication against www., docs., apps.domain.com)
- JWTs work better on mobile... NO!  Web authentication is handled by Web browsers, and web browsers work the same whether you are running them from Desktop, or Mobile
- JWTs are more efficient... NO!  Same payload, same cryptographic algorithm... in these circumstances the payload of JWT can be 3x larger
- JWTs are easy to revoke -- false, you have to change your signature key.  You can check check the validity of a token... but then if you need to check against a database/cache, why are you using JWTs to begin with?!
- JWTs are easier to "Scale" -- not really.  It's true, if you implement stateful JWT you don't have to interrogate the database, but then you are opening up to other security attacks; however, session management can nowadays be horizontally scaled quite easily, so the argument is weak.
- JWTs are secure by design: actually they were never meant for web authentication; there is always a tradeoff between security and speed, and unless you verify on the server that tokens are still valid (defeating again the purpose of using JWTs), then it won't be impossible for you to prevent malicious users from doing damage
 
What are JWTs good for?
 
- 1 time redirect: pay for a book on books., receive a link to download the book on download., the link contains the JWT which then the server internally validates (the JWT is short lived in this case)
- Resetting passwords

TIL: in Vim, you can disable/enable spell-check based on syntax (`:help spell-syntax`)!

Worse is better: http://dreamsongs.com/WorseIsBetter.html

Martin Fowler's essay about [Collection Pipeline](https://www.martinfowler.com/articles/collection-pipeline/) never gets old; should probably come back and re-read it more frequently.

Lately, I have been exploring the codebase of the product I am involved with at work, looking for repetitive usage patterns.

One in particular that caught my attention, had something to do with [feature toggles](https://www.martinfowler.com/articles/feature-toggles.html):

_Is a given feature X, toggled on for the logged in user? If so, show this area of the screen, otherwise, hide it or show something else instead_

This is how we have been handling this (we use Angular):

- Get the `FeatureToggleStore` injected in the controller of the current screen
- Store somewhere on the controller if the given feature is on/off for the logged in user
- Use that flag inside the template to show/hide (read: `*ngIf`) certain areas of the screen

If you think about it, what we really want is a special [structural directive](https://angular.io/guide/structural-directives), similar to `*ngIf`, that instead of evaluating the input expression and expecting it be either truthy or falsey, it would check that feature against our store, and then manipulate the DOM accordingly.

Easy right?! Let's take a stab at this:

Expected usage:

This looks good.  However, the implementation has some problems:

- What if the name of the feature is dynamically updated, and user has access to the new one too? This solution will cause inner part of the DOM (the one protected by the feature), to be re-rendered again even though nothing has changed (we keep on calling `this.viewContainer.createEmbeddedView()`)
- What if we wanted to support an `else` branch, like `*ngIf` does?

Well, for this, we will have to stand on the shoulders of the [giants](https://github.com/angular/angular/blob/master/packages/common/src/directives/ng_if.ts), and you might end up with something like:

Additional reading: https://juristr.com/blog/2018/02/angular-permission-directive/

Small Javascript utility function to create N-d arrays (_create_, not _initialize_):

- Accepts the size of the outer layer, and the sizes of the inner ones (if any)
- Recursive solution
- ...when on the last layer, simply return a new Array, with the expected size
- ...otherwise, create a new array with the expected size, and initialize its elements with a recursive call (i.e. each element would now be initialized with a new (N-1)-d array)

Few pointers on writing **good** commit messages:

- https://chris.beams.io/posts/git-commit/
- https://wiki.gnome.org/Git/CommitMessages
- https://www.conventionalcommits.org/en/v1.0.0/

When in doubt, check what the specific project commit guidelines say (if any).

Great presentation, from Maciej Ceglowski, on how bloated the Web has become -- it's from 2015, but if anything, things have gotten worse since: https://www.youtube.com/watch?v=iYpl0QVCr6U

The annoying thing about HTML emails using CSS magic to convert DIVs into links/buttons, is that when you try and view them with Mutt/w3m, action links would not render correctly; sometimes this is great, there is a reduced risk of phishing attacks, but what if I indeed wanted to click that link?

Two options:

1. Pop Gmail open, and read the email there
2. Configure Mutt/mailcap to use an _external_ browser when explicitly told to

I have been using the former for quite some time, but with the increased influx of HTML email, I have grown tired of it.  Especially because the latter turned out to be pretty simple to implement:

The first entry, is used when _sending an attachment to mailcap_ (pop an email open, press `v` to open the attachment menu, select a text/html entry, and press `m`); the latter instead, is automatically used by Mutt to display HTML emails.

PS. The `& sleep 3` is used to make sure the attachment Mutt does not accidentally deletes the attachment before the _external_ browser has finished processing it.
PPS. Want to use HTML emails? Use semantic web, please... seriously.

TIL: Elasticsearch will enter read-only mode when running out of disk-space

Elasticsearch started acting out today, and logs were littered with the following error messages:

Our database box did run out of space earlier today (well, actually, the disk usage got above a specific threshold), so that would explain Elasticsearch's behavior.  Anyway, free-ing up space and bouncing the service is not going to help; you will indeed have to manually unlock the cluster and restore write accesses:

After this, things should finally go back to normal.

Sources:

- https://selleo.com/til/posts/esrgfyxjee-how-to-fix-elasticsearch-forbidden12index-read-only
- https://discuss.elastic.co/t/forbidden-12-index-read-only-allow-delete-api/110282

TIL: [standard](ttps://www.npmjs.com/package/standard)

Electron - By Javan Makmali, 2016: https://www.youtube.com/watch?v=nwvourv3nSQ

Basecamp 3, released on Web, iOS, Android, and **desktop** (via Electron)

- The prototype was ready in 1 day
- 6 weeks to get it ready to ship
- You finally can CMD/CTRL-TAB and switch to the app (no more a tab within the browser)
- Having your brand on the dock... that's powerful :)
- Inject some CSS to add icons/items to the Window title bar (not the menu bar)
- History menu, to navigate to previous pages
- Remember your last place, and window size

Quick tour how Electron works:

- Main process: C++
- Opening a tab, spawns a new process (**Renderer** process)
- With Electron, Node.js is simply injected into each Renderer, and into the Main process, and they can communicate together, and access the OS
- Electron is... a set of APIs that you can use to build applications, and interact with the OS

Get started:

Communicate back to the main process from the renderer:

Misc:

- You can inject new items in the menubar (big JavaScript object to define items: item -> click -> userland callback)
- You can create create toast notifications
- You don't have to worry about browser compatibility anymore, and you can use all the experimental features that you want (that are supported by Chromium)
- Mutate the browser like normal extensions would do (i.e. high)
- Intercept every request / proxy it / delete cross-origin headers and render stuff in an iframe even if forbidden
- You can inject a blob of css into fetched page (at Basecamp, they just add a new css-class, and keep all the styles remote)
- Persistence: SQLite, LocalStorage, IndexDB
- You can register system wide key commands (activated when the app is running)
- You can register the app as a protocol handler (e.g. basecamp://...)

Ship:

- Facilities to bundle/ship Electron applications
- Sign your application with your name
- APIs for automatic updates (Mac apps are always full-updates, while on Windows, only diffs are sent)

Brave:

- Browser built with Electron + React
- That's how they inspect traffic, and filter out ads
- Open a window, and load a website... simple

The JavaScript That Makes Basecamp Tick, By Javan Makhmali, 2014: https://www.youtube.com/watch?v=mWo3oEwFFzM

Basecamp (2):

- 40 app servers
- 100 total servers
- 1/2 PB file storage
- 1 TB database
- 1 TB caching
- 70 million requests per day
- 50-60ms Rails response times

The Asset Pipeline:

- Tool for compiling, concatenating, and compress asset files

  - desktop.js.coffee.erb -> erb first, then coffee compiler, then javascript...

- Bunch of _require_ comments that bring in assets from somewhere else, and add them to the pipeline
- All of this will later be replaced by webpacker
- You can also configure an `asset_host`, so the generated `<script src.../>` line, will load the asset from there (you will have to manually upload the file on the CDN)

Code structure:

- Lot of small, single-purple, files (see below), mostly to give behavior to elements/group of elements
- Data attributes:J avascript only, not inside CSS (inside CSS, they use class names, and IDs)

- Most of the event handlers, are bound to the `document` element: arguably the slowest thing you can do... but it does not really matter -- the end result is pretty good.  Don't need to add bindings when elements are added to the dom; all the events will eventually get to the `document`, which will then dispatch based on the selector.

Stacker:

- Page stacking UI

- Refreshing the page, will actually change the layout a bit -- no more stacks, just the one you requested (you can still go back though)
- Pages are cached, so going back will first show you the cached page; the page is still getting fetched, but it will replace the current and cached one, only if-changed (304 status)
- Goodbye: DOMContentLoaded.  Hello: page:beforechange, page:change, page:update
- Custom way of registering global events, that enables them to document what the custom event is for -- that will make for easier debugging (they can enter debug mode, and see each handler how long it took to complete)

- Inspired by [pjax](https://pjax.herokuapp.com/)
- Lead to [turbolinks](https://github.com/turbolinks/turbolinks)

Assets reload:

- People are not refreshing their pages very often, so they won't always get the latest version of the JavaScript files

  - Every Rails request set `X-Asset-Paths` where all the assests and their digests are listed
  - On the client, whenever a Ajax request is completed (i.e. `ajaxSuccess`), we would compare these digests with the ones currently loaded, and if different, we would trigger a full page reload

Cache all the things:

- Russian doll caching

  - Each individual element is cached: todo, todolist, project
  - When you change a todo, you will touch the todolist, and the project
  - All these cache entries are invalidated
  - Rebuilding the project page is cheap though, as most of the content is already cached

- There is stuff you cannot cache (e.g. timestamps, edit/delete links -- usually available to the author, for 15 minutes)

  - You cache the complete object (as if an Admin, with all the permissions possible, was looking at it)
  - You use JavaScript to taylor the page to the logged in user
  - `<time data-local="time-ago" datetime="${UTC value}">` that will read the UTC value, and render a localized version of it **after** the page has been rendered
  - `data-creator-id=${ID}` and `data-visible-to="admin creator"` data-attributes in the template, then inside JavaScript

  - of course the same checks ought to be done on the server as well :)

Backbone.js:

- Basecamp is not a backbone app, but it relies heavily on it on certain areas... like the Calendar!
- When there are a lot of interactions, it's better to start doing things on the client

Eco, templating language on the client:

- Coffeescript, ERB, so people are already familiar with it

"Live" page updates:

How to keep 2 pages in sync:

- Polling: each person with an active session, is polling the polling server (Rack app), every 3 seconds
- When I create a comment, Basecamp sends back to me some JavaScript to a) append the new comment to the thread (e.g. `$("section#comments_for_...").append("...")`), b) highlight it (e.g. `$("article#...").highlight();`)
- Redis queue where page updates pushed, and then delivered to users when they are polling; due to the nature of the updates (they go by section/id), if you are not **that** page, nothing will happen

TIL: DevOps folks have [design patterns too](https://medium.com/@karthi.net/8-container-design-patterns-that-you-should-know-970a1d6a594c), like the _ambassador_ pattern, described [here](https://www.ctl.io/developers/blog/post/deploying-multi-server-docker-apps-with-ambassadors/) and [here](https://test-dockerrr.readthedocs.io/en/latest/admin/ambassador_pattern_linking/)

Today I decided to spend some time to scratch one of the itches I have been having lately, when working with CL (Vim + Vlime): closing all the splits except for the current one, the Lisp REPL (terminal buffer), and Vlime's REPL.

When I work on a CL project, I usually arrange my splits as follows:

Well, that's when I start working... few minutes/hours later, it might as well look similar to the below:

So, how can I easily and quickly get from this messy state, to where I started off, with a single file, and the termnial and Vlime REPLs, and Vlime's REPL?  `:only` would unfortunately close all the open splits except for the current one, which would force me to create new splits for the terminal and Vlime REPLs.

I ended up creating the following VimL function:

Which can be summarized as follows:

- Get a hold of the focused split's Window-ID
- Iterate all the splits of the current tab

  - If the current split is **not** the focused one
  - and the loaded buffer does not contain 'vlime' (that will match both my terminal REPL, and Vlime's one)
  - then we should close the split

And that's it!  Wire those mappings in (I like to override `:only` ones) and you should be ready to roll:

Had some troubles updating my brew formulae today:

It seems like my java cask is [unbelievably old](https://github.com/Homebrew/homebrew-cask/issues/58475):

Oh boy, time-zones are a bitch!

Spent the day looking at the different DB-related libraries I am using in my web app (MITO, CL-DBI, and CL-MYSQl) trying to chase down a problem with DATE fields; these fields, even though stored with the **right** value inside the database, once _inflated_, they ended up with an unexpected time-zone offset (in MITO's terminology, _inflated_ is the action of transforming data, after it's read from the database, so it's easier to work with it inside the controller).

Before we dive into the details, let's make it clear I want my web app to store DATE/DATETIME/TIMESTAMP in UTC (everyone should, really)... and here I thought the following SETF statement will get the job done:

It all starts with the _model_ trying to save a date object; it reads it as string from the request, converts it to a `local-time:timestamp`, and pass it down:

MITO will then process the value twice; it will try to _deflate_ it first inside DEFLATE-FOR-COL-TYPE (_deflate_ is the opposite of _inflate_, i.e. make a memory value ready to be processed by the database access layer) -- this step will turn out to be a noop for us, since we are using `local-time:timestamp` already:

Then it will apply some MySQL specific conversions inside CONVERT-FOR-DRIVER-TYPE

This basically converts the `local-time:timestamp` back into a YYYY-MM-DD string:

And this is how the data is actually getting stored inside the database.  Let's have a look now at what happens when we try to read the data back.

I am using a MySQL database, and CL-DBI internally uses CL-MYSQL to actually talk to the database; CL-MYSQl in particular, tries to convert all the DATE, DATETIME, and TIMESTAMP objects into CL [universal time](http://www.lispworks.com/documentation/lw51/CLHS/Body/26_glo_u.htm#universal_time), and it does it with the following function:

Let's apply this function to the value stored inside the database and see whta it returns:

This is what MITO receives, before _inflating_ it; so let's _inflate_ this and see if we get back to where we started:

What?!  That's what I thought too.

The first thing I tried was to change STRING-TO-DATE, and force a UTC offset when invoking ENCODE-UNIVERSAL-TIME:

This is better!  What happened? Basically SETF-ing `local-time:*default-timezone*` changes the behavior of the LOCAL-TIME library, but does not change how built-in date-related functions operate; which means that if the runtime thinks it's getting runned in CEST, then CEST is the time-zone it will try and apply unless instructed not not to.

Alright, it kind of makes sense, but how can we fix this?  Clearly we can't change CL-MYSQL and hard-code the UTC time-zone in there, as everyone should be free to use the library under whichever time-zone the like.  Enters the `TZ=UTC` environment variable.

_Lovely time-zones..._

This is the output:

While I would expect:

Note how `(cl-dbi:with-transaction ...)` and its body should be indented by an additional space

TIL: `cal` can be instructed to display not just the current month, but also surrounding ones, with `-$N` (if `$N` is 3, `cal` will show the current month, the previous, and the next one):

Source: https://drewdevault.com/2020/07/14/March-2nd-1943.html

RailsConf 2016 - Turbolinks 5: I Can’t Believe It’s Not Native! by Sam Stephenson: https://www.youtube.com/watch?v=SWEts0rlezA

Basecamp3:

- 18 months
- 200+ screens
- 5 platforms (desktop web, mobile web, android native, ios native, and email)
- 6 rails devs, 2 android, 2 ios
- built 3 open source frameworks: Trix (editor), Action Cable, and Turbolinks 5

Turbolinks for iOS (or Android):

- Intercepts link-click events, and creates a new view on the stack
- There is a single WebView only, and that's shared by all the windows on the stack (smaller memory footprint)
- You can customize the user agent, and on the backend for example, hide certain areas which would not look good on the APP
- Native (kind-of) app in 10 minutes
- You can go fully native on specific screens -- hybrid approach
- You can create native menus, by simply extracting metadata from the received page

TIL: `git` fixups / autosquashes: https://fle.github.io/git-tip-keep-your-branch-clean-with-fixup-and-autosquash.html

Rails Conf 2013 Patterns of Basecamp's Application Architecture by David Heinemeier Hansson: https://www.youtube.com/watch?v=yhseQP52yIY&list=PL01Ur3GaFSxxOQWCxypbFBqb2s11Yy_N0&index=8

HTML: document based programming, or delivery mechanism?  Google maps vs Blogs (and to some extend, SPAs vs server-side rendered applications, or hybrid applications)

To make things fast:

1. Key-based cache expiration (or generational caching)

  - Model name + id / "new" + last-updated-at (if available)

2. Russian Doll nested caching

  - Comment is inside a post, a post is inside a project
  - When you change a comment, the system automatically touches the parent, then the parent touches its parent... (where "touches" really means update the last-modified-date timestamp)
  - The MD5 of a partial, is included in the cache key, which means every time you update a partial, the new view will be rendered (and cached again); if the partial is not updated, the old, cached value would still be safe to use
  - Templates are inspected, and caches are invalidates based on `render` calls
  - What if you want to show local time?  You add UTC to the template, add `data-time-ago` attribute, inject some JavaScript on the client to display the utc value into local value
  - What if you have admin links (Edit, Delete, Copy, Move) which are only visible to a subset of users?  We cannot access the logged-in user when rendering/caching the view, so a similar solution to the problem above: annotate the link with `data-visible-to`, and then some JavaScript will take care of removing the link which is not visible

3. Turbolinks process persistence

  With Turbolinks, your app could be as fast as the backend is able to serve responses: 50/150 ms?  The experience is great; higher than that, and you are not going to notice much of a difference from a complete page-refresh.

4. Polling for updates

Bit of vim g* niceties:

g8: show the ASCII code of the character under the cursor
g<: see the output of the last command
gF: got to file, and line number (./path/file.js:23) -- handy if you have a stack-trace in a buffer
gv: re-select the last selection
gi: go back to last insert location
gq: wrap command (e.g. break at the specified text-width)

A little bit off-topic from the usual stuff I write about, but I just want to drop here some links to videos about DJ techniques (don't ask why I got into these):

TIL: Ansible won't re-create a container, when you remove one of its ENV variables -- and apparently, that's by design!

Apparently ansible would not recreate the container when ENV variables
are removed, because the condition of the remaining ENV variables still
being set would still hold true.

  https://github.com/ansible/ansible/pull/31340

The work-around, is to inject a dummy ENV variable, and keep on updating
it's value every time we want to force ansible to recreate the container
(for whatever reason).

What?!

This is pretty dope!

TIL: only the Quartz Java scheduler (i.e. the one used by Jenkins)[0] supports the H character to _evenly_ distribute jobs across a defined time range [1]

[0] https://en.wikipedia.org/wiki/Cron
[1] https://stackoverflow.com/a/47302727

Been finally giving [vim-sexp](https://github.com/guns/vim-sexp) a try, and I gotta be honest, I am quite liking it.

I have also been reading about _structural code editing_, and landed on this [SO page](https://stackoverflow.com/a/30178499) about _barfing_ and _slurping_:

That's an alright definition, but when would you actually use it?  Another [answer](https://stackoverflow.com/a/30190612) to the same question tries to shed some light on this:

It all starts to make sense.  Let's now have a look at Tpope's [vim-sexp-mappings](https://github.com/tpope/vim-sexp-mappings-for-regular-people), and in particular what he thought some sane mappings should be for slurpage and barfage:

So going back the example above where the cursor was on the outermost closed paren:

To slurp the next expression in, you would end up pushing the closing paren the cursor is on to right (past to the next element), and the chosen mapping, `>)`, really tries to caption that...

...again it all starts to make sense...

On indenting lisp files with Vim.

First things first, Vim has Lisp mode (`:h lisp`), an that alone should give you good enough indentation for lisp files.

However, Vim's default way of indenting s-expressions is not always perfect, so if you happen to use [Vlime](https://github.com/vlime/vlime) (and if you don't, I highly reccommend that you do), then you can switch to Vlime's `indentexpr` by simply disabling lisp mode (the plugin will do the rest):

Lastly, you can go back to using lisp mode, but tell Vim to use an external program like [scmindent](https://github.com/ds26gte/scmindent) to invoke when indenting s-expressions (make sure `lispindent` is in your `$PATH`):

You might prefer this last approach more, especially when collaborating with others, as it does not rely on a specific conbination of editor / plugin, but on an external tool that others can easily configure in their workflow.

Few final words about Vim `lispwords` (`:h lisowords`), and particular a question that has bugged me for quite some time: do you need to set them up with using Vlime's `indentexpr`, or an external program to indent your lisp files?  Yes, especially if you care for Vim properly indenting s-expressions as you type them: `indentexpr` is only used when in conjunction with the `=` operator (i.e. when manually indenting blocks of code), while `lispwords` are used when typing in new code.

Random quote from a podcast I recently listened to:

Simplified Poor's man yankstack implementation to to use `localtime()` instead of timers.

The idea is pretty simple, everytime you invoke it:

- Take a timestamp
- Check that timestamp another one (buffere variable) representing when the function was last executed
- If the two timestamps are more than 5 seconds apart, it means the user wants to start from register 0, otherwise 1, 2, 3...

Change SendToTerminal (STT), to strip out command prompts (if configured)

Sometimes you just want to _send_ a line like the following one, without worrying about stripping the `> ` bit out of it.

So I changed STT to automatically strip it out for me!

Fucking fixed bash completion for `g`, my `git` alias.

Alright, I think I figured out what I had to do in order to get my CL programs, on Window, to properly output stuff to stdout.  It turns out you have to explicitly tell deploy[1], the system I use do deploy standalone CL applications, that you want your Windwos application to be a _console_ application, or otherwise deploy will go with a GUI application (and GUI applications that don't usually get a standard output to write to).

To do so, we will have to set the feature flag `:deploy-console`, before building the application:

And that's it, your '.exe' program will finally print stuff to stdout, irrespective of the terminal you run it from:

[1] https://github.com/Shinmera/deploy

Run into another problem with Travis-CI the other day; when deploying artifacts to GitHub, it would error out with the following message:

After a bit of digging I finally found this `dpl` issue [1], where the OP says that there were some problems with his password/token; that made me think about the token I had used, and whether I got it right or not (I generate tokens with `cb | travis encrypt`, so what if I accidentally copied something else inthe OS clipboard, overriding GitHub's code?).

The new token turned out to be different from what I had inside my .travis.yml file, so yeah...yet another PEBCAK (even though, the guys at Travis-CI could have logged a better error message!)

[1] https://github.com/travis-ci/dpl/issues/634
[2] https://en.wikipedia.org/wiki/User_error#Acronyms_and_other_names

Did a little bit of debugging as to why **all** my Common Lisp Windows executables were not printing things out on the stdout as expected, and it seems to have something to do with redirection...

I am not sure what's going on here... but at least I narrowed down the problem a bit.  I will try something else during the following days, but I might wind up asking directly to the cygwin mailing list.

Been plaing with `ap` lately, trying to find a _good-enough_ heuristic, but it's really hard.  I even tried with implementing a depth-first-search algorithm, and even though with pruning it converges to a good-enough solution pretty quickly, it won't ever reach the optimum (the search space is simply too vaste).  The solution?  Add a command line switch, `--good-enough`, to tell `ap` to settle for a sub-optimal solution, and to do it ASAP.

To recap:

- Optimal solution: A* without heuristic (might take forever, or even blow up)
- Good enough solution -- best between

  - A* with very naive heuristic (one that can easily overestimate the remaining cost)
  - Bounded DFS -- i.e. one that will stop after having evaluated 50000 states

Previously I had the following in my `.gitconfig`:

Now, and after a bit of fiddling around, I have:

Why?  Because GitLab merge commits can contain `^M` caracters, and those can fuck up the output of `git branch --verbose`.

The solution?  Manually strip carriage returns escapes, and forcibly enable colours -- `git` knows it's output is being piped, so it would turn colors off by default.

This `docker` trick will never get old:

Finally spent some time trying to figure out a solution for `ap` claiming activities too _early_ (i.e. before all their dependencies were satisfied).

I wound up keeping track of when each activity is completed; this way, when worker `w` who has been busy for `t` time tries to claim activity `a`, the algo would check and confirm that all `a` dependencies have been completed before `t` (and if not, it would skip the activity and move to the next one).

It's a bit inefficient at the moment (well, the whole codebase leaves a lot to be desired) but before cleaning that up I need first to figure out a good heuristic; and if I cannot find one, I might as well change how search state are represented, or decide to abandon the project altogether.

Let's see.

Wanted to try and setup some _automatic checkins_ for the team; as people work remotely, I would like to experiment with reducing the number of scheduled meetings, but before implementing that and say, kill every daily standup and have people write their daily status update, I thought we should first give people a place where they could talk about anything, and stay up to date with each other lives (if they want).  So rather than start asking people what they will be working on during the coming week, I thought we should start with something lighter, something social, something like: How was your weeked like?

The task is quite easy: every Monday morning at 8am, have Jenkins fire an email (later published on Teams) to ask people: what have you guys done over the weekend?  People into sharing, would then reply to the thread, or simply read what others have been up to.  Nothing creazy, nothing creepy, just a bit of sharing to make people we work with a bit more interesting.

All right, let's talk implementation:

We have people working from: Jakarta, Noida, Hyderabad, Pisa, Scotland, and New York.  So what that 8am really means here?  Well, ideally we would want people to process this as soon as they get in (i.e. skim through inbox / Teams to see if there is anything critical, then spend a few minutes _sharing_), so the notification needs to be there when Jakarta people get in.

Jenkins lets you easily schedule when jobs need to run (Build Triggers > Build periodically > Schedule), and it supports custom timezones too:

Nothing could have been easier: on a Jenkins job configuration page, Build > Add build step > Execute shell, then copy the following into the 'Command' field (replace `$TO_EMAIL` with the email address associated with the specific MSFT Teams channel):

And that's it, really!

Source: https://twitter.com/_tessr/status/626076327133577216

This never gets old!

Flipped the order of notes in my .plan file...again!

The main reason why switched from _most-recent-last_ to _most-recent-first_ last August, was that I thought that would make it easier for a casual reader to access the most recent entry; however, that made it really difficult for someone, to dump the whole file and read it in chronological order.

Anyway, now that I can create a Feed RSS off my .plan file (see: https://matteolandi.net/plan.xml), there no more need for adding new notes at the top of my .plan file, so I decided to flip the order of my notes to _most-recent-last_.

This is what I last used last August, to reverse the order of all the notes:

It still does not properly support the scenario where a `§` character is being used in a note, but I checked  my plan file before running it, and it's going to be all right.

Ode to [checklists](https://medium.com/javascript-scene/managing-remote-teams-use-checklists-301aae93e7a5):

Good checklists are:

- Short enough to memorize
- Only include the keypoints

For example (quite relevant these days):

- Use soap
- Wet both hands completely
- Rub the soap until it forms a thick lather covering both hands completely
- Wash hands for at least 20 seconds [not included in this study, but we know now it takes at least 20 seconds to break down viral bugs including Coronavirus so I’m putting it here for posterity]
- Completely rinse the soap off

Other examples, closer to the software development industry

Before asking peers to review your pull request, make sure that:

- [ ] Successfully tested on Jenkins
- [ ] Product team has signed off the implemented workflow
- [ ] Bonus: Screenshots/screencast demo included

Before approving a pull request and merging that into master, make sure that:

- [ ] Code is readable
- [ ] Code is tested
- [ ] The features are documented
- [ ] Files are located and named correctly
- [ ] Error states are properly handled
- [ ] Successfully tested on Jenkins

Before pushing a new version out, make sure that:

- [ ] Look into failing tests (if any), and confirm if intermittent
- [ ] Announce on whichever social media you are using, the main features / bugfixes / changes being released

After a successful release, make sure that:

- [ ] Do some smoke-test to confirm it's all good
- [ ] Run any post-release action (e.g. database migration, if not automatic, support tickets updated)
- [ ] Announce on social media that the release has completed successfully
- [ ] Archive completed stories

When adding a new Defefct to the backlog, make sure it includes:

- [ ] Description
- [ ] Steps to reproduce
- [ ] Expected behavior
- [ ] Actual behabior
- [ ] Bonus: Screenshot/video demonstrating the bug
- [ ] Bonus: any additional pre-analysis

I believe we can go on forever, but this seems promising.

Is it possible to implement Basecamp's automatic check-ins with Teams?  I think it is, with some duct tape of course.

- Each Teams channel has an email address associated with it; you send an email to it, and a few seconds later that message would pop up on teams
- A Jenkins job can be configured to run periodically (e.g. every day @ 9am)
- You can can easily send email from the command line as follows: `echo 'body' | mutt -s 'Subject' your.address@foo.com`

So...

1. Gather your Microsoft Teams' channel email
2. Set up your script:

3. Tell Jenkins to run this every Monday morning, at 9am

And that's it!  Everyone, every Monday morning will have a new notification in the specified channel, and could inform the others about their plans for the week.

Another interesting video from the Basecamp guys, on how they use Basecamp...to run Basecamp.  Check it out: https://m.signalvnoise.com/a-live-tour-of-how-basecamp-uses-basecamp-to-run-basecamp/

Home:

- 3 sections: HQ, teams, projects
  - HQ i.e. company space
  - Teams i.e. teams, or departments (how people are organized)
  - Projects i.e. how work is organized
- each of these sections has **tools**
- each person has access to HQ, and only those teams and projects they have been invited to

Tools:

- Message board
  - project/team/company announcements: so when a new joiner is added, they can easily browse past announcements

- Todos
  - Lists (or scopes, or chunks of work)
  - Each list has items
  - An item can:

  - Hill-chart

- Docs & Files

  - Dropbox, Google Drive ...
  - Can create folders
  - Can _color_ document -- should you need some clues

- Campfire

  - realtime chat, built-in

- Schedule

  - project/team/company shared calendar

- Automatic Check-ins

  - scheduled questions sent to everybody in the company
  - Click on someone's name, and it will pull all someone's answers to a specific automatic check-in (it works similarly for other features too)


General:

- Everything is _commentable_
- Almost everything has a deep-link associated with it, so you can share it with anyone, and if they have the right permissions they will be able to see it
- You can leave **boosts** (like reactions, or 16-character-long comments) to messages or to comments
- From each team, or each project, if you scroll down the Tools section, you get access to the **whole** history of the team/project.  Organized stuff at the top (your tools), scroll through history down the bottom
- The same **history** concepts exists for the whole **company**.  There is a "Latest activity" section where you can see what's happening, in realtime, across all the teams, across all the projects
- There is a "My Schedule" section, that lists all the events that you are involved with; same with the Schedule tool, you can get a link and display this information inside your personal Google Calendar, or whatever
- You can open someone's profile, and access all that is on their plate (i.e. all the to-dos currently assigned to them)
- You can open someone's profile, and access all of their activities... not just to-dos, but comments

Basecamp for Basecamp:

- Discuss multiple things in a **team**... but very specific ones inside **projects**
- If what you want to do can be summarized in one to-do item, or a message... then it goes into a team; if not, then it goes into a project
- Pretty much all the **teams** have everybody on it -- very open company.  Only a few teams have a few people only -- mostly for executives to discuss about strategy.
- Tons of projects and they usually last for 1 week or 2 weeks (once completed, you can archive them) For example: every new release of the iOS Basecamp app, has a new project, with to-dos, hill-chart and everything
- They have a project called OUT, with only the Schedule tool turned on, where people tell when they will **not** be working.  The nice thing about the Schedule tool, is that you can import that into Google Calendar, Outlook, iCal.
- Idea pitches are completely managed asynchronously on Basecamp: big writeup on the message board (usually the _deep_ thinking is done by one person), with enough details for programmers to be able to come up with high level estimates, but that's it (too many details, at this stage, are almost a waste of time, especially if the idea does not turn out to be a good one).
- How to manage contractors? 1. create a new company (otherwise they would have access to your HQ) 2. invite them to projects.

HQ:

- Announcements

  - Everyone has to see this stuff

- All Talk

  - Chat-room, social stuff, everyone has access to it

- Dates

  - Company coming/past meetups

- Reference Materials

  - Policies
  - Logos for products
  - National Holidays
  - 5x12s: every month, 5 random people, 1h to talk about stuff which is not work -- all of this is transcribed

- Fan mail

  - Forward mail into Basecamp, so they show up there

- Scheduled check-ins:

  - Every Monday morning: what did you do this weekend?
  - Every month, what are you reading? -- helps building a culture, especially for remote teams

Example project: Hey (a new email platform they are launching):

- 2 develoeprs, but everyone invited to the project
- Tools: Message board, To-dos, Campfire
- All starts with a _shaping-doc_ (read more at: https://basecamp.com/shapeup)

  - high level what the project is about
  - edge cases maybe
  - few low-fidelity mockups
  - the team creates the tasks

- To-dos

  - Mixed to-dos for the programmer and the designer
  - Different scopes (list of to-dos), like 'sign-up flow'

Another example project: 'What Works [2020]' project (one project per year):

- Message board

  - Heartbeats: every team lead, every 6 weeks (they run 6 weeks dev cycles), write about what they have done over the last cycle
  - Kickoffs: every team lead, every 6 weeks, write about what they will be working on
  - Just summaries for the rest of the company to read, and stay up to date
  - One heartbeat / kickoff per team pretty much

- Automatic checkins

  - Every Monday, 9am, what will you be working on this week?  Rough estimate of what we think we will be working on
  - Every day, at 4:30pm, what did you do today?  Not just a list of to-dos... as most of the time, what you are working on does not have a to-do attached.  Own words, 15 minutes tops
  - Managers can stop asking people about updates, but read them instead

- Schedule

  - When 6 weeks cycle start, end

- To-dos

Put together a little script to generate the RSS feed URL given a YouTube page.

YouTube does not include such URL in the HTML page, but it's easy to guess it (thanks to [1]):

Here you go:

[1] https://danielmiessler.com/blog/rss-feed-youtube-channel/

Very interesting (and quite lengthy) Q&A session on remote working, held from the Basecamp guys: https://m.signalvnoise.com/live-qa-on-remote-working-working-from-home-and-running-a-business-remotely/

A new version of Alacritty has been released (0.4.2), so time to do the _dance_:

1. Update the main app:

2. Do the dance

That's it!

Been working on a little tool called `ap`: the activity planner.

You feed to it a list of **activities** (ID, effort, and dependencies), and a list of **people** (ID, allocation, and whether they are working already on a specific activity):

And it will output what it thinks the _best_ execution **plan** is:

Where each line tells:

- The ID of the activity (column 1)
- When _someone_ will start working on it (column 2)
- When the work will be done (column 3)
- Who this _someone_ actually is (column 4)

This also tell us that all the planned activities will be completed after `16.25` days of work.

Now, actual days of work can be converted into calendar days, week-ends can be excluded...

...and with this we can then plot a Gantt chart and I don't know, maybe make some decisions about it.

Finding the optimal execution plan turned to be more complicated than anticipated; in fact, the moment I remove activities pre-allocations from the example above, `ap` would blow up and crash (apparently the search space becomes too large).  _There must be a problem with your implementation_ you might argue, and I would not disagree; the reason why I am putting this into writing, is so I can clarify the problem in my mind (never heard of rubber-ducking before?!).

Anyway, `ap` internally uses A*[1] to find the best execution plan; for the sake of readability, we can say that each state object is just a list of `workers`, where each worker is defined as two fields:

- `been-working-on`: the list of activities completed _so far_
- `free-next`: when the worker will next be available to pick up something else

With this, we can easily project our `target-date` (i.e. when all the in-progress activities will be completed) by simply running the `max` of all the workers' `free-next` values.

But what's the **cost** to move from one state to another?  Well that depends on:

1. The activity itself (i.e. it's `effort`)
2. Who is to claim that activity (i.e. someone with a _high_ `allocation` value, will complete the activity in less time)
3. When all the activities claimed so far will be completed

For example, let's imagine:

- the current `target-date` (before the worker had claimed the new activity) is '13'
- the current worker has been working on for '10' days
- and that it will will take them '5' days to complete the a newly claimed activity

In this case, the _new_ target date (again, _max of all the been-working-on values_) will be '15', so the cost of moving into this new state is `15 - 13 = 2`; if on the other hand `target-date` was '17', then the cost to get into this new state would have been '0' (i.e. the _projected_ target date would not have changed).

So far so good... I hope.

How can we now _speed-up_ things a bit, and suggest A* which states to evaluate first, so that `ap` does not blow up when the search space increases?  That's where the heuristic come into play -- as a remainder, in order for A* to find the optimal solution, the heuristic function has to be _admissible_ [2] i.e. it should never _overestimate_ the cost required to reach the target state.

Let's look at couple of examples:

1. Sum of all the remaining activities' `effort`.  This assumes that all the remaining activities are completed one after the other (and not in parallel), so it's easy to understand how this would end up overestimating the cost remaining.  This heuristic is clearly non-admissible.
2. Sum of all the remaining activities' `effort`, over the number of total `workers`.  This is a bit better from the previous one, as at least it tries to assume that work can actually happen in parallel); however, not **all** of it can actually be done in parallel, so this too is doomed to overestimate under certain circumstances.

Please note that using a non-admissible heuristic does not necessarily implies A* will stop _working_; it will probably find a solution, sometimes even the optimal one, but it really depends on the proble, your input, and how lucky you were.  For example, let's see what happens when we try and use the first heuristic:

With this, `ap` would still return '16.25' as closest completion date, but when I try that without taking pre-allocations into account, it would return '22.5' (clearly a success given that the planner is not blowing up anymore, but the solution found is _sub-optimal_).

Is there an **admissible** heuristic that we can use with this problem?  Have I modelled the problem poorly, and painted myself into a corner?

[1] https://en.wikipedia.org/wiki/A*_search_algorithm
[2] https://en.wikipedia.org/wiki/Admissible_heuristic

Fucking figured out why my `PS1` was breaking input with Alacritty: https://github.com/alacritty/alacritty/issues/3512

It turns out I was using non-printing characters in the prompt... without escaping them!  Hence `bash` was not able to properly calculate the length of the prompt, hence `readline` blew up!

You can read more about escaping non-printing characters, here:
https://superuser.com/questions/301353/escape-non-printing-characters-in-a-function-for-a-bash-prompt

My reg-cycle plugin is not quite working as expected... sometimes you yank some text... then yank something else but when you try to paste what you yanked the first time (`p` followed by `gp`), other stuff will be pasted instead (like text previously deleted).

Few things to look at:

- `:help redo-register`
- https://vim.fandom.com/wiki/Remembering_previous_deletes/yanks

Today I learded, you can quickly setup SSH proxies by adding the following to your ~/.ssh/config file:

By this, when we connect to the server by git push, git pull or other commands, git will first SSH to server.example.com. As the ssh client will check the config file, the above rule makes it set up a proxy by SSH to proxy.example.org and relaying the connection to %h (server.example.com) with port %p (22 by default for SSH) by nc (you need to have nc installed on proxy). This way, the git connection is forwarded to the git server.

And why would this be relevant?  Think about this scenario:

1. Main laptop: decent CPU / memory, connected to the home WIFI, and company VPN
2. Dev laptop: good CPU / memory, connected to the home WIFI, but not to the company VPN (because you know, you don't want to connect and re-enter auth tokens... **twice**)

Well, with this proxy trick setup, you would still be able to access configured internal services (e.g. git) from the dev laptop without it being connected to the company VPN.  Quite handy!

https://www.systutorials.com/git-through-ssh-tunnel-as-proxy/

Something is messing up my bash prompt, when running it inside Alacritty:

1. Open a new instance

The new instance is opened, and the configured prompt is printed:

2. Press `up-arrow` to access the last executed command:

3. Press `ctrl+a` to get to the beginning of the line

Expected behavior: the cursor moves indeed at the beginning of the line

Actual behavior: the cursor stops somewhere in the middle of the line

Note 1: if I now press `ctr-e` (to get to the end of the line), the cursor get past the current end of the line:

Note2: if I hit `ctrl+c` (to reset the prompt), press `up-arrow` again, and start hammering `left-arrow`, it eventually gets to the beginning of the line:

And if I know press `ctrl+e` (again, to get to the end of the line), the cursor does actually move to the end of the line:

I opened a new [ticket](https://github.com/alacritty/alacritty/issues/3512) to the project's GitHub page -- hopefully someone will get back to me with some insights.

Re-set up SSH on my W10 laptop:

1. Re-install: `cygrunsrv`, and `openssh`
2. Open a cygwin terminal, **as-administrator**, and run:

3. Add a Firewall rule to let in all incoming connections on TCP: 22

Note: if you do this on a company's laptop, `sshd` will try and contact the company's AD when authenticating connections, so make sure your laptop is connected to the Intranet.

Links:
- http://www.noah.org/ssh/cygwin-sshd.html
- https://gist.github.com/roxlu/5038729

I have got a bit serious about trying to use `w3m` for web browsing (yeah, I know, I bit ironic coming from me, given that my team is working on a SPA unable to load shit without Javascript enabled).

First things first... mappings!

I am going to change these quite a lot over the following weeks, but these should be enough to get you started using it.  A few gems

- You won't be able to read all the pages you visit inside `w3m`... so when you bump into one, just press `V` (or `M`) to open the current page in a configured external browser
- There is no support for a default search engine (a bit annoying), but given that you can customize the hell out of `w3m`, I was able to work around that with the following: `COMMAND "GOTO /cgi-bin/b1.cgi; NEXT_LINK"`.  This renders the content of cgi script that I created, and moves the cursor to the next link (so I can then press `<enter>`, type anything I want to search for, press `<enter>` to quit editing the text field, press `<tab>` to focus the Submit button, and press `<enter>` again to submit... easy uh?).  Anyway, this is the content of my cgi script (it's a simple wrapper for [bunny1](https://github.com/ccheever/bunny1)):

- Another intersting thing you can do by using a custom cgi script, is opening withing `w3m` the URL saved in the OS clipboard.  How? 1) read the content of the clipboard (assuming it's a URL), 2) tell `w3m` to go to that URL (yes, your cgi script can send commands to `w3m` ):

- This last tip will teach you how to _copy_ the current page URL into the OS clipboard.  We are going to use the `EXTERN` command for this (i.e. invoke an _external_ command and pass the current URL as the first argument) and in particular we will: 1) set `url` to the input URL, 2) print `$url` (without the trailing new-line) and 3) pipe that into [cb](https://matteolandi.net/cb.html) to finally copy it into the OS clipboard.

Few interesting articles I found when setting this all up:

- Bunch of `w3m` related tricks: https://ntmlabs.com/w3m-tricks/
- A vim like firefox like configuration for w3m:
  https://github.com/felipesaa/A-vim-like-firefox-like-configuration-for-w3m

Finally decided to give [Alacritty](https://github.com/alacritty/alacritty) a go, and damn... now I wished I had tried it earlier: scrolling in `vim` inside a `tmux` session is finally fast again!  It supports `truecolors` too, so what else could I ask more?

Well, one thing maybe I would ask for: [support multiple windows](https://github.com/alacritty/alacritty/issues/607).  We can _multi-instantiate_, and that's fine, but those instances would not be recognized as being part of the same group (i.e. multiple entries in the dock, no support for `cmd + backtick`)... and that would make it really hard for people to set up keystrokes to focus a specifc instance of a group (currently with `Terminal.app`, I have a mapping to focus the group, and then then automatically inject: `cmd + opt + 1` to select the first instance of the group, `cmd + opt + 2` for the second...).

There is a `--title`, but Keyboard Maestro would not let me select an application given its title (also, I do want the title of the window to be dynamic, based on the current process...).  There is a `--class` option, but it seems to be working on Linux only... so what else?

Well, after a bit of fiddling I finally found a solution:

It's ugly, I know it, it's a bit like installing the same application twice, with a different name, but who cares?  I mean, scrolling is damn fast now <3

PS. remember to re-sync these '/Applications' directories the next time that an new release of `alacritty` is published.

_Rant against software development in 2020: start_

We added `prettier` to our repo because you know, it feels good not to have to worry about indentation and style; so we linted all of our files (yes, it was a massing changeset), and then carried on.  Except...changesets pushed by different team members looked different from one another, like `prettier` settings were not properly parsed...and yet all of them had their IDEs properly configured.

Well, it turns out 'prettier-vscode', `prettier` plugin for VisualStudio Code, is not picking up '.prettierignore' unless it's in the project working directory: https://github.com/prettier/prettier-vscode/issues/375.  And guess what? Since we have a monorepo, we have different '.prettierignore' files, one per sub-module...so that's why changesets were looking different.

Long story short:

- `prettier` does not support that behavior: https://github.com/prettier/prettier/issues/4081
- 'prettier-vscode' does not want to support that, unless `prettier` support that: https://github.com/prettier/prettier-vscode/issues/375

So yeah, users, go fuck yourselves!

Well, of course there are [workarounds](https://code.visualstudio.com/docs/editor/multi-root-workspaces), but still, `git` works that way, `npm` works that way...why not implement a similar behavior?  I am pretty sure there are reasons, but still...

_Rant against software development in 2020: start_

Few notes on how to implement multitenancy with Elasticsearch:

[shared-index](https://www.elastic.co/guide/en/elasticsearch/guide/current/shared-index.html), i.e. a single index, shared by all the tenants, in which all the documents have a tenant identifer

This approach works, but all the documents for a specific tenant will be scattered across all the shards of the index.  Enters [document routing](https://www.elastic.co/guide/en/elasticsearch/guide/current/routing-value.html):

By specifing 'baking' as routing value, we are basically telling Elasticsearch to always use a single shard...  which one? `shard = hash(routing) % number_of_primary_shards` (not that we care, as long as it's always the same).

Oh, and when searching data (with routing), don't forget to filter by the tenant identifer, or you ill accidentally retrun other tenant's data:

But...can we do better, and have Elasticsearch do the filtering for us?  Yes, [aliases](https://www.elastic.co/guide/en/elasticsearch/guide/current/faking-it.html) to the rescue!

When you associate an alias with an index, you can also specify a filter and routing values:

Now we can use the 'baking' index when indexing, and forget about _routing_:

Similarly, when searching, we can omit the _routing_ parameter, and the filters too!

Next step: see if it's possible to implement ACL so that one user can connect to Elasticsearch and only see their aliases: neither the aliases used by other tenants, nor the big, fat, shared index.

Asking for help, on [reddit](https://www.reddit.com/r/node/comments/fj1zru/best_practices_on_deploying_multitenant/?), on best-practices on how to implement multitenancy Node.js applications:

Interesting article about [Zone.js](https://medium.com/ngconf/deep-dive-into-zone-js-part-1-execution-context-92166bbb957): the dummy implementation is ridiculously simple!

This is how you are expected to use it:

Too bad, the [TC39 proposal](https://github.com/domenic/zones) has been withdrawn!

MacOS Bundle IDs:

Note: this only works if the the application you are querying the bundle ID for, is running.

https://superuser.com/questions/346369/getting-the-bundle-identifier-of-an-os-x-application-in-a-shell-script

English writing lessons:

- Use verb + adverb, not the opposite

- Use 'be experienced with' instead of 'have experience with'
- Don't use 'seem'... be assertive: either one is, or is not!
- Use 'further' instead of 'improve'

TIL: you can pass '60m' to `docker logs --since ...` to get logs of the last hours... I knew how to se data/times with `--since`, and always been doing the math in my head to figure out the correct cut-off date-time value; but being able to `--since 60m` is just... pure gold!

Today I finally got around to toy a bit with MacOS Karabiner-Elements, and customize my configuration even further so that:

- `'` behaves exactly as `<caps>` (i.e. `<ctrl>`-modifier when held down, `<esc>` when tapped)
- `[` behaves exactly as `<tab>` (i.e. _movement_-modifier when held down, `<open-bracket>` when tapped)

What's the deal with these _movement_-modifiers?  Just to give you an idea:

- `<tab> + h` -> `<left>`
- `<tab> + j` -> `<down>`
- `<tab> + k` -> `<up>`
- `<tab> + l` -> `<right>`
- `<tab> + p` -> _paste from clipboard_
- `<open-bracket> + b` -> _one word backward_
- `<open-bracket> + w` -> _one word forward_

For the record, these are the relevant blocks of my karabiner.json file that enabled this:

TIL: when you have an unresponsive SSH connection, you can kill it with `<enter>~.`

Also, you can type `<enter>~?` and get the list of supported escape codes:

https://superuser.com/questions/985437/ssh-escape-key-only-works-when-connection-is-stuck

Convert markdown files to PDF on MacOS:

When we estimate, it is worth considering worst-case scenarios as well as best-case scenarios in order to provide a more accurate estimate. A formula I often use in estimation templates is the following (derived from a book I read a long time ago):

Keep a risk register alongside the estimates
Review the estimates and the risk register at the end of the sprint

Estimating work is never easy. No two tasks are the same, and no two people are the same. Even if they were, the environment (code base) would most certainly not be the same. Getting to a precise estimation of work is almost impossible without doing the work itself.

Source: https://medium.com/swlh/planning-and-estimation-11e59ac1956b

All right, I finally got around to get `sic(1)` up and running on my laptop and I am quite...OK with the result.  Why sic and not irssi, or weechat, you migth ask; I don't know, I guess I just got bored...

Anyway, [sic](https://tools.suckless.org/sic/) stands for simple irc client, and it really lives up to its name:

- let you connect to a server (plain connection, no SSL)
- support `PASS` authentication
- outputs a single stream of messages (yes, all the messages received on the different channels you joined, are just...comingled)

That's it, really.

Suckless tools might seem...lacking at first -- well, I guess they really are -- but there is a reason for that: they usually are highly composable, which means that most of the times you can combine them with other tools (suckless' tools, or unix tools in general) and say implement a feature that was originally missing.

For example, `sic(1)` does only support plaintext connections; not a problem, create a secure TCP connection using `socat(1)` and have `sic(1)` connect to the local relay instead:

Or, `sic(1)` does not support colors, but everyone would agree that a certain level of color does not hurt; easy, pipe `sic(1)`'s output into `sed(1)`, et voila:

Or, you want to store every message ever received or sent? easy, that's what `tee(1)` is for:

Or you can add a typing hisory using `rlwrap(1)`, or on-connect auto-commands (e.g. join #vim) by using a combination of shell pipes, `echo(1)` and `cat(1)`.

Anyway, I guess you got the idea...and if anything, I hope I made a you a bit curious about this whole _compose-all-the-things_ philosophy.

These are the scripts I ended up creating -- feel free to poke around and tell me if anything intersting come into your mind:

- [sicw](https://github.com/iamFIREcracker/dotfiles/blob/master/bin/sicw)
- [sicw-rlwrap](https://github.com/iamFIREcracker/dotfiles/blob/master/bin/sicw-rlwrap)

Say you have an interactive process like a REPL or something; how can you send some data/text to it, before entering in interactive mode, waiting for the user to type anything?  For example: how can you pass some _auto-commands_ like `:j #suckless` and `:j #lisp` to `sic(1)`, so that you don't have to manually type them every time you connect to the server? Note, you still want to be able to manually send messages to the server, after the auto-commands have been sent.

Well, I found the solution somewhere on StackOverflow (unfortunately I cannot find the link to the page anymore):

What this `input` script does, is:

- `echo(1)` its input argument

- Then start reading from stdin (i.e. enter interactive mode)

Clever, isn't it?

The Old Way Using Decorate-Sort-Undecorate

From: https://docs.python.org/3/howto/sorting.html

Spent a good 30 mins trying to find this reference... somehow I remembered it was called Wrap-Sort-Unwrap and Google wasn't returning anything meaningful.  After the fact, I was able to find this in the Python Cookbook Recipes by searching for pack/unpack.

I got tired of the colors of my prompt (probably because the default colors palette used by most of the terminal applications are kind of terrible and I don't want to bother finding new colorscheme), so here is what I am experienting with:

- username: bold (previously pink)
- hostname: cyan / pink (previously yellow / blue)
- path: underline (previously green)

It's definitely less colored as it used to be, and I am pretty sure I will tweak it again over the following days, but let's see if it works

Vim was segfaulting when opening lisp files, and after bisecting my ft_commonlisp `autogroup` I found the culprit:

I dug deeper and found that the line in the plugin that Vim was tripping over, was:

It did not take me long to get to this vim issue: https://github.com/vim/vim/issues/5541, and changing `reverse(range(...))` with a simple `range()` with negative 'stride' did solve the problem for me:

Opened a MR for this: https://github.com/eapache/rainbow_parentheses.vim/pull/12

Finally got around to enhance pmdb.lisp (Poor Man's debugger) to add a few macros to facilitate profiling of slow functions -- not really debugging per-se, I will give you that, but since I did not have a Poor Man's profiler package yet and I wanted to get this done quickly, I figured I could shove it inside pmdb.lisp and start using it (I can always refactor it later).

Anyway, these are the macros that I added:

- DEFUN/PROFILED: a DEFUN wrapper to create functions that, when executed, would keep track of their execution times
- PROFILE: a macro (similar to TIME) to evaluate a given expression and output information about profiled functions (e.g. % of CPU time, execution time, number of calls)

Say you TIMEd an expression and decided you wanted to try and understand where the bottlenecks are; the idea is to replace all the DEFUNs of all the potential bottleneck-y functions, with DEFUN/PROFILED, and then replace TIME with PROFILE.

For example, say you started from something like:

To time the execution time of MAIN, you would probably do the following:

Perfect!  But what's the function that kept the CPU busy, the most?  Replace all the DEFUNs with DEFUN/PROFILED:

Replace TIME with PROFILE, et voila', you now have a better idea of where your bottleneck might be:

It also works with nested function calls too:

Percentages would start to lose meaning here (FUN-5/FUN-4 execution time would be included in FUN-5's one), but still I am quite happy with the overall result.

PS. If you read PCL, you should notice quite a few similarities with the WITH-TIMING macro explained at the end of the book.

I am going to leave it here (another e-learning platform): https://www.edx.org/

Few Lisp book recommendations (in this order):

Got presented with the following info messages this morning, while booting up my dev box:

All right then, let's install them and see what happens:

Reload the virtual box and....

All right, I feel dumb...

For almost one year I have been dreaming of a `WITH-SLOTS` macro to help with structures and not only classes, and today I stumbled upon a piece of Common Lisp code where the author was using `WITH-SLOTS` with a structure.

"That has to be homemade/library macro, right?" I thought.  Well, it turns out `WITH-SLOTS` works with slots, and strucutres use slots too, so I have been waiting all this time.. for nothing.

Let's look at the bright side of this, though: now I can finally use it!

Reference: http://clhs.lisp.se/Body/m_w_slts.htm

EVAL-WHEN is there to tell the file compiler whether it should execute code at compile-time (which it usually does not do for function definitions) and whether it should arrange the compiled code in the compiled file to be executed at load time. This only works for top-level forms.

Common Lisp runs the file compiler (remember we are talking about compiling files, not executing in a REPL) in a full Lisp environment and can run arbitrary code at compile time (for example as part of the development environment's tools, to generate code, to optimize code, etc.). If the file compiler wants to run code, then the definitions need to be known to the file compiler.

Also remember, that during macro expansion the code of the macro gets executed to generate the expanded code. All the functions and macros that the macro itself calls to compute the code, need to be available at compile time. What does not need to be available at compile time, is the code the macro form expands to.

This is sometimes a source of confusion, but it can be learned and then using it isn't too hard. But the confusing part here is that the file compiler itself is programmable and can run Lisp code at compile time. Thus we need to understand the concept that code might be running at different situations: in a REPL, at load time, at compile time, during macro expansion, at runtime, etc.

Also remember that when you compile a file, you need to load the file then, if the compiler needs to call parts of it later. If a function is just compiled, the file compiler will not store the code in the compile-time environment and also not after finishing the compilation of the file. If you need the code to be executed, then you need to load the compiled code -> or use EVAL-WHEN -> see below.

https://stackoverflow.com/a/45683744

All right, replaced a bunch of `(if (< a b) -1 (if (> a b) 1 0))` expressions with `(signum (- a b))`, but I wonder: doesn't a mathematical/cs function exist, do refer to this?  It seems too common as a pattern, not to have an agreed name -- https://www.reddit.com/r/Common_Lisp/comments/eqf061/is_the_following_a_commonknown_mathematicalcs/?

Its name is: three-way comparison, a.k.a. spaceship operator

Figured out how to customize Clozure-CL REPL prompt... it couldn't be easier, could it?!

Finally got around to refactor 2019/15, and fix the +1 issue

The issue was pretty dumb...when reading 2 from the robot I ended up setting oxygen with the current position, and not with the position after the movement!

Thanks to some Reddit folk, I ended up simplifying the solution by implementing a simple dfs to explore the map (no more 5000 ticks random walking)

It feels good!

Couple of TILs (not all today's really, but whatever):

- `:serial T` inside ASDL systesms, make sure that components are compiled in order; otherwise, in case of inter-file dependencies, one is forced to to use `:depends-on`, which is annoying
- you need to run `(ql:update-dist "...")` to download an updated version of a dist, or `(ql:update-all-dists)` to download them all

Fixed xml-mitter#6, added tests support to the project

Fixing #6 was pretty easy; in fact, double quoting WITH-RSS optional
arguments was all we had to do.  Adding unit tests support to the module
on the other end, wound up being not as easy as I initially thought it
would, but still, I am quite happy with the final result.

I split the tests support in 3 different sub-activities:

1) Add a package (and a system) for the tests: `:xml-emitter/tests`
2) Add a Makefile to run the tests

  This turned out to be more annoying than expected:

  - The interactive debugger needs to be disabled when tests fail, or the
  CI job would hang forever
  - The spawn REPL needs to be shut down when tests pass, or again,
  it would cause the CI job to hang forever
  - Certain implementations did not exit with non-0 code when tests
  failed

  And all this needed to be done outside of the testing system (hence in
  the Makefile) becasue I still wanted to leave things interactive when
  people tried to run the tests with `(asdl:test-system ...)`

3) Add a .travis.yml file to test the library with multiple
   implementations

The result:

- Makefile

- .travis.yml

This is it!

Today I installed `roswell` again, because I wanted to test `xml-emitter` with abcl, but somehow it seemed the runtime corrupted:

Googling for the error I stumbled upon this GH issue: https://github.com/roswell/roswell/issues/216, and after nuking ~/.roswell, `ros setup` successfully installed the latest version of sbcl.

I was erroneously trying to use `cl-travis` instead of plain `roswell`.  Why erroneusly?  `cl-travis` uses `CIM`: https://github.com/sionescu/CIM, which turns out to have been deprectated in [2017](https://keens.github.io/blog/2017/01/29/deprecating_cim/).  What's the replacement?  `ros` and similars -- so better directly use `ros` instead.

The command `ros` however won't be available unless you tweak a couple of ENV vars:

Imported yet another trick from SJL, this time to automatically load all the .lisp files conained a directory -- this way I don't have to update aoc.asd everytime I add a new day.

First you define a new class, and then implement the generic method COMPONENT-CHILDREN:

Next, you use `:auto-module` in your components list as follows (2nd line):

TIL, VALUES in Common Lisp, is SETF-able!

Migrated all the mercurial repository from Bitbucket to Github:

https://git-scm.com/book/en/v2/Git-and-Other-Systems-Migrating-to-Git