this post was submitted on 17 May 2024
6 points (80.0% liked)
FreeAssembly
75 readers
1 users here now
this is FreeAssembly, a non-toxic design, programming, and art collective. post your share-alike (CC SA, GPL, BSD, or similar) projects here! collaboration is welcome, and mutual education is too.
in brief, this community is the awful.systems answer to Hacker News. read this article for a solid summary of why having a less toxic collaborative community is important from a technical standpoint in addition to a social one.
some posting guidelines apply in addition to the typical awful.systems stuff:
- all types of passion projects and contributions are welcome, including and especially those that aren't programming or engineering in nature
- this is an explicitly noncommercial, share-alike space
- don't force yourself to do work you don't enjoy, or demand it of others
(logo credit, with modifications by @[email protected])
founded 8 months ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
that’s my biggest frustration with Aux. they’ve actually dropped the nixpkgs fork after the board announcement, but I haven’t seen many concrete plans after that. there’s so much low hanging fruit for improvement on NixOS’s mechanisms and processes and I’d love for someone to take a swing at fixing all that — but I don’t think Aux is currently anywhere near focused enough to be it
at least we got Lix out of things, which I think is an incredibly important project to have especially after the board announcement. Nix’s new governance structure has a gigantic gap in it in the form of the Nix evaluator, and I feel strongly that’s intentional. having an independent and modernized (but compatible) Nix implementation will be better for the ecosystem as a whole.
I’d love to hear about your Nix implementation when it’s in a shareable state. I’ve got a few Nix-related projects myself that need a good home — some finished ones are waiting for things to fully settle before I decide how they’ll be released, but one project I’d like to start (but don’t know where it should go) is much better directory-local evaluation — that is, lorri/nix-direnv/
use nix
but with just one vastly-improved implementation in the evaluator.Yeah, Lix is good. It's not what it claims to be, but just being a CppNix fork is enough.
So, I'm not developing in secret. My code is here, in my rpypkgs flake, and as the
.packages.${system}.reguix
attribute of that flake. One would probably want this Cachix cache if they're on amd64 and want to avoid building PyPy or CPython. (Upstream discussion about this bootstrap path is here.) I'll send out a more serious round of invites once the lexer, parser, compiler, and evaluator can actually handle a real-world evaluation.For posterity: Hi! I'm linking this to you because you'd like to contribute to Regiux. Cool! You need to know RPython, a dialect of Python 2.7 used to specify interpreters. In a nutshell, RPython is statically-typed with lots of metaprogramming, somewhere around Java or Haskell. You write a Python 2.7 program, it gets imported into memory, and then the RPython toolchain compiles from memory into C, optionally generating a JIT compiler. For a gentle explanation, check out Brown et al doing Brainfuck (1, 2); if you'd like to see what high-performance RPython looks like, check out my DIVSPL interpreter or my take on Brainfuck.
that’s awesome, and RPython seems like a great choice for a more comprehensible foundation for a Nix evaluator! I’ll definitely be digging into this more as time permits this weekend. feel free to start a thread for this if you’d like more eyeballs on it at any point in the future!