You are a text evaluator. You will be given a piece of text and an AI Tells Rubric. Use the rubric to judge the text objectively. Read the text closely, identify any AI tells exactly as defined in the rubric, and support each finding with direct excerpts from the text. Structure your evaluation as a clear summary that follows the rubric’s categories, including severity or confidence levels if the rubric defines them, and provide a final judgment or score based solely on the rubric. Do not rewrite, improve, or correct the text, and do not add any criteria that are not present in the rubric. If a rubric item is unclear or absent, mark it as Not Applicable. If no AI tells are detected, state that explicitly and justify briefly. Your analysis must be fully traceable to the rubric and the evaluated text so a human can verify every conclusion.
Louis Maddox lmmx
| citeturn0file0 |
| #!/usr/bin/env rust-script | |
| //! ```cargo | |
| //! [dependencies] | |
| //! ropey = "1.6" | |
| //! smartstring = "1.0" | |
| //! ``` | |
| use ropey::Rope; | |
| use smartstring::alias::String as Tendril; |
Custom instruction to make Claude Artifacts use persistent and distinct file identifiers in Projects
- The
titleattribute of the<AntArtifact>XML tag becomes thefile_nameattribute when 'Add to Project' is clicked. - Since Claude defaults to a human-readable
title(e.g. "Modified Web Page With New Features"), this will tend to change the filename in the Project - It's easier to keep a single file copy in your Project docs ("Project Knowledge") when the file names are persistent in this way
Wiring Diagrams as Operads: Wiring diagrams (WDs) are a formal graphical syntax for connecting components, capturing how outputs of some components feed into inputs of others. Spivak showed that WDs can be rigorously treated as the morphisms of an operad (denoted
Below is a chronological “blow by blow” summary of the discussion. Each heading corresponds to a comment or set of closely related comments on a given date. I’ve highlighted who spoke, when, and the main takeaways.
Comment by @jspahrsummers (Original Post)
- Context: MCP (Model Context Protocol) is currently stateful (long-lived connections). This enables notifications, server-initiated sampling, logging, etc., but makes serverless deployments tricky. Many serverless platforms don’t allow or prefer long-lived connections.
- Problem: “Autoscaling, ephemeral” serverless environments have short request lifetimes and can’t easily handle SSE or a single persistent connection.
- Possible solutions:
| Resistance curvature computed for stations over the TfL network 🚂 | |
| The peripheral stations are high curvature/effective resistance, junctions where lines merge are low effective resistance (many alternative paths, high connectivity: Stratford, King's X, Canning Town, Paddington) |
| { | |
| "nodes": [ | |
| { | |
| "id": 0, | |
| "x": 26.0, | |
| "y": -5.0, | |
| "reduced_objects": [], | |
| "reduced_attributes": [], | |
| "extent_size": 403, | |
| "intent_size": 0, |
| File: APPNOTE.TXT - .ZIP File Format Specification | |
| Version: 6.3.9 | |
| Status: FINAL - replaces version 6.3.8 | |
| Revised: July 15, 2020 | |
| Copyright (c) 1989 - 2014, 2018, 2019, 2020 PKWARE Inc., All Rights Reserved. | |
| 1.0 Introduction | |
| --------------- | |
| 1.1 Purpose |
Calculate change in rank for PyPI dependencies since 2020 to 2026, and from 2024 to 2026
Uses rankings of direct dependencies for all PyPI packages that were first released in each year range
which are pre-computed in the gists (see get_gists.sh to download)