Pete Vilter
petevilter.me
Pete Vilter
@petevilter.me
Working on grid interconnection at Pearl Street Technologies. Prev databases and things at RelationalAI, Bubble, Cockroach.

https://petevilter.me
Added wind and solar generators, which respond to wind and sun availability curves. As you edit those curves, the dispatch updates. (Need to work on the color coding to make the correspondences more clear)
August 18, 2025 at 3:19 PM
Nice. Are those datalog-based?
August 3, 2025 at 11:58 AM
React and TypeScript, with a REST API to a NodeJS backend where DuckDB is running.

My initial prompt to Claude was something like "I want to explore DuckDB data in a UI that looks like DataDog, with React and TypeScript" etc
August 3, 2025 at 4:55 AM
and of course the classics, 'filter to this value' and 'sort asc/desc'.

I lose my mind when table UIs don't have 'filter to this value' 😂
August 3, 2025 at 4:45 AM
you can also filter by clicking on the histograms, inspired by Datadog's log search UI
August 3, 2025 at 4:43 AM
are tarriffs going to send prices back up?
July 2, 2025 at 7:16 PM
Datadog up next?
June 11, 2025 at 1:34 AM
@peet.io I see you added support for taking profiles for JS a while ago: github.com/microsoft/vs... very cool!

Think there's a chance of getting this upstreamed to the main debug adapter protocol so other languages can implement it?
May 30, 2025 at 5:16 AM
whoops, that lock implementation had a bug — forgot to set holder back to null, messing up next acquire. now fixed gist.github.com/vilterp/bf02...
May 26, 2025 at 4:29 PM
whoops, repo is still private. source here gist.github.com/vilterp/bf02...
bank.ts
GitHub Gist: instantly share code, notes, and snippets.
gist.github.com
May 25, 2025 at 1:19 AM
bank source here: github.com/vilterp/cons...
github.com
May 24, 2025 at 11:42 PM
Dist Sys Simulator
dist-sys-simulator.netlify.app
May 24, 2025 at 11:42 PM
If we make the client grab a lock around reading & writing the new balance, it's impossible to get a double spend:

the first client to acquire the lock wins; the next sees that there's not enough in the account.
May 24, 2025 at 11:39 PM
I think the closest experience to what I'm looking for is Apple's Instruments or even the Chrome/Safari devtools, but a standardized protocol could really help the ecosystem flourish.

Tools like py-spy and memray have built fancy UIs for profile inspection, but each language/tool shouldn't have to.
May 19, 2025 at 11:04 PM
Could also be interesting to attach to running servers in the cloud or continuous profiling services.
May 19, 2025 at 11:02 PM
And VSCode would be free to visualize the data however it sees fit, e.g. in the debugger UI or by annotating source lines with a heatmap.
May 19, 2025 at 11:02 PM
As with LSP and DAP, each language runtime would be free to do it its own way.
May 19, 2025 at 11:02 PM
Different profile types, like CPU, memory allocation, contention, and blocking could be supported.
May 19, 2025 at 11:02 PM
Under the hood, this could look like VSCode saying to the process "profile yourself please" over the debugger protocol, and getting a stream of stack frames in response, each tagged with a thread ID.

Perhaps it could use the OTel profiling standard as inspiration: github.com/open-telemet...
github.com
May 19, 2025 at 11:02 PM