Show HN: Minimal Fibers(github.com) |
Show HN: Minimal Fibers(github.com) |
I think ucontext is an excellent starting point for a general implementation. You just abstract it with a thin veneer and adopt faster implementations as needed where applicable.
I realize the Forth & Lisp heritage might be a bit hard on the brain for those who haven't been exposed before, but what you're asking for is otherwise more or less what Cixl is aiming for.
> To build Cixl yourself, you'll need a reasonably modern GCC and CMake installed.
I was very taken aback by this. Really? Why do you really need to depend on the cmake monstrosity? It's just a few lines of C without dependencies that they are distributing!
If there is something about cixl that will scare people is the ridiculous dependence on cmake, not its clean syntax.
(I'm genuinely curious about the answer to this question - I'm also looking for something similar to C)
Why do you consider it too big?
Yeah, it is. You can easily avoid the GC as long as you don't mind managing memory yourself (unfortunately this means that you cannot use the stdlib either, or at least parts of it, if you disable the GC with the `--gc:none` flag you'll get warning messages from the compiler about procs that need the GC which is nice).
> I'd also have liked the compiled C code to be readable, which if I'm not mistaken, Nim doesn't do.
Yeah, that's one thing that Nim definitely doesn't do. I don't think there are many languages that do. It would be an interesting experiment to see how pretty you could make the generated C by either fixing things in the compiler or just running a C formatter on it.
This is the kind of friction I expect from a language which uses GC, for my usecase. I think it might make sense for Nim to support a GC-less stdlib for people who do not want GC in their code.
[1] https://github.com/spc476/C-Coroutines
[2] In my not-so humble opinion, using signals at all is not wise.
xchg %rsp, %rdx
leaq 1f(%rip), %rax
jmp *%rsiIt it expect the target stack ptr/ip pair to be in rdx/rsi and saves the current stack ptr and ip in rdx/rax. It does not save any register and uses gcc asm clobbers to instruct the compiler to save any other register.
Code at [1]. The comments about hacks and ub is because I'm trying to transparently propagate exceptions across coroutines, otherwise the stack switching us fairly robust (although GCC specific).
[1] https://github.com/gpderetta/delimited/blob/master/delimited...
I would love to be wrong though...
I spent several years trying to bend regular make into something I was happy with; then I spent several years on top of that using Rake, since at least it allowed me to say what I mean in a sane language. Compared to Rake, CMake is at least semi-standard, provides some kind of macro for most things I want to do, and mostly stays out of my way.
But you definitely have a point when it comes to simplicity and project fit. If someone would be willing to step up and help translate the makefile into something that doesn't look horrible, I'd be more than happy to let it go. Otherwise we'll have to wait until I get enough round tuits, which could take a while given how much remains to be done in Cixl.
CFLAGS = -Isrc -O2
LDLIBS = -ldl -lm
SRC = $(shell ls src/cixl/*.c src/cixl/lib/*.c)
OBJ = $(SRC:%.c=%.o)
src/main : src/main.o $(OBJ)
clean : ; $(RM) $(OBJ) src/main
test: src/main ; for i in tests/*; do ./src/main<$$i; done
Sure thing, if you feel like giving the entire makefile the same treatment I'd be delighted to accept it.
Thanks for taking the time!
I take it that cmake tried to tackle autotools, partially succeeded, and partly succumbed to autotools' all-devouring complexity? :)
I do not know what is "the percentage system", but I doubt it can be so wonderful to make me forget about all the other unnecessary problems.
It may be justified to use cmake when it is really needed. But the cixl interpreter can be built by a five-line makefile.
I was regarding how it outputs progress indication, like
[ 16%] Building C object ...
[ 91%] Linking C executable ...
But (10 years on) I can understand it being icky to use. I guess, ugly as it is, it's a little more structured than automake is, and maybe that's its redeeming quality.
Maybe build systems are the dead-centre of a "sour spot" (opposite of sweet spot) in computer science, with no truly nice solutions out there? (Genuinely curious. The exponential profusion of JS build systems suggests it's rather hard to solve.)
The only explanation I have is that
- Maybe the author is used to cmake
- Maybe this project has Big Goals And Ventures™ syndrome - and, hence, all the enterprise build systems. (Hopefully not, it looks kinda nice)
I think it's the opposite. It is a very, very sweet spot for which many essentially perfect solutions exist. Then, it attracts all kinds of extreme bikeshedding and produces the monsters we see here and there.