beagle

JavaScript did this for the Web back in the day. I work on a malleable git-compatible SCM right now. First I put all the performance-critical parts into a native lib, then happily built my own git(hub) in JavaScript. Tastes differ, someone else may build it completely differently. I believe this is the right architecture for the LLM age. https://github.com/gritzko/beagle

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

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...

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 suboptima

I use a C dialect with (ptr,ptr) slices and (ptr,ptr,ptr,ptr) buffers. Effectively a different programming language, still uses standard C compiler. https://github.com/gritzko/libabc In this day and age, the top problem is Claude bringing lots and lots of bad C into the code base. Takes a weekend to clear the week's mess. https://github.com/gritzko/beagle In a cleared codebase though all the usual C memory bugs are virtually non-existant. When did I see core dump last time? I do not remember. Thus feel no urge to use Zig or Rust.

> how does adding the word blob in the url help with that? i don't think it makes a difference here. How does adding a disambiguating segment help disambiguate? "in fact, consider these urls": https://github.com/gritzko/beagle/issues https://github.com/gritzko/beagle/pulse > are functions to describe how the object in question is to be presented So they are functions, which take parameters, which makes prefix notation reasonably natural? > the problem is rather that it is in a weird place. it should be at the end That's, like, your opinion man. > except i think putting it at the end makes handling relative paths more difficult as it would have to be appended to every link to other files. It also doesn't make sense when file paths may not be relevant at all e.g. compare https://github.com/gritzko/beagle/commit/a7e172 and https://github.com

how does adding the word blob in the url help with that? i don't think it makes a difference here. in fact compare these urls: https://github.com/gritzko/beagle/blob/a7e172/VERBS.md https://github.com/gritzko/beagle/raw/a7e172/VERBS.md https://github.com/gritzko/beagle/commit/a7e172/VERBS.md turns out that "blob", "raw" and "commit" have nothing to do with the hash itself, but are functions to describe how the object in question is to be presented. so what i said above about blob being redundant is false, the problem is rather that it is in a weird place. it should be at the end, like a kind of extension because it signifies the format of the output. except i think putting it at the end makes handling relative paths more difficult as it would have to be appended to every link to other files. the roxen webserver has an interesting solution

> this should be sufficient to represent the file. Except it's not, because the oid can be a short hash (https://github.com/gritzko/beagle/blob/a7e172/VERBS.md) and that means you're at risk of colliding with every other top-level entry in the repository, so you're restricting the naming of those toplevel entries, for no reason. So namespacing git object lookups is perfectly sensible, and doing so with the type you're looking for (rather than e.g. `git` to indicate traversal of the git db) probably simplifies routing, and to the extent that it is any use makes the destination clearer for people reading the link.

That's actually what it is here, a7e17290a39250092055fcda5ae7015868dabdb4 is a commit's oid: https://github.com/gritzko/beagle/commit/a7e17290a3925009205...

They are following the /key/value/key/value pattern, but the first two pairs in a GitHub URL are fixed to user and project, which lets them omit the key names. I could see them not being willing to hardcode the third pair to blob. Back when GitHub URLs were kind of cool, github.com/user/gritzko/project/beagle would have been much less cool than just github.com/gritzko/beagle.

that's not what i meant. i was trying to suggest that the string "blob" does not fit. why is it there? why is it needed? https://github.com/gritzko/beagle/a7e17290a39250092055fcda5ae7015868dabdb4/VERBS.md this should be sufficient to represent the file. "blob" is like a descriptor of the value that follows. it would be like doing this: https://github.com/user/gritzko/project/beagle/blob/a7e17290a39250092055fcda5ae701… this actually irks me every time i see it in a github url

In fact, GitHub URIs are a good example of overusing paths: https://github.com/gritzko/beagle/blob/a7e17290a39250092055f... - user gritzko, - project beagle, - view blob, - commit a7e17290a39250092055fcda5ae7015868dabdb4, - file path VERBS.md ... all concatenated indiscriminately.

In my current project I use URIs to refer to absolutely any entity in a git(-ish) repo. Files, branches, revisions, diffs, anything. URI turns out to be a really good addressing scheme for everything. Surprise. But the most used and abused element is always the path. Query takes a lot of that mess away. Might have been unmanageable otherwise. https://github.com/gritzko/beagle

Ugh you're right. There was a new AST-based version control system that came out a month ago and I couldn't remember the name. I asked an LLM what the name was and repeated the answer the LLM gave me without checking (facepalm). I may have been thinking of https://github.com/gritzko/librdx/tree/master/be