Tim Kersey tkersey

What is your setup?

Just chat.deepseek.com with prompts adapted from this gist.

Does it work in one-shot or I have to prompt it multiple times?

For the qX_0 variants, they are actually quite straight-forward so deepseek can come up with a correct result in 1 shot.
For the qX_K it's more complicated, I would say most of the time I need to re-prompt it 4 to 8 more times.
The most difficult was q6_K, the code never works until I ask it to only optimize one specific part, while leaving the rest intact (so it does not mess up everything)

Why did you do this?

Relax, I only have one Sunday to work on idea, literally my weekend project. So I tried Deepseek to see if it can help. Surprisingly, it works and it saves me another weekend...

What is your setup?

Just chat.deepseek.com (cost = free) with prompts adapted from this gist.

Does it work in one-shot or I have to prompt it multiple times?

Recently we’ve noticed a number of our clients maintain a backlog of small tasks that are handled separately from their main backlog. These are tasks that should be finished at some point, but will rarely take priority over business-critical features and bugfixes. Often they are bite-sized pieces of work that can be finished in a couple of hours or less: addressing engineering chores, paying off tech debt, and addressing minor bugs. Internally, this separate backlog has earned a catchy name: the snacklog.

When is it appropriate to work on a snacklog task instead of something in the prioritized backlog? After all, developers should be working on things that move the business forward (obviously). Inevitably, though, natural lulls come up in the course of development:

I’ve just finished a big pull request and have some time before my team finishes leaving feedback.
I’m temporarily blocked by a design or product decision.
It’s near the end of the day, and I’d rather work on something small than sta

Carbon Five has embraced emoji in daily written communication. They carry a lot of meaning in a small package, they inject personality and culture into our writing, and they visually stand out on the page as you scan a document. Pull requests are no exception. Love them or hate them, emojis ensure our pull request comments include the intended tone, something easily lost in written communication.

An engineer has only two strong signals to summarize their whole response to a PR: approve or reject. But what about all of the smaller, intermediate comments? Consider prefacing a review comment with different emoji to classify the comment under one of these three categories. (Many thanks to Srinivas Rao for his initial write-up that inspired this strategy.)

Positive, congratulatory comments that give kudos and compliment the author for his or her work. The pull request author is not required to respond to these.

To stick to green emojis:

Basic setup for formalizing elaboration

First attempts

Elaboration is, broadly speaking, taking user-written syntax and converting it to "core" syntax by filling in missing information and at the same time validating that the input is well-formed.

I haven't been fully happy with formalizations that I previously used, so I make a new attempt here. I focus on a minimal dependently typed case.

	import Foundation
	import SwiftUI

	extension View {
	/// Adds introspection to find the parent view controller in the view hierarchy and
	/// makes that view controller available to downstream views in the view hierarchy.
	public func addParentViewControllerIntrospection() -> some View {
	modifier(ParentViewControllerEnvironmentModifier())
	}
	}

	import Testing
	import Combine

	// From https://stackoverflow.com/questions/78892734/getting-task-isolated-value-of-type-async-passed-as-a-strongly-trans/78899940#78899940
	public final class AsyncFuture<Output, Failure: Error>: Publisher, Sendable {
	public typealias Promise = @Sendable (Result<Output, Failure>) -> Void

	private let work: @Sendable (@escaping Promise) async -> Void

	public init(_ work: @Sendable @escaping (@escaping Promise) async -> Void) {

	import Observation

	public protocol _Observable: Observable {
	nonisolated
	func _access<Member>(keyPath: KeyPath<Self, Member>)

	nonisolated
	func _withMutation<Member, MutationResult>(
	keyPath: KeyPath<Self, Member>,
	_ mutation: () throws -> MutationResult

	// Backports the Swift 6 type Mutex<Value> to Swift 5 and all Darwin platforms via OSAllocatedUnfairLock.
	// Lightweight version of https://github.com/swhitty/swift-mutex
	// Feel free to use any part of this gist.
	// Note: ~Copyable are not supported

	#if compiler(>=6)

	@available(iOS, introduced: 16.0, deprecated: 18.0, message: "use Mutex from Synchronization module included with Swift 6")
	@available(macOS, introduced: 13.0, deprecated: 15.0, message: "use Mutex from Synchronization module included with Swift 6")
	public struct Mutex<Value>: @unchecked Sendable {

	import Foundation

	struct TimeoutError: Error {
	}

	extension AsyncThrowingStream.Continuation where Failure == Error {
	func timeoutTask(with interval: TimeInterval) -> Task<Void, Error> {
	let sleepNS = UInt64(interval * 1_000_000_000)

	return Task {