The launch post for php_clickhouse 0.6.0 covered the framing: native binary protocol, soft fork of the stalled SeasClick, modern ClickHouse types, 30-40% faster than HTTP at high throughput. That post landed April 25, 2026. Today (May 1, 2026) the current tag is 0.8.1, and I'm calling the extension stable. The six days in between were a focused quality cycle, not a feature sprint. Three buckets: Performance. Insert and write paths build native ClickHouse columns one at a time directly from row-major input. Peak intermediate PHP memory dropped from N_rows × N_cols zvals to one column. Security. Strict full-consumption parsers across Map, narrow-int, Int128 / UInt128, geo, DateTime64, Time64, hex literals, and typed parameters. Wrong-type input throws instead of corrupting memory or coercing silently to zero. Recursive type-conversion gained a depth cap so adversarial server schemas can't blow the stack. Stability. Per-Client state moved from file-scope std::map banks onto the zend_object...

Anyone who's tried AI-assisted trading research has hit the same wall. The agent has no native access to your charts. You end up copy-pasting symbols, indicator values, screenshots, and Pine Script back and forth between TradingView and Claude or Cursor. The tools that try to fix this fall into two camps: route market data through a third-party API (added latency, added cost, their interpretation of your bars), or pollute your TradingView chart with helper indicators just so an agent can read them back. There's a third path that's more obvious in retrospect: drive your local TradingView Desktop through the Chrome DevTools Protocol that the app already exposes on port 9222 when you launch it with --remote-debugging-port=9222. The agent talks to the same TradingView you already use, reads what your chart actually shows, executes Pine Script through TradingView's own runtime. Same data, same indicators, same features, just with an agent in the loop. A project called tradesdontlie/tradingview-mcp star...

In 2005 I wrote a PHP binding for libstatgrab and pushed it to PECL. The extension took CPU, memory, disk I/O, network, process, and user statistics from a cross-platform C library and exposed them to PHP as plain functions. I moved on to other things, libstatgrab kept evolving, PHP went through three major versions, and the binding sat untouched. By 2020 you could not build it against PHP 7 without patches. By PHP 8 it was effectively gone. statgrab 2.0 brings it back. PHP 8.0 through 8.5, libstatgrab 0.92+, glibc Linux, musl, macOS, FreeBSD. The 2006 procedural API still works (sg_cpu_percent_usage, sg_memory_stats, sg_diskio_stats), there is a modern OO surface (Statgrab::cpu(), Statgrab::memory(), Statgrab::processes()), counters return as 64-bit int instead of the 2006 stringified %lld, and the BC bugs that were latent in the original (swapped page-stat keys, copy-pasted gid/egid fields, the flat name_list for users) are fixed. A few things had to change to get there. One of them wa...

I run a few projects that move a lot of data through ClickHouse. Telemetry pipelines, ad-hoc analytics, log ingest. The two pure-PHP options today are smi2/phpClickHouse (HTTP) and lizhichao/one-ck (binary TCP). HTTP gets you a 30-40% slowdown on hot loops; one-ck shipped its last release in 2020 and isn't keeping up with the column types ClickHouse keeps adding. The reference native binary client from ClickHouse themselves is C++ only. A PHP extension already wraps that C++ client: SeasX/SeasClick. The last accepted external PR there is from 2020, and a handful of follow-up PRs have been sitting open since, including my own PR #4 from 2019 that added the fetch-mode constants (FETCH_ONE, FETCH_KEY_PAIR, FETCH_COLUMN, DATE_AS_STRINGS) and a SeasClickException class. When I finally got around to updating that PR to merge cleanly, I realised the extension was kinda dead and had a few issues. So I forked it, renamed it to php_clickhouse, swapped the vendored client (an old artpaul fork) for the offici...

Several of my projects do heavy markdown parsing. Comment rendering, documentation pipelines, content management. The volume keeps growing, and I've been hitting the point where pure-PHP parsers (Parsedown, league/commonmark, cebe/markdown, michelf) just can't keep up. They're solid libraries, but parsing thousands of documents per request or chewing through 200 KB files in interpreted PHP is slow no matter how well the code is written. I wanted something 10x+ faster that could serve as a drop-in replacement for the common cases. The result is mdparser, a native C extension that wraps cmark-gfm (GitHub's CommonMark parser) and exposes it through a clean PHP 8.3+ OO API. I'm releasing it today. How it works mdparser vendors a copy of cmark-gfm 0.29.0.gfm.13 directly into the extension's shared object. No external library to link against, no cmake, no runtime dependencies. The entire cmark-gfm codebase compiles alongside the PHP wrapper into a single .so (or .dll on Windows). Four cherry-picked comm...