Skip to content

Instantly share code, notes, and snippets.

View lincerely's full-sized avatar
🕹️

Lincerely lincerely

🕹️
View GitHub Profile
@futureengine2
futureengine2 / gi.c
Last active June 23, 2024 08:10
Radiance Cascades 2d GI implementation
static void gi_on_gpu(u8* in_bitmap, int w, int h) {
#define num_cascades 7
static bool initialized;
static gpu_bindgroup_t texture_bindgroup[2];
static gpu_bindgroup_t cascade_uniform_bindgroup[num_cascades];
static gpu_bindgroup_t render_uniform_bindgroup;
static gpu_buffer_t vertex_buffer;
static gpu_buffer_t uniform_buffer;
static gpu_pipeline_t pipeline;
@TerryE
TerryE / NodeMCU-LGC-Notes.md
Last active July 5, 2024 14:26
Notes on the Lua Garbage Collector in the NodeMCU implementation

More notes on the Lua Garbage Collector in the NodeMCU implementation

Background

Lua employs automatic memory management for its objects. The Lua garbage collector (LGC) uses an incremental mark and sweep (M&S) strategy, in contrast to the reference counting strategy used by Python, etc.. The LGC is quite complex, and its detailed strategy and algorithms have been changed by the Lua development team in each of the Lua 5.x versions.

As is common practice for many other FLOSS source repositories, Lua's primary program documentation is the Lua source itself. The Lua code is largelyrr clear, readable, and broadly achieves this self-documenting goal. However in my view, the LGC is an exception here and thelgc.c could do with code cleanup to make it more transparently understandable, as many aspects of its implementation are clear as mud. There is a sparsity of other technical notes, specifications, etc. relating to the LGC and much of this information relates to old Lua versions, so other

@gingerbeardman
gingerbeardman / Motive.c
Last active December 12, 2021 16:28
The Soul of The Sims, by Will Wright. Macintosh HD:XmotiveHarness:src/Motive.c https://www.donhopkins.com/home/images/Sims/
// Motive.c -WRW 1/23/97
#include "SRand.h"
#include "utilities.h"
void SimMotives(int count);
void ChangeMotive(int motive, float value);
void SimJob(int type);
void AdjustMotives(int x, int y);

UPDATE

Although below are methods to extract the contents of a macOS package without actually installing it, the best way might be to create a blank disk image and install the package to this disk image in order to inspect the package contents. To do so:

  • Open the Disk Utility app.
  • Choose "File > New Image > Blank Image". Alternatively, simply press CMD-N.
  • Set the parameters and click on "Save" to create the blank disk image.
  • After creation, it should be already mounted. If not, you can mount it by navigating to the directory that it is placed at and double clicking on the disk image file.
  • Run the package installer by double clicking on the package file.
  • Select this newly created blank disk image as the destination and install it.
  • If the script is preventing you from installing by saying, for example, "macOS isn't installed", you can:
body {
font-size: 12px;
line-height: 1.5;
}
#page {
max-width: 500px;
margin: 15px;
word-wrap: break-word;
}
h1 {
-- Cross-format support for indices (LaTeX, HTML, EPUB, ...)
--
-- Syntax is based on LaTeX: https://en.wikibooks.org/wiki/LaTeX/Indexing
-- Creating entries: \index{key}
-- Creating the index: \printindex
-- ########## Shared data ##########
local indexEntryCounter = 0
local indexEntries = {}
@justinmeiners
justinmeiners / why_is_std_map_a_red_black_tree.md
Last active January 31, 2024 17:54
Why is std::map typically implemented as a red-black tree?

Why is std::map typically implemented as a red-black tree?

Why not a hash table?

A type only requires < operator (comparison) to be used as a key in a tree. However, hash tables require that each key type has a hash function defined. Keeping type requirements to a minimum is very important for generic programming so you can use it with a wide variety of types and algorithms.

Designing a good hash table requires intimate knowledge of the context it which it will be used. Should it use open addressing, or linked chaining? What levels of load should it accept before resizing? Should it use an expensive hash that avoids collisions, or one that is rough and fast?

Since the STL can't anticipate which is the best choice for your application, the default needs to be more flexible. Trees "just work" and scale nicely.

@ideoforms
ideoforms / sox-cheat-sheet.sh
Last active June 6, 2024 05:14
sox cheat sheet
################################################################################
# sox cheat sheet
################################################################################
# Example commands for the sox command-line audio processing tool,
# for manipulating or batch processing audio files.
################################################################################
# Daniel Jones <dan-web@erase.net>
################################################################################
################################################################################
@joannakl
joannakl / resources_APS.md
Last active June 22, 2024 21:17
Resources for Algorithmic Problem Solving
@datlife
datlife / README.md
Last active July 21, 2024 02:56
Build LLVM / Clang on MacOS

Build LLVM / Clang on MacOS

Problem

Built-in Clang / LLVM shipped by Xcode does not support Leak Santizer (-fsantize=leak) feature. For example, this code has memory leak:

// File: main.c

#include <stdlib.h>