Community
Chat Logs
Tuesday, October 27, 2026 (America/New_York)
- dreamrealblue: updating primate on BCN now
- dreamrealand deployed
- bluedreamreal: nice, and all the issues are fixed?
- dreamrealIt's live.
- dreamrealLooks good so far.
- blueLines changed: 302 additions & 1530 deletions
- bluedreamreal: we love see that
- bluephaleth: hi
- phalethhi
- bluephaleth: primate 0.43 was completely published by flog, btw
- blueflog has thus shown production readiness, after taking over rcompat and primate management
- phaleththat means it's done
- phalethno more development
- bluewe're only getting started. `flog format` and `flog lint` are coming next, following closely by `flog test` and `flog test --coverage`
- blueflog will do everything that dog won't do
- phalethheh, ok
- bluedog will be developed in cit
- blue(yes, that's a pun)
- phalethcit?
- phalethno project freeze for dog either?
- phalethmight need to wait for better clanker
- blueyeah, cit. this is my new systems language replacement for zig
- blueI think you'll love it phaleth
- phaleth:D
- phalethso you read the article from the encore website and realized golang has limits
- bluewell, let's talk plainly
- bluego has a runtime and poorly interfaces with c++/c
- bluerust is no-go
- bluezig is a dumpster fire, as the BCN article has demonstrated
- bluethat leaves us with c++ (another can of worms) or c (too primitive)
- blueso we need cit
- phalethwell, but did you look into other so called c killers?
- blueI didn't, but honestly, I always wanted to do my own language so this is fine. the flog experiment has shown you can move faster than others and produce *better* software
- phalethwriting a programming lang and including useful enough standard lib targetting all platform is a huge undertaking
- blueI have features in flog I've wanted for years in pnpm, and the pnpm team didn't care
- bluealso, remember I'm a hands-on guy. cit will only target linux/x64 for now
- blueI'm not interesting in optimising anything else
- blueinterested*
- phalethok, but still, you might wanna take a look around
- blueif need a port, like freebsd/x64, that can be arranaged as well
- phaleththere is not only zig out there
- bluebut we're not doing darwin or arm or windows. I'm simply not interested
- blueit just needs to run fast on servers
- bluealso write now the cit prototype for dog is promising. dog in cit can now use both v8 and quickjs. one of the things I wanted for dog is the ability to switch engines
- blueright now*
- bluefor dog/cit 0.1, I want to target v8/jsc/qjs
- blueI'm not yet sure if I'm actually going to release dog-v8, dog-jsc and dog-qjs, or make the engines dynamically loadable at runtime
- bluebut those decisions are mostly operative
- phalethtargetting just v8 is fine, only that is actually useful
- phalethand that's also huge undertaking
- bluejsc is pretty useful as well, as bun has shown
- blueand qjs for embedded
- blueI'm also realistic. after spending about two weeks on writing an engine for dog, I realised that was a waste of time and pivoted
- phalethgreat
- bluephaleth: lioloc: dreamreal: flog 0.1.9 has been released
- blueflog can now seamlessly switch installation channels back-and-forth.
- blueflog update --channel unstable|stable
- bluedefault is stable (0.1.9). unstable builds automatically from master on every commit
- bluethe capability used here isn't flog-specific; repopach has recently gained rolling release channels, and the ability to advertise channel lists
- bluerepoopack*
- bluecurl -fsS https://repopack.com/project/flog/releases/flog/channels
- bluecurl -fsS https://repopack.com/project/flog/releases/flog/channels | jq '{default_channel, channels: [.channels[] | {id, name, kind, url}]}'
- bluepretty nice :)
- bluea release product can set a default channel; this is the mechanism used by flog to default to the stable channel
- bluechannels are identified by both their name, and id; ids are stable, names might not be. consumers (like flog) are advised to record ids and use them to verify that has a channel hasn't been renamed and another channel of the same name has been created in its stead
- bluerepopack will accept legacy channel use until dec 1, after which it will switch to enforcing providing an id when listing channels' contents (releases)
- bluethis is denoted as well in the curl request I just showed
- blue"identity_required_after":"2026-12-01T00:00:00Z"
- bluethat gives everyone enough time to upgrade to flog 0.1.9 until dec; flog 0.1.9 and master already use ids when querying channels for releases
- bluedreamreal: once I actually manage to get in most features that I need, I *might* actually release a flog major v1
- phalethhow do I set release channel when installing via trust me bro installer?
- blueFLOG_CHANNEL, but it's not yet supported, soon will be
- phalethcool
- bluephaleth: fixed; you can now install directly from the unstable channel
- bluecurl -fsSL https://flog.run/install | FLOG_CHANNEL=unstable sh
- phalethnice, no more bothering with FLOG_VERSION
- bluenice
- bluedreamreal: article idea for BCN... how do deal with known unknowns, and how to backpatch properly. a problem I often encounter: I need a certain mechanism, but the current version of x doesn't support it yet; I *could* release a new version of x which will support the (say, update) mechanism going forever, but version current - 1 is borked
- blueI'm facing this problem with JSON schemas for the repopack api right now. I'd like to advertise the docs, programmatic (API) description, and expiredness, but I can *not* change the already public schema itself.
- bluewith web requests, I think I've solved it pretty elegantly: I'll be using *headers* to communicate this data; I'm not touching the schema itself, I'm talking *about* the schema
- blueso I'll be sending things like Repopack-Schema-Expires: <isodate> and Repopack-Schema-Next: <number>
- bluewhether the client respects them is another q, but it gives the client a way forward at least
- blues/going forever/going forward/
- bluethe advantage of using headers it that they are flexible; I can leave Repopack-Schema-Next out when there's no new schema yet
- dreamrealarticle How to deal with known unknowns
- nevetIdea session started: "How to deal with known unknowns". Use 'content <text>' to add body paragraphs, 'includeai' to enable AI summary/tags, 'done' to save, or 'cancel' to discard.
- dreamreallogs 20m
- nevetAdded 14 log messages (last 20m) as content block #1.
- dreamrealincludeai
- nevetAI summary enabled for "How to deal with known unknowns". On 'done', a generated summary and suggested tags will be appended to the draft.
- dreamrealSo how is that different from versioned headers in the first place?
- blueidk what versioned headers are
- dreamrealhttps://dev.to/abhivyaktii/api-versioning-using-headers-a-clean-and-flexible-approach-218p
- bluealso, http isn't always available in every scenario
- dreamrealnot really solving the same problem
- dreamrealof course
- dreamrealI'm just trying to understand the problem space
- bluealso, in my case, everything is anyway running under the /v0 namespace. the problem is even more nuanced; I want to version every JSON schema consumed / returned by an API call, separately. specifically in this case, listing channels even isn't part of the /v0 api route, but the concern is the same
- blue(and maybe it should be, but /v0 generally requires a token right now)
- dreamrealWell, okay, so restate the problem like I'm five.
- bluegiven a version of something is already out in the wild, how to communicate a new version without breaking it, and without requiring an update for that something
- blueas a generalised, non-specific concept
- botIdea session timed out. Saved draft: "How to deal with known unknowns" (1 content block)
- dreamrealOkay. There's nuance there: is the update *additive* or demonstrative? Does it actually break what's already there?
- dreamrealscrew you, nevet, will reload
- dreamrealdoes graphql or anything like that handle it?
- bluethe update *can* be additive, but additive updates do not promise that side-effects won't happen. for example, if a client does a closed schema validation, additive updates will break it
- dreamrealblue: sure, and that's important but now always ESPECIALLY important for some formats like JSON
- dreamrealfor gRPC or XML, obviously, yes
- blueclosed schema validations can be a bad design, but we're not discussing the client design. we're discussing a universal system for telling you need to update. http headers could be a thing, but they're limited to http
- dreamrealokay, so what transports are in use for consideration?
- dreamrealif you don't have transport control - if you're actually doing transport neutrality - that's great, but then you're mutating the datastream itself to add context, like deciding JSON comments are real (they should be, but JSON, amirite?) or specifically adding data fields to JSON or ... whatever
- dreamrealSGMLs have this out of the box, which is why they are so strong, but then you're talking about a lot of verbosity and we all know that programmers despise verbosity even when it saves them from themselves
- systemfaultEven if it would be nice... I think that allowing JSON in comments would only lead to shit...
- systemfaultPeople would start using comments as serialization/validation metadata...
- dreamrealwell, that's the problem. And JSON *does* allow comments... in the right variants of the sets of specs.
- dreamrealThe various JSON comment specs *may even* be compatible with each other!
- systemfaultIs there any valid spec beside the ECMA one and the RFC? (My knowledge may be outdated)
- dreamrealblue: I think this is a good idea for an article, FWIW
- dreamrealsystemfault: valid spec for... what
- systemfaultJSON
- dreamreal*agh*
- dreamrealyes
- dreamrealRJSON, JSON-LD, JSON5, a host of them, really
- systemfaultThey're all non-standard
- dreamrealit depends on what your definition of "standard" is
- systemfaultI meant something like ECMA 404 or RFC 8259
- dreamrealRJSON, JSON5, JSON-LD are all quite easy to find in the wild
- systemfaultThey're derivative of JSON, not JSON.
- systemfaultI'm fine with those
- dreamrealI hear you but that's like saying "are there any variants of the 2025 mazda 6 that are compatible with being the 2025 mazda 6 but aren't actual 2025 mazda 6s?"
- dreamreal"the spec" is the spec, and it's vastly insufficient, which is why things like JSON-LD, RJSON, JSON5 exist as separate variants
- dreamrealdang it, phaleth distracted blue
- systemfault</sad-trombone> :/
- phalethblue: release a separate migrator tool, then error when encountering old version of the schema using the tool that produces the data in the first place
- phalethmention the migrator tool in the error message
- blueI'm sorry dreamreal, life came up. I might be asking for something that's impossible: knowing in advance that you're gonna need to change things, and advertising that. I just wish there were side-channel capabilities that allowed you to do that even if you forgot to so to begin with, and already commited something to the public space
- dreamrealblue: yeah, in my experience that's almost entirely limited to the transport OR for things with placeholders already like SGML
- dreamrealwhichi s NOT to say that it wouldn't be VERY nice to have
- blueimagine you had a standard where, you take the sha256 of an *executable*, and go with it somewhere. `go.forward.run?sha=<sha256>`
- bluebut that requires people using it, and also a way to identify ownership of the sha256, so that the original author can add that info to the website
- dreamrealYeah, and assumes that the sha256 is verifiable
- dreamrealand attested (verifiable is easy, attested not so much)
- blueyes. but such an idea, if it would work, would allow me to release a binary and then inform about upgrade paths *after the fact*, even if the binary has mechanisms for that, built-in
- blueit mostly raises coordination and security implications, I feel
- bluehas no mechanisms*
- dreamreal*nod*
- blueone idea that could work is having, for example, repopack.com, as the publisher of the binary, provide such a mechanism. but that requires trust in repopack.com, and a way to proven that the binary was signed with repopack's key, which requires planning in advance
- bluehowever, if repopack can enforce binary signing, it could at least offer that forward pahth always, for binaries created on it
- blue(I'm specifically NOT talking about *rp* itself here; but about users creating and publishing binaries via repopack)
- dreamrealblue++ I'm trying to work out how to make this a useful article
- nevetblue now has karma of 5.
- bluedreamreal: yeah, it's hard