今日已更新 73 条资讯 | 累计 31751 条内容
关于我们

标签:#c

找到 25281 篇相关文章

AI 资讯

What actually crosses the React Server Component boundary

Everyone can type "use client" . Almost nobody can say what survives the trip across it — and then something breaks: next build dies at prerender, the error names no file and no import chain, and the prop that killed it was an arrow one level down inside an object called options . Here's the uncomfortable secret: the boundary is one serializer . React walks every prop you hand a client component, encodes each value it has a branch for, and throws on the first one it doesn't. This post reads those branches out of React 19's Flight source — one file, no framework — and shows the two traps that pass code review and fail the build anyway. What crosses A prop is legal if the serializer has a branch for it. Everything else falls into one prototype check and throws. The whole contract fits on a screen: // app/page.tsx — a Server Component. Every comment is the serializer's verdict. export default function Page () { return ( < Chart title = "Q3" data = { { rows : [ 1 , 2 , 3 ] } } when = { new Date () } seen = { new Set ([ 1 ]) } index = { new Map () } rows = { fetchRows () } // an un-awaited Promise; the client calls use(rows) bytes = { new Uint8Array ( 8 ) } // ArrayBuffer, DataView, every typed array upload = { new File ([], ' a.csv ' ) } // there is no File branch — a File is a Blob form = { new FormData () } stream = { new ReadableStream () } kind = { Symbol . for ( ' chart ' ) } // global symbols cross; Symbol('chart') throws Slot = { Legend } // a client component: a function, and a client reference save = { saveRow } // a "use server" function: a server reference err = { new Error ( ' boom ' ) } // crosses — and arrives empty in production // no branch — every one of these throws at render match = { /q3/ } href = { new URL ( ' https://x.dev ' ) } cache = { new WeakMap () } user = { new User ( ' ada ' ) } bare = { Object . create ( null ) } onPick = { ( id ) => select ( id ) } /> ); } Four of those lines are the ones people get wrong: new Error() crosses, and product

2026-07-12 原文 →
AI 资讯

TrulyFreeOCR – a Java OCR pipeline in a single fat JAR, zero native deps required

Introduction I'm the author of TrulyFreeOCR, an open-source OCR pipeline that turns scanned PDFs into searchable, highly-compressed PDFs. Everything is Apache 2.0 / MIT / BSD — no GPL, no AGPL, no proprietary model weights. Why I built it: I needed an OCR pipeline for a document processing system where: Every dependency had to be business-friendly (no GPL/AGPL) Deployment required zero admin rights (no sudo, no brew, no apt-get) MRC compression was needed to hit 5-10x file size reduction vs JPEG-only Everything had to run offline on CPU — no cloud APIs, no GPU I surveyed 20+ existing tools (full comparison in the repo's docs) and none fit all requirements. OCRmyPDF is closest but needs Python + Ghostscript + Tesseract as system deps, and MPL-2.0 requires publishing modifications. The VLM models (DeepSeek-OCR, GLM-OCR, etc.) produce better text extraction but need GPUs and don't output PDFs at all. What it does: Input: any PDF (scanned, born-digital, or mixed) Output: searchable PDF with invisible text layer + MRC compression (JBIG2/CCITT foreground + JPEG background) Single fat JAR — one file to copy, one command to run Bootstrap script downloads everything (JDK, Gradle, Tesseract, Leptonica, jbig2enc) into project subdirs Fully offline, CPU-only PDF/A-2b output available 7 bundled language models, 100+ more downloadable Concurrent OCR (configurable thread pool) Try it in 3 commands: $ git clone https://github.com/msmarkgu/TrulyFreeOCR.git $ cd TrulyFreeOCR $ ./bootstrap.sh ./run.sh tests/simple-text.pdf -o output.pdf Limitations (being upfront): Tesseract-based accuracy — good for clean scans, not SOTA for noisy/photographed docs No table/formula extraction yet No handwriting recognition CPU-only is slower than GPU backends for high volume Would love feedback — especially from anyone who's tried to deploy OCR in an enterprise environment. https://github.com/msmarkgu/TrulyFreeOCR

2026-07-12 原文 →
AI 资讯

Stratagems #12: Mark Watched an AI Dashboard Take Over. The Muted Channel Was Still Speaking.

Take something that is dead and give it new life. — The 36 Stratagems, Borrow a Corpse to Return the Soul Previously on this series: #1: Mark Johnson Walked Into an AI Audit. The Benchmark Had Everything Figured Out — Except the Truth. — Mark was the first protagonist to open the 36 Stratagems series. A former Client Engineering lead laid off after his 12 years of experience were packaged into an AI Skill, he walked into a benchmark audit, found a benchmark that looked clean on paper but was built on fabricated samples, and walked out without arguing — just the data, neatly collected, left on the table. 11 stories later, Mark is back. Mark Johnson walked into the client's Network Operations Center. The first thing he saw was the big screen on the wall. AI monitoring dashboard. Real-time metrics flowing, color gradients smoothing over, a UI design that cost real money. The client's tech lead walked ahead of him, pride in his voice: "Just upgraded last month — all active channels are unified on this platform now." Mark nodded. His eyes went past the screen, to the cable management trays behind the racks. He never stood in front of dashboards for long. Standard infrastructure audit — mid-sized client, decent security rating, not a high-value contract. He took whatever came his way. Couldn't afford to be picky. The audit started at the network layer. He needed the channel inventory, historical logs, configuration change records. A laptop on a temporary desk, a cup of coffee he'd brought himself — pour-over, gone cold, but he wouldn't throw it out. Flipping through the channel inventory, he found one line that didn't look right. #alert-legacy-infra — a Slack channel. Status: muted . Last active config: 14 months ago. "What's this channel for?" he asked. The tech lead glanced at it. "Oh — that's from the last SRE we had. He set it up before the new platform went in. Nobody's maintained it since. We kept it around, just muted it." Mark didn't reply. He wrote the channel ID

2026-07-12 原文 →