karpathy

LLM Wiki

A pattern for building personal knowledge bases using LLMs.

This is an idea file, it is designed to be copy pasted to your own LLM Agent (e.g. OpenAI Codex, Claude Code, OpenCode / Pi, or etc.). Its goal is to communicate the high level idea, but your agent will build out the specifics in collaboration with you.

The core idea

Most people's experience with LLMs and documents looks like RAG: you upload a collection of files, the LLM retrieves relevant chunks at query time, and generates an answer. This works, but the LLM is rediscovering knowledge from scratch on every question. There's no accumulation. Ask a subtle question that requires synthesizing five documents, and the LLM has to find and piece together the relevant fragments every time. Nothing is built up. NotebookLM, ChatGPT file uploads, and most RAG systems work this way.

peterc

SELECT
  schema_name, rel_name, table_size,
  pg_size_pretty(table_size) AS size
FROM (
  SELECT
    nspname AS schema_name,
    relname AS rel_name,
    pg_table_size(pg_class.oid) AS table_size
  FROM pg_class, pg_namespace
  WHERE pg_class.relnamespace = pg_namespace.oid

lboulard

list of composition keys

https://www.x.org/releases/X11R7.7/doc/libX11/i18n/compose/en_US.UTF-8.html

command line (direct)

$ setxkbmap -option # clear option
$ setxkbmap -model pc105 -layout us -option compose:ralt,caps:ctrl_modifier,shift:both_capslock

mkllnk

#!/bin/sh

set -e

APP_PATH="$HOME/apps/openfoodnetwork"
CURRENT_PATH="/home/openfoodnetwork/apps/openfoodnetwork/current"
SHARED_PATH="/home/openfoodnetwork/apps/openfoodnetwork/shared"
CONFIG_PATH="/home/openfoodnetwork/apps/openfoodnetwork/shared/config"
BUNDLE="$HOME/.rbenv/shims/bundle"
GEM_PATH="/home/openfoodnetwork/.gem"

r00k

#!/bin/sh

# Set up Rails app. Run this script immediately after cloning the codebase.

# Exit if any subcommand fails
set -e

# Copy over configs
if ! [ -f .env ]; then
  cp .sample.env .env

peterhurford

Using py.test is great and the support for test fixtures is pretty awesome. However, in order to share your fixtures across your entire module, py.test suggests you define all your fixtures within one single conftest.py file. This is impractical if you have a large quantity of fixtures -- for better organization and readibility, you would much rather define your fixtures across multiple, well-named files. But how do you do that? ...No one on the internet seemed to know.

Turns out, however, you can define fixtures in individual files like this:

tests/fixtures/add.py

import pytest

@pytest.fixture

franciscoj

Ruby: ivar vs readers

Spoiler alert: Readers win.

1. You don't rely on the instance state.
2. You've better protection againt typos. @ivar might not exist and nothing will fail ivar will complain.
3. They're easier to mock in specs in case you need to.
4. They properly wrap the state so that refactors are easier
5. they can be aliased
6. they can be alias_method_chained

PurpleBooth

Project Title

One Paragraph of project description goes here

Getting Started

These instructions will get you a copy of the project up and running on your local machine for development and testing purposes. See deployment for notes on how to deploy the project on a live system.

Prerequisites

caarlos0

SELECT bl.pid AS blocked_pid,
  a.usename AS blocked_user,
  ka.query AS blocking_statement,
  now() - ka.query_start AS blocking_duration,
  kl.pid AS blocking_pid,
  ka.usename AS blocking_user,
  a.query AS blocked_statement,
  now() - a.query_start AS blocked_duration
FROM  pg_catalog.pg_locks bl
  JOIN pg_catalog.pg_stat_activity a ON a.pid = bl.pid

mikestone14

Pointing a GoDaddy domain to a Heroku app

https://devcenter.heroku.com/articles/custom-domains http://thenomadicfreelancer.blogspot.com/2012/08/pointing-godaddy-domain-to-your-heroku.html

1) Custom Subdomains

For each custom subdomain use domains:add in the Terminal.