> Currently, only Windows and Linux are supported by BBA-IPC, but if there is enough interest, cristian64 has already found another library that could let us support this in other operating systems.
Had to look it up. Saw this right on the main page of nanomsg:
> This project has largely been superceded by the nng project. Users are encouraged to use nng if they are able. The nng project is wire compatible with this library, and supports a significant superset of capabilities.
> This may not come as a surprise, but Linux (and with some tweaking even macOS) supports SLIP.
Anyone have any experience with SLIP for macOS? Curious if the author was actually able to make that work, I’ve been looking into something similar the past few weeks with no luck.
Are there any culling optimizations for unseen elements when layering SVG images? Looks like this isn’t an optimization that comes out-of-the-box with OpenVG and all the major web browsers needed to add this, so wondering what your solution is doing.
> Makes you dream there could be an equivalent for our own universe?
I’ve always considered that to be what’s achieved by the LHC: smashing the fundamental building blocks of our universe together at extreme enough energies to briefly cause ripples through the substrate of said universe
That's assuming there is a substrate that can be disturbed. That's where the parent's analogy breaks down.
As an example of an alternative analogy: think of how many bombs need to explode in your dreams before the "substrate" is "rippled". How big do the bombs need to be? How fast does the "matter" have to "move"? I think "reality" is more along those lines. If there is a substrate - and that's a big if - IMO it's more likely to be something pliable like "consciousness". Not in the least "disturbed" by anything moving in it.
It's a pretty exact description: the universe is made of fields, smashing stable excitations of those fields together produces disturbances in other fields (“virtual particles”) that sometimes makes (fleetingly) stable excitations in other fields, which then fall apart through the same dance into different stable excitations than we started with, allowing us to prove that the field in the middle exists and start to determine its properties.
Another way to think of it. Consider breaking out of Minecraft. Can you do it?
Maybe. There are certainly ways to crash it today. But now let's go through some cycles of fixing those crashes, and we'll run it on a system that can handle the resource usage even if it slows down in the external reality's terms quite a bit. And we'll ignore the slash commands and just stick to the world interactions you can make.
After that, can you forcefully break out of it from the inside?
No.
It is not obligatory for systems to include escape hatches. We're just not great at building complex systems without them. But there's no reason they are necessarily present in all systems.
Another brain bender covering the same idea in a different direction: The current reigning candidate for BB(6) runs an incomprehensible amount of computation [1]. Yet, did it at any point "break out" into our world? Nope. Nor do any of the higher ones. They're completely sealed in their mathematical world, which is fortunate since any of them would sweep aside our entire universe without noticing.
The LHC doesn't generate anything like the kind of energy that you get when interstellar particles hit the Earth's upper atmosphere, nevermind what's happening inside the sun - and any of these are many, many orders of magnitude below the energies you get in a supernova, for example.
The LHC is extremely impressive from a human engineering perspective, but it's nowhere close to pushing the boundaries of what's going on every second in the universe at large.
I’ve been curious, what are the motivations for most projects to use Lua for enabling scripting in C over this? Is the concern around including an entire Python interpreter in a project and Lua is lighter?
Lua is absolutely trivial to isolate. As the embedder, you have complete control over what the interpreter and VM are doing. Don't want your Lua scripts to have file access? Don't hook up those functions and you're done. Want to prevent against endless loops? Tell the VM to stop after 10.000 instructions. Want to limit the amount of memory a script can use? Absolutely trivial. This makes Lua very attractive for things like game development. You can run untrusted addon code without any worry that it'll be able to mess up the game - or the rest of the system.
Doing the same with Python is a lot harder. Python is designed first and foremost to run on its own. If you embed Python you are essentially running it besides your own code, with a bunch of hooks in both directions. Running hostile Python code? Probably not a good idea.
Another thing to mention is that until very recently (Python 3.12, I think?) every interpreter in the address space shared a lot of global state, including most importantly the GIL. For my area (audio plugins) that made Python a non-starter for embedding, while Lua works great.
I agree though: biggest reason is probably the C API. Lua's is so simple to embed and to integrate with your code-base compared to Python. The language is also optimized for "quick compiling", and it's also very lightweight.
These days, however, one might argue that you gain so much from embedding either Python or JavaScript, it might be worth the extra pain on the C/C++ side.
People already mentioned that Lua is very lightweight and easy to integrate. It's also significantly faster than Python. (I'm not even talking about LuaJIT.)
Another big reason: the Lua interpreter does not have any global variables (and therefore also no GIL) so you can have multiple interpreters that are completely independent from each other.
Lua is much lighter but the key is that it’s probably one of the easiest things to integrate (just copy the sources/includes and add them to build it’ll work)—like a “header only” kind of vibe.
But, you can strip down a minimal Python build and statically compile it without too much difficulty.
I tend to prefer Tcl because it has what I feel the perfect amount of functionality by default with a relatively small size. Tcl also has the better C APIs of the bunch if you’re working more in C.
Lua is very “pushy” and “poppy” due to its stack-based approach, but that can be fun too if you enjoy programming RPN calculators haha :)
I've done both. Let me tell you, embedding Lua into a C program is magnitudes easier than embedding Python.
The main reason is the endless fragility of Python's garbage collector. To be clear, the API is trying to be as helpful as possible, but it's still a whole bunch of complexity that's easy to mess up. Incidentally, this discussion is left out in the linked article, which makes it less than useless. In my experience with many a third party C/Py interface, data leaks are incredibly common in such code.
Lua of course also has a garbage collector, but it essentially only knows two types of values: POD, and tables, with only the latter needing much consideration. The interaction model is based on a stack-based virtual machine, which is more complex than Python's full-function abstraction, but conveniently hides most of the garbage collector complexity. So long as you're just reshuffling things on the stack (i.e. most of the time), you don't need to worry about the garbage collector at all.
Just listened to a segment about him on NPR, apparently his writing themes were greatly influenced by an experience he had as a child where he was standing next to someone who was killed by a lightning strike.
Definitely I have lots more to say about 15-glider universal construction! It was a really exceptionally interesting collaboration, where several people working together were able to complete something that would have taken any one person a ridiculously long time to sort out.
Development of the RCT has slowed down a bit, though there's a hyper-optimized version in the works that will build a spacefiller instead of a Hensel decimal counter as its example pattern:
There's also another long-awaited project in the works, that will use quite a bit of the same technology along with some new ideas -- a unidimensional (one cell thick) spaceship:
It's improbably complex and awkward, of course, just like an RCT pattern, and it's huge though nowhere near as huge as an RCT pattern -- but there will be one phase of the spaceship that fits in a 1xN bounding box.
For anyone curious, the cross-platform IPC library they’re considering is ZeroMQ. Draft pull request here: https://github.com/dolphin-emu/dolphin/pull/14046