gritzko

might be relevant: https://martin.kleppmann.com/2025/12/08/ai-formal-verificati...

Thanks, fixed. The runtime[1] and the scripts[2] are the practical ones. I am separating the old repo[3] into submodules since submodule recursion became smooth in Beagle.

[1]: https://github.com/gritzko/jab

[2]: https://github.com/gritzko/beagle-ext

[3]: https://github.com/gritzko/beagle

gritzko

4 日前議論

Three commits in one day fixing the same bug, and the bug is still there, or about the same place as before. That is the actual problem. Not connected to determinism at all, except I want bugs to be fixed deterministically.

gritzko

4 日前議論

I am the author. I am trying to limit one post to one page. Most people here are reading reasoning all day, I am afraid. Might get tired.

I also aspire to make one post a day. To be continued.

gritzko

4 日前議論

I have the last native Fujitsu laptop that is worthy of mention. I am a big fan. Fun story: about 5 years ago they decided to resume their laptop production, and the only practical way was to enroll old retired Japanese workers. I guess, the youth do not have the skill or/and do not want to bother. They made some batches, then I believe it ended.

Panasonic still makes laptops, enterprise use only, very expensive.

How is that relevant? Well, directly.

gritzko

5 日前議論

CommonMark spec[1] is laaarge and not formal (no grammar). StrictMark has block-level[2] and inline[3] grammars, 100+ and 200+ lines of Ragel code respectively. May parse with regexes too, and results will be identical.

[1]: https://spec.commonmark.org/0.31.2/

[2]: https://github.com/gritzko/beagle/blob/main/dog/tok/MKDTB.c....

[3]: https://github.com/gritzko/beagle/blob/main/dog/tok/MKDT.c.r...

gritzko

5 日前議論

About five years ago I faced the fact no two Markdown implementations are fully compatible. I made StrictMark[1], which is a backwards-compatible Markdown dialect with a formal grammar (I use Ragel for parser generation btw). Takes 5-10 min with LLMs to make any implementation, cause formal grammar is unchanged. I use it, no one else does, which is not an issue cause it is backwards-compatible. GitHub renders it fine[3].

Solved my problems. Caused no inconvenience.

[1]: https://web.archive.org/web/20210130000533/http://doc.replic...

[2]: https://github.com/gritzko/beagle-journal/blob/main/wiki/Str...

[3]: https://github.com/gritzko/beagle-journal/blob/main/wiki/Str...

gritzko

11 日前議論

May look mundane, but there is a funny trend. Git folks rediscover database internals from the first principles.

gritzko

17 日前議論

2010. I remember those times. I was doing these things for science in 2008. Performance-wise, PEX was much faster than DHT. At least, in my setting.

This year, I was giving it as an assignment to students. Does not take much time with LLMs.

gritzko

18 日前議論

The question is who maintains it. I think, LLM is the only practical option. In my agent rules, I tell it to maintain INDEX.md on each level. That takes 1 line of instruction and starting with an example file. Then, it self-maintains.

gritzko

23 日前議論

In the Beagle SCM, I am doing my best to simplify that flow, but that is only doable because Beagle has multi-project repos. Still, there are some difficulties with submodule recursion. In the git model, difficult to imagine this working smoothly.

gritzko

24 日前議論

Every Beagle command:

    gritzko@spot ~/beagle $ be get
     19:07  get ?#0ac49e6a
     16:58  post ?0ac49e6a#POST-018 put:/post: banner on stdout
     19:07  new beagle/test/be-post-put-banner.sh
     19:07  upd dog/INDEX.md
     ...more stuff...
     19:07  del test/post/01-bare-msg/01.put.err.txt
     19:07  del test/post/01-bare-msg/02.post.err.txt
     19:07  get abc?4222dfab

gritzko

24 日前議論

Five is enough. Beagle uses five HTTP verbs: GET, POST, PUT, DELETE, PATCH. And it is syntax-aware.

https://replicated.wiki/blog/uris.html

gritzko

27 日前議論

Git vocabulary is workflow-based, i.e. "what we usually do". Unfortunately, the language grew complex and easy to mess up. The problem of NxN interactions: what happens if we do C between A and B?

So the idea here is to define actual operations that happen to the tree, formally. Those are a bit more complicated than the vanilla blob/tree/commit model, but still manageable. Six verbs is enough.

Overall, it all decomposes cleanly and uniformly. Workflow-based vocabulary becomes unnecessary (and a bit confusing) once you grasp that basic underlying model of orthogonal operations/concerns. Some parts still need work though, e.g. conveying the precise state of the tree (can't steal from git here).

gritzko

27 日前議論

The most human-friendly thing is probably natural language. If so, it is LLMs who should have an intuition about the REST interface and its URI syntax. I personally would prefer to glance at it, but not to type it repeatedly. Especially, hashes.

So, the actual question is how to make this machinery un-screw-up-able. (Author)

gritzko

28 日前議論

https://github.com/gritzko/libabc/blob/main/Sx.h

https://github.com/gritzko/libabc/blob/main/S.md

ABC uses s[2] for slices, g[3] for gauges, b[4] for (ring) buffers. Also containers on top of those (heaps, hash sets, etc etc)

gritzko

先月議論

Nice experiment, but a bit expensive.

I work on Beagle, a git-compatible SCM [1]. I use ABC, Abstractionless C [2] dialect with slices, optional range checking, etc. So far, memory safety was the least of my concerns, frankly. Most of the thorny issues would be equally thorny in Rust (e.g. right now: reflog zeroed when VM ran out of disk space; must be some state machine issue or an OS level glitch). Also, forking off a C process (no runtime) is cheap enough that you actually want to do that more.

But, those are all technicalities. The key issue I see with the approach: the data structures and algos of git have been fanatically fine tuned for that particular application with those particular usage patterns. By very sophisticated low-level C programmers. So, quite likely, any other app/lib working with that store will always be a suboptimal fit. I would recommend read-only access only, esp for LLM code.

Meanwhile, git's underlying data model (blobs/trees/commits) is very simple and very much internet-standard level. Decoupling at that interface is so much easier with so much less issues looming.

May look differently from your vantage point though.

[1]: https://github.com/gritzko/beagle

[2]: https://replicated.wiki/blog/abc

gritzko

先月議論

I always post this https://www.rte-france.com/en/data-publications/eco2mix/powe...

gritzko

2 か月前議論

I live on alpine, in fact.

gritzko

2 か月前議論

That is interesting. I make LLMs write C with the general hope that a simpler language they can manage well. That is not entirely true, though. They reason about C fluently indeed. The problem is, Claude pumps lots of bad C into the codebase if left unattended for 5 min. So, I need some clean-up passes afterwards to get to some acceptable quality level (both by LLMs and my own eyes). At which point, Claude sees the problem clearly, for some mysterious reason. Also, I use a C dialect heavly influenced by Go (slices, generics, no smart tricks, virtually no malloc).

投稿

Automating AI Away

Work the Tool to Work the Thing

AI: Surgeon's Assistant or Commodity on a Meter?

Beagle: Git, URIs and all the dirty words

Three Years with Abstractionless C

Three Years of Abstractionless C

Spot – Git repo code search, replace, diff and merge

Spot – git repo AST-aware index, search and replace

Iranian strikes on Amazon data centers highlight industry's vulnerability

Beagle SCM: repos, branches, waypoints and milestones

Part II. SCM as a database for the code

Beagle SCM: improving on Git's "blockchain"

Beagle SCM: the continuous commit model (a.k.a. undo/redo)

Beagle: CRDT-based AST-level version control (doc)

[untitled]

Beagle CRDT SCM outer interface

SCM as a database for the code

Challenges of revision control in the LLM era

Arguments for a syncable data exchange format

The Internet's Last Bottleneck

コメント