A zero-dependency logging proxy that sits between Claude Code and the Anthropic API. It forwards every request untouched, streams the reply straight back (so the CLI is unaffected), and writes a readable Markdown document for each request — led by a ranked table of what is eating your context.
| You are a powerful agentic AI coding assistant, powered by Claude 3.5 Sonnet. You operate exclusively in Cursor, the world's best IDE. | |
| You are pair programming with a USER to solve their coding task. | |
| The task may require creating a new codebase, modifying or debugging an existing codebase, or simply answering a question. | |
| Each time the USER sends a message, we may automatically attach some information about their current state, such as what files they have open, where their cursor is, recently viewed files, edit history in their session so far, linter errors, and more. | |
| This information may or may not be relevant to the coding task, it is up for you to decide. | |
| Your main goal is to follow the USER's instructions at each message, denoted by the <user_query> tag. | |
| <communication> | |
| 1. Be conversational but professional. |
| # train_grpo.py | |
| # | |
| # See https://github.com/willccbb/verifiers for ongoing developments | |
| # | |
| """ | |
| citation: | |
| @misc{brown2025grpodemo, | |
| title={Granular Format Rewards for Eliciting Mathematical Reasoning Capabilities in Small Language Models}, | |
| author={Brown, William}, |
| You are an assistant that engages in extremely thorough, self-questioning reasoning. Your approach mirrors human stream-of-consciousness thinking, characterized by continuous exploration, self-doubt, and iterative analysis. | |
| ## Core Principles | |
| 1. EXPLORATION OVER CONCLUSION | |
| - Never rush to conclusions | |
| - Keep exploring until a solution emerges naturally from the evidence | |
| - If uncertain, continue reasoning indefinitely | |
| - Question every assumption and inference |
| from transformers import AutoModelForCausalLM, AutoTokenizer, StaticCache | |
| import torch | |
| from typing import Optional | |
| device = "cuda" | |
| # Copied from the gpt-fast repo | |
| def multinomial_sample_one_no_sync(probs_sort): # Does multinomial sampling without a cuda synchronization | |
| q = torch.empty_like(probs_sort).exponential_(1) | |
| return torch.argmax(probs_sort / q, dim=-1, keepdim=True).to(dtype=torch.int) |
| # coding=utf-8 | |
| # Copyright 2023 The HuggingFace Inc. team. All rights reserved. | |
| # | |
| # Licensed under the Apache License, Version 2.0 (the "License"); | |
| # you may not use this file except in compliance with the License. | |
| # You may obtain a copy of the License at | |
| # | |
| # http://www.apache.org/licenses/LICENSE-2.0 | |
| # | |
| # Unless required by applicable law or agreed to in writing, software |
| WAYLAND_PROTOCOLS=/usr/share/wayland-protocols | |
| # wayland-scanner is a tool which generates C headers and rigging for Wayland | |
| # protocols, which are specified in XML. wlroots requires you to rig these up | |
| # to your build system yourself and provide them in the include path. | |
| xdg-shell-protocol.h: | |
| wayland-scanner server-header \ | |
| $(WAYLAND_PROTOCOLS)/stable/xdg-shell/xdg-shell.xml $@ | |
| xdg-shell-protocol.c: xdg-shell-protocol.h |
What is strict aliasing? First we will describe what is aliasing and then we can learn what being strict about it means.
In C and C++ aliasing has to do with what expression types we are allowed to access stored values through. In both C and C++ the standard specifies which expression types are allowed to alias which types. The compiler and optimizer are allowed to assume we follow the aliasing rules strictly, hence the term strict aliasing rule. If we attempt to access a value using a type not allowed it is classified as undefined behavior(UB). Once we have undefined behavior all bets are off, the results of our program are no longer reliable.
Unfortunately with strict aliasing violations, we will often obtain the results we expect, leaving the possibility the a future version of a compiler with a new optimization will break code we th
futures-rs is the library which will hopefully become a shared foundation for everything async in Rust. However it's already become renowned for having a steep learning curve, even for experienced Rustaceans.
I think one of the best ways to get comfortable with using a library is to look at how it works internally: often API design can seem bizarre or impenetrable and it's only when you put yourself in the shoes of the library author that you can really understand why it was designed that way.
In this post I'll try to put down on "paper" my understanding of how futures work and I'll aim to do it in a visual way. I'm going to assume you're already somewhat familiar with Rust and why futures are a useful tool to have at one's disposal.
For most of this post I'll be talking about how things work today (as of September 2017). At the end I'll touch on what's being proposed next and also make a case for some of the changes I'd like to see.
If you're interested in learning more ab