bgongfu

Reminds me of the stinkymeat project [0] for some reason.

Sweet memories from a more playful online experience, and probably part of the reason I turned vegan.

[0] http://www.stinkymeat.net/stinkymeat/day1/

There are different qualities of salt. Some contain additives, sea salt contains plastic particles. I eat plenty of salt, as much as I feel like; but it's all mineral salt without additives.

Everyone likes to pretend they can predict the future for a while, to the point where they will stop at nothing to make it conform to their predictions. Then comes the part where they will defend their choices to death, no matter how much evidence to the contrary is piling up. Once you start seeing the entire chain of consequences, it becomes easier to discipline yourself; it's a process of growing up and taking responsibility.

The whole discussion is a side track, the essence of who we are is and always was immortal. Do you honestly believe in a universe that would throw away the results of the experiment?

There's no proof either way, but it seems the least likely alternative to me. As to Buddha, Gandhi, Tesla, Einstein and many more otherwise respectable thinkers.

Examine what you're not supposed to think, what is collectively ridiculed; that's where truth is hiding in plain sight.

Primitive types such as booleans, int, floats, times etc. are passed by value.

Reference counting is only used for heap allocated values and types that themselves reference values, like pairs and tables.

https://github.com/basic-gongfu/cixl/blob/master/src/cixl/bo...

And since composition is seamless, and they're relatively trivial to implement; they make great glue/DSL/process description languages. Take off as in replace C++ or Java, probably not. I see them more as a complement to existing languages, a more convenient way to glue the pieces together. Even wrote my own [0] to see how far it's possible to push that idea in C.

[0] https://github.com/basic-gongfu/cixl

I get what you're saying, and I get the same feeling from most modern languages. They lack conceptual integrity. It's sort of spreading like a virus, even C++ fell into the same trap lately. Whole system design is difficult, really difficult, tear your hair out difficult. Accumulating features is a Sunday walk in the park in comparison; until the pile tips over, that is.

It sort of makes sense in an engineering/programming context, but life in general doesn't really lend itself to that level of control.

Did you ever try thinking about how they might turn out for the best instead to compare results? Energy follows thought, the more you focus on it the more likely it is to happen from my experience. And the only place and time you're ever going to stop failure from happening is here and now using up to date local knowledge.

Take it or leave it...

Two words, nested functions. They should have been in the C standard a long time ago, solving the same problems without them is a major pain. And even though Clang supports most of the rest of the GCC extensions, they stubbornly refuse to touch nested functions. That and the code of conduct social justice warrior bullshit they've been pulling lately keeps me away from Clang these days.

I wouldn't trust any corporation with something I couldn't afford to loose, Microsoft or not. Corporations, by definition; have no souls.

I guess the question is if they actually changed or just retreated back to the Embrace phase with plan B.

I'm split on this one.

I lived through Microsoft's dark ages, when the victory of open source was still hanging by a thread. The reason we're seeing a softer Microsoft is that they lost, they were forced to change. And the open question is what they learned in the process.

On the other hand, they're producing pretty decent software these days; dotNet Core, TypeScript & VSCode just to name a few solid projects. Open source, no less; imagine that back when monkey boy was running the show, literally.

But then I keep hearing about shady Linux licensing deals and endless privacy intrusions over in Windows land.

Tricky indeed, I think I'm going to leave my code in there for now and give them a chance to redeem themselves.

No experience, and not APL; but [0] pops up on my radar now and then.

[0] https://futhark-lang.org/

There are as many kinds of nils as programming languages.

Cixl [0] doesn't derive nil from every other type, instead Nil and most other types derive Opt; which means that user code may specify Opt to accept nil or any other type to have them automatically trapped by function dispatch. I find this to be a nice compromise between wrapped optionals and shooting from the hip.

[0] https://github.com/basic-gongfu/cixl#optionals

While I'm all for more options, and against deprecating commonly used functionality; the results I'm getting say that first class context switching support isn't really as important as we like to pretend.

Sweet Amiga memories :)

I recently reverse engineered the walker to get something simple but fun to animate, in the console no less:

https://github.com/basic-gongfu/cixl/blob/master/devlog/cons...

If you're serious about writing code; I strongly recommend learning some C, Forth & Common Lisp to get an idea of what's possible. Once you have those under your belt, appearances matter less and Cixl will look less crazy banana.

Not bad; my make-fu was never that spectacular to begin with and it hasn't been aging well, this helps me a lot.

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!

For the record: I just benchmarked GnuPth with NULL sigmask against ucontext for the example in the post and it's slightly (3.4/3.2s) slower.

I hear you; I'm not overly excited with CMake either, or the C build system story in general.

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.

I was under the impression that Boost Context is more than that; at least that's what the amount of assembler code tells me; but I'll be the first to admit I don't have much patience for deciphering modern C++. I get that it's possible to invoke the same functionality as ucontext minus signal masks manually, but I'm not convinced it would save enough cycles to pay for the added complexity.

Isn't Zig based on LLVM rather than compiled to C?

Not faster than dealing directly with ucontext from what I've seen; many wrap it directly and the rest tend to emulate using signals, setjmp and prayers.

I would love to be wrong though...

Cixl? :)

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.

https://github.com/basic-gongfu/cixl#compiling

It's slower than Boost Context for sure, but still around 10x faster than (ab)using Pthreads on Linux. Until someone releases a faster standalone C library it's still the fastest portable solution for projects like Cixl that can't afford dragging C++ around.

Jedi encryption :)

One of the ideas I've tinkered with along the way is hiding encrypted emails in content that's markov generated from unencrypted communications with the same peer. It doesn't have to be perfect, just good enough to not get caught in the slime squad's algorithms.

There are as many kinds of nulls as programming languages. Cixl [0] doesn't derive null from every other type, instead Nil and all other types derive Opt; which means that user code may specify Opt to accept nulls or any other type to have nulls automatically trapped.

[0] https://github.com/basic-gongfu/cixl#optionals

Good for you maybe, projecting that on people who have a clue what they're doing doesn't make sense either. They're mostly messing up chainsaws as well these days, for the same misguided reasons.

Using a chainsaw without paying attention is how fingers are cut off, using that as an argument against making chainsaws easier to use doesn't make any kind of sense.

Just wanted to mention that GNU C has supported nested functions since forever, it's one of the main reasons I prefer GCC over Clang these days.