| # ----------------------------------------------------------------------------- | |
| # AI-powered Git Commit Function | |
| # Copy paste this gist into your ~/.bashrc or ~/.zshrc to gain the `gcm` command. It: | |
| # 1) gets the current staged changed diff | |
| # 2) sends them to an LLM to write the git commit message | |
| # 3) allows you to easily accept, edit, regenerate, cancel | |
| # But - just read and edit the code however you like | |
| # the `llm` CLI util is awesome, can get it here: https://llm.datasette.io/en/stable/ | |
| gcm() { |
With custom commands, you are one shortcut away to run commands thanks to the Quick Launch (Ctrl+P, ⌘+P).
Custom commands can be configured in File > Preferences > Custom commands, or by editing the json file custom-commands.json located in AppData/Local/Fork on Windows and ~/Library/Application Support/com.DanPristupov.Fork/custom-commands.json on MacOS.
Please share your own custom commands :)
Fork commands are posted as comments on this gist. Press CTRL+F to search for commands.
by Leonard Ritter leonard.ritter@duangle.com, 2019-05-12
An implementation written in Scopes can be found here
We have the task of distributing IDs to objects in a pool that we can use to look up their contents. We want to ensure that:
As C programmers, most of us think of pointer arithmetic for multi-dimensional arrays in a nested way:
The address for a 1-dimensional array is base + x.
The address for a 2-dimensional array is base + x + y*x_size for row-major layout and base + y + x*y_size for column-major layout.
The address for a 3-dimensional array is base + x + (y + z*y_size)*x_size for row-column-major layout.
And so on.
So the technique is called Shell Mapping and I got the basics from:
Interactive Smooth and Curved Shell Mapping
https://www.cg.tuwien.ac.at/research/publications/2007/JESCHKE-2007-ISC/
The technique as documented starts with Geometry Shaders which is a really bad idea so I kept things simple and did all the pre-processing on the CPU when meshes were imported. These days I'd look at doing it on-demand in a Compute Shader. Preprocessing steps are:
| @echo off | |
| setlocal enableextensions disabledelayedexpansion | |
| (for %%a in (%*) do if exist "%%~a" ( | |
| pushd "%%~dpa" && ( copy /b "%%~nxa"+,, & popd ) | |
| ) else ( | |
| type nul > "%%~fa" | |
| )) >nul 2>&1 |
Papers I like Pt. 1 Papers I like Pt. 2
Let's start meta:
I've been trying to get clarity on to what extent the position-independent data structure tricks in Gob (https://gist.github.com/pervognsen/c25a039fcf8c256141ef0778a1b32a88) are legal or illegal according to the C standard. I always had the impression it would run afoul of strict aliasing or pointer casting restrictions, but I've been digging into the standard, and now I'm no longer so sure. It might be perfectly legal after all?
Here's section 6.3.2.3 on pointer conversions from the C99 draft standard. I'll be referencing the C99 standard throughout this article, but I've verified that the C11 standard hasn't changed in the relevant areas.
"5 An integer may be converted to any pointer type. Except as previously specified, the result is implementation-defined, might not be correctly aligned, might not point to an entity of the referenced type, and might be a trap representation. [56]
6 Any pointer type may be converted to an integer type. Except as previously specified, the result is implementation-defined
| // -------------------------------------------------------------------------------------- | |
| // Atomic singly-linked intrusive list using 128-bits Compare And Swap (AKA: DCAS). | |
| // Keeps a version counter with the list head to prevent the A-B-A problem. | |
| // | |
| // Based on the implementation found in moodycamel.com: | |
| // http://moodycamel.com/blog/2014/solving-the-aba-problem-for-lock-free-free-lists | |
| // | |
| // My implementation uses raw GCC/Clang atomics intrinsics. While in theory | |
| // std::atomic of a struct of exactly 16 bytes and properly aligned could |
| // Here is btree.inl, which is the thing you would write yourself. | |
| // Unlike C++ templates, the granularity of these lightweight templates is at the | |
| // module level rather than the function or class level. You can think of it like | |
| // ML functors (parameterized modules) except that there isn't any static checking | |
| // of signatures (in that respect, it's like C++ templates). In my view, this style | |
| // of parameterized generative modules is generally the better conceptual framework. | |
| // This is a completely valid C file even prior to preprocessing, so during library | |
| // development you can just include this file directly. That is a big win for testing |
