This vault follows the llm-wiki-extended pattern — an extension of Karpathy's llm-wiki with PARA organization, idea inbox, action orientation, and bidirectional cross-project knowledge flow.
The core idea: Instead of using RAG (retrieve-at-query-time), maintain a persistent, LLM-curated wiki that sits between raw sources and the user. When you add a source, the LLM doesn't just index it — it integrates it:
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.
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.
| #!/bin/bash -e | |
| echo "🤡 Applying carthage 12 and 13 workaround 🤡" | |
| xcconfig=$(mktemp /tmp/static.xcconfig.XXXXXX) | |
| # For Xcode 12 make sure EXCLUDED_ARCHS is set to arm architectures otherwise | |
| # the build will fail on lipo due to duplicate architectures. | |
| CURRENT_XCODE_VERSION=$(xcodebuild -version | grep "Build version" | cut -d' ' -f3) | |
| echo 'EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_simulator__NATIVE_ARCH_64_BIT_x86_64__XCODE_1200 = arm64 arm64e armv7 armv7s armv6 armv8' > $xcconfig | |
| echo "EXCLUDED_ARCHS__EFFECTIVE_PLATFORM_SUFFIX_simulator__NATIVE_ARCH_64_BIT_x86_64__XCODE_1200__BUILD_$CURRENT_XCODE_VERSION = arm64 arm64e armv7 armv7s armv6 armv8" >> $xcconfig |
| // | |
| // ScrollingStackView.swift | |
| // | |
| // Created by Antonio Nunes on 05/08/2018. | |
| // Copyright © 2018 SintraWorks. All rights reserved. | |
| // | |
| // Permission is hereby granted, free of charge, to any person obtaining a copy | |
| // of this software and associated documentation files (the "Software"), to deal | |
| // in the Software without restriction, including without limitation the rights | |
| // to use, copy, modify, merge, publish, distribute, sublicense, and/or sell |
| import Foundation | |
| struct PushNotification: Codable { | |
| let accessToken: String | |
| let preferredLocale: String | |
| let notificationId: Int64 | |
| let notificationType: Type | |
| let icon: URL | |
| let title: String | |
| let body: String |
Author: Chris Lattner
| import RxSwift | |
| // MARK: - pausable | |
| extension ObservableType { | |
| /** | |
| Pauses the underlying observable sequence based upon the observable sequence which yields true/false. | |
| - parameter pauser: The observable sequence used to pause the underlying sequence. |
When Swift was first announced, I was gratified to see that one of the (few) philosophies that it shared with Objective-C was that exceptions should not be used for control flow, only for highlighting fatal programming errors at development time.
So it came as a surprise to me when Swift 2 brought (What appeared to be) traditional exception handling to the language.
Similarly surprised were the functional Swift programmers, who had put their faith in the Haskell-style approach to error handling, where every function returns an enum (or monad, if you like) containing either a valid result or an error. This seemed like a natural fit for Swift, so why did Apple instead opt for a solution originally designed for clumsy imperative languages?
I'm going to cover three things in this post:
PS: If you liked this talk or like this concept, let's chat about iOS development at Stitch Fix! #shamelessplug
Speaker: David Abrahams. (Tech lead for Swift standard library)
"Crusty" is an old-school programmer who doesn't trust IDE's, debuggers, programming fads. He's cynical, grumpy.
OOP has been around since the 1970's. It's not actually new.
Classes are Awesome
