Douglas Creager @dcreager@dcreager.net

Wrote a bit about Swanson's new bootstrap process. h/t to beka_valentine for the suggestion to only let it depend on the Python interpreter and NOTHING ELSE

https://swanson-lang.org/bootstrap/

Wordle 199 5/6

⬜⬜⬜🟨⬜
🟩⬜⬜⬜🟩
🟩⬜🟨⬜🟩
🟩🟩⬜🟩🟩
🟩🟩🟩🟩🟩

I really appreciate how Wordle’s social sharing is just copying some text onto the clipboard for you to paste wherever you want. No requests to log in to any sites, no access to any personal information!

Gotta love an emailed patch series with over 2,000 patches in it 😅

Seriously, though, this is some really great work to clean up the header dependencies in the Linux kernel, resulting in much less wasted duplicated work recompiling the same header content over and over. We usually think of that as a C++ concern, but it can happen in a large C project too!

https://lwn.net/ml/linux-kernel/YdIfz+LMewetSaEB@gmail.com/

Really nice post from apenwarr, starting off ostensibly talking about logfrahhhhj, but quickly getting into really interesting meta discussions about gifts and whatnot: https://apenwarr.ca/log/20211229

Hopefully these examples show how game-changing stack graphs are. And again, this is WITHOUT building any code or configuring any CI jobs.

Right now we only support Python, but more languages are on the way. And it's all powered by an open-source library if you want to play around with it yourself!
https://github.com/github/stack-graphs/

And a reference AFTER the ‘if’ statement can see both, since we can't know which branch of the ‘if’ statement was taken:

A reference IN the ‘else’ branch can only see the reassignment:

And we can track this all correctly! A reference BEFORE the ‘if’ statement can only see the original definition:

Interestingly, this local variable is overwritten later in the function, but only in the ‘else’ branch of an ‘if’ statement:

With precise, we can see all of the places that variable is referenced in the function:

We can now also track local variables and function parameters! Those are MUCH more likely to have overlapping names, so we don't even TRY to resolve those in search-based lookups.

This ‘output_shape’ local variable in Tensorflow is an interesting example:
https://github.com/tensorflow/tensorflow/blob/6140cfcaf039df86de41edbc872a43c2beb440ea/tensorflow/python/ops/parallel_for/gradients.py#L108

With stack graphs, we can see which particular method is being called, even though that means tracking:
- a local variable created by a ‘with’ statement
- whose value comes from invoking a class constructor
- of a class imported from another file

A search-based lookup can only use the name of the method when searching for definitions. That means we show ALL of the methods in your repository with that name:

First, a simple example showing the different between search-based and precise results. Let's look at this call to a ‘request’ method in the requests library:
https://github.com/psf/requests/blob/39d0fdd9096f7dceccbc8f82e1eda7dd64717a8e/requests/api.py#L61