As far as I know that is really the only example. And to clarify it is about a struggle between who controls Rubygems and Bundler, not Ruby itself. A key component to be sure but maybe not that relevant to this discussion when the ones running the infra hijacks the GitHub project. That was an inside coup.
I started by writing a user interface that handled they keyboard events in a thread and communicated to the main thread using a message queue.
IMO that's a good easy first step :)
If a thread is blocked waiting for something, then at some point in the future it will be ready to continue execution. But what if some other thread is still running on that specific core? If there is some other core available and you can restart execution there with low overhead, that's a performance win.
I think that as asynchronous code becomes more and more common, this kind of capability becomes more and more beneficial.
Yes, I assume that it is better to spread the generated heat across the die. Migrating threads between clusters probably does have some cost (mostly cache misses, minimal cost to pausing and moving) but if done less than every second that is likely miniscule.
I find that https://github.com/casey/just is a great answer to a lot of problems in this thread.
I have a justfile in all my projects now and I'm very happy.
I found just and was about to use it in place of a Python script for preset targets in one of the Greenfield projects I had. I decided not to since it makes a weird decision to use sh in Windows environments, it tries to use Git for Windows bash or MSYS2 one which is very unwieldy.
I am still in search of a simple build scripting language/system that doesn't rely on any OS shell. Something that isn't as barebones as ninja, isn't as wacky and Unix specific as Make nor is as general purpose as Python. I just want a statically linked executable that I can install in any of the Linux, macOS or Windows versions as a single binary. It should handle the path differences well and should execute things directly without a shell. I basically need a very basic script interpreter.
CMake kind of is that system but it is too stringly typed and sometimes wacky too. Python kind of works too, but they have a quite a bit disregard for backwards compatibility and isolation from the surrounding OS, so I am forced to use solutions like Conda to ensure a specific version with specific dependencies and their versions are pulled and can be reproduced across different OSes without interfering with the locally installed Python.
No. Not really. Is Make a shell? It isn't. Neither is CMake. Python can be used as one but it really lacks niceties that an actual shell would provide. A cross platform shell with limited capabilities would do the job for me but it is overkill.
I am not really looking for features you find in shells like REPL, job control or very complex structure support. Having targets and being able to execute commands to build them independent from any OS shell is enough.
Same. I think a lot of it comes down to the language you’re using. If I’m doing something in Python or Rust, poetry or cargo hand all the magic I would have encoded in a Makefile for a C project years ago. Today I have a justfile with a target like:
build:
cargo build
and a bunch of other targets for testing, running it, etc.
That’s primarily via the PROs - ASCAP, BMI, SESAC.
E.g. ASCAP says
“Fortunately, most popular live-streaming platforms, such as YouTube, Facebook, Instagram Live, Soundcloud and Twitch are licensed by ASCAP”
I’m assuming because DJ performances via twitch are considered non-interactive streaming they - like Pandora’s free tier - don’t need a mechanical licence, at least in the US.
How that then translates to other territories though I’m not entirely sure. In Europe I’m pretty sure they’d need to have a mechanical licence in place whether or not they are interactive.
My only concern is that actually the big guys get the big cut, and the DJ and the original artists (that are not wildly popular) the shortest end of the stick.
