Programming thread

Can I ask why? What access pattern are you trying to implement here? Can't you solve it some other way, such as optimistic concurrency and immutable data structures?
ex, the entire data structure is immutable, behind a managed ref, each bin is also immutable behind a managed ref, reads are "free", inserts require some STM and then you transact an update to the bin and the head.
Entity system for a game engine. Lots of components have n-m relationships; for example each entity may have n behaviors, but for the purposes of dispatching behaviors I also need to be able to map each behavior to the m entities that have it. My previous solution was as you suggest a pair of copy-on-write lists, which while workable, creates an unacceptable quantity of garbage and also requires mutex during edits. Ultimately I'd like the engine to run totally concurrently (and with few gc stalls) and I'm hopeful this will support that.
 
Entity system for a game engine. Lots of components have n-m relationships; for example each entity may have n behaviors, but for the purposes of dispatching behaviors I also need to be able to map each behavior to the m entities that have it. My previous solution was as you suggest a pair of copy-on-write lists, which while workable, creates an unacceptable quantity of garbage and also requires mutex during edits. Ultimately I'd like the engine to run totally concurrently (and with few gc stalls) and I'm hopeful this will support that.
So your idea is to create an entire MxN mapping then operate on it concurrently?
Sounds hard, tbh.
There are lots of ways you could slice and represent this data. I was thinking more about binning / partitioning it such that different threads will get a "range" of entities and only write to their area (have to be wary of false sharing, cache, yuck). You could even do it in a completely lockless manner if you find a good algorithm to partition the work. Also depends if your model is entity first or behavior first.
 
  • Like
Reactions: Strange Looking Dog
So your idea is to create an entire MxN mapping then operate on it concurrently?
Sounds hard, tbh.
I've got a working concurrent skip list and I've got a working concurrent two way singly linked list so it's a matter of combining them. I'll be honest it's a little daunting, so today I've just been messing with bezier curves.

There are lots of ways you could slice and represent this data. I was thinking more about binning / partitioning it such that different threads will get a "range" of entities and only write to their area (have to be wary of false sharing, cache, yuck). You could even do it in a completely lockless manner if you find a good algorithm to partition the work.
The entities are basically just UIDs, the top half of which is it's "family", and since similar entities are generally allocated from the same family behaviors will generally only apply to a few contiguous ranges of entities. CSL edits only have localized side effects so contention should be fairly limited.

For synchronization each task has a list of resources that it uses, and the scheduler ensures that tasks with conflicting resources can't run at the same time, but other than that it's lockless.

Also depends if your model is entity first or behavior first.
What do you mean?
 
  • Like
Reactions: Shoggoth
so today I've just been messing with bezier curves.
I know that feel. I've been messing around a bit with [redacted] to chill for the past week or so. Ended up learning interesting things about streams
What do you mean?
You can think of a ECS as a database of sort. It's basically a question of what you index on. Is your index (e.g. access pattern) around entities first, or behaviors first? This is as simple as: is your outer loop over entities or behaviors?
Another way you could model it is EAV, with cross indexing, where a EID is just a number, the attributes are things like family, behavior, etc.
Then you can build AEV index which lets you access from family or behavior first.
Entity component systems are hard, concurrency is hard, I wish you luck. You should (perhaps) take a look at how tangentially related systems have solved the issue. Indexing and accessing lots of data concurrently is a wide field. It also depends on how much "lateral" influence each action has on the system, i.e. how many entities / attributes should change (falls under access pattern tbh).
I dunno man, build an in-memory hybrid of LMAX disruptor and Apacha Samza, maybe that will win?
 
I have a basic knowledge of C (yes, C, not C++ or anything like that) and HTML. Recently I've wanted to start learning Javascript. Anyone here have recommendations for tutorials or guides for quickly learning Javascript and React? Always been interested in creating basic little multiplayer games that can be locally hosted, like a non-faggoty version of roll20.
 
I have a basic knowledge of C (yes, C, not C++ or anything like that) and HTML. Recently I've wanted to start learning Javascript. Anyone here have recommendations for tutorials or guides for quickly learning Javascript and React? Always been interested in creating basic little multiplayer games that can be locally hosted, like a non-faggoty version of roll20.

JavaScript's syntax is pretty similar to C, so you're off to a good start. Just forget about strict typing and learn about the dictionaries that JS calls "objects." (Newer strains of JS have something closer to proper OOP but it's still new enough that it's not yet entirely common to see it used on client-side code.)

I suggest ignoring React for now (and preferably forever). Learn to walk before you try to ice skate (with anvils for skates on the thinnest of ice). At any rate, get it working with just simple HTML elements and inputs before you worry about making it pretty.

Learn to use the dev tools in your browser of choice if you haven't already. All three browser engines include very helpful debuggers and REPLs that are sadly more capable than the equivalents for most other languages you can think of.

I don't have recommendations for specific tutorials, but developer.mozilla.org's JS reference site is invaluable, so I suspect their tutorials may be of similar high quality. Whatever you use, if it doesn't mention the "let" and "const" keywords alongside the "var" keyword, it's too old. If it mentions "Node," it's teaching you server-side JS, which may also work on the client side for a while until it doesn't. If the code is calling a function with the name of a dollar sign, like $("#foo"), it's assuming you're using jQuery, a library that was incredibly helpful with smoothing out the quirks and differences between browsers back in the IE 5-8 days but isn't quite as useful nowadays that browser engines behave more similarly and predictably than they used to. Whether you choose to use jQuery in (almost) 2022 is up to you but I don't use it at all for new projects anymore. At any rate, be sure to at least learn the basics of JS without jQuery first so that you at least understand what jQuery is doing for you under the hood.

When you start using fancier APIs, I suggest checking Can I Use to make sure you're not wasting your time using something so new that a significant number of your visitors' browsers won't support it. Also, CDNJS and jsDelivr are two of a handful free CDN services that host JavaScript libraries. Even if you don't use the CDN part, their search tools can be useful for finding a certain library you're looking for.
 
I suggest ignoring React for now (and preferably forever). Learn to walk before you try to ice skate (with anvils for skates on the thinnest of ice). At any rate, get it working with just simple HTML elements and inputs before you worry about making it pretty.
This. JavaScript can be quirky enough on its own that trying to learn it alongside React is going to make things so much harder for you. JavaScript first, then any UI frameworks.
 
I have a basic knowledge of C (yes, C, not C++ or anything like that) and HTML. Recently I've wanted to start learning Javascript. Anyone here have recommendations for tutorials or guides for quickly learning Javascript and React? Always been interested in creating basic little multiplayer games that can be locally hosted, like a non-faggoty version of roll20.
While I can't give general advice as well as @Least Concern's post, I can recommend Eloquent JavaScript by Marijn Haverbeke. In fact you can read it on-line legally at https://eloquentjavascript.net/ As its table of contents shows, it focuses almost exclusively on the language itself and programming concepts, dealing only with Node.JS as the last two chapters. The writing is clear and does not treat the reader like a child, although there are bits of "quirkiness", and the on-line version allows you to work directly in browser with the examples and exercises.
 
So Jersh is writing a new forum system with blackjack and hookers in Rust. I don't really know much about Rust so let's have a look, shall we? From this docs page:

Code:
use rand::Rng;
use std::cmp::Ordering;
use std::io;

fn main() {
    println!("Guess the number!");

    let secret_number = rand::thread_rng().gen_range(1..101);

    println!("The secret number is: {}", secret_number);

    println!("Please input your guess.");

    let mut guess = String::new();

    io::stdin()
        .read_line(&mut guess)
        .expect("Failed to read line");

    println!("You guessed: {}", guess);

    match guess.cmp(&secret_number) {
        Ordering::Less => println!("Too small!"),
        Ordering::Greater => println!("Too big!"),
        Ordering::Equal => println!("You win!"),
    }
}

The io::stdin().read_line() bit is interesting. It's returning an enum with either "Ok" or "Err" "variants" (as Rust calls them), and in the case of the latter, calling the expect() method causes the program to crash after outputting the passed string as an error message. That's about the only idea here that I like.

What sucks? println!() is an obvious one. Apparently methods with exclamation marks in Rust are actually macros; the code around its parameters gets expanded to several other lines of code when compiled. The function to print a line to the terminal is not a built-in or stdlib function. Apparently this is necessary because as you see println!() does both line-printing and string formatting, and Rust doesn't natively support variadic functions (functions with an arbitrary/undefined number of parameters), but they can be faked with macros. And rather than just having it be a function which takes a string and an array of strings to do the placeholder replacement with or some other sane alternative, they decided they'd implement it with macros and you can just litter your code with exclamation points and fuck off.

Next, the intermingling of OOP-ish concepts with snake_case. We Ruby now bois. Speaking of which, I'm confused what significance the capitalization has in the namespacing. I suppose I can look it up like I did with the exclamation points but I'm getting annoyed already. And why do we use rand::Rng; but then never actually use Rng anywhere?

let mut guess. The "mut" keyword makes the variable mutable. I don't like the idea of immutable variables because we already have a word for those and it is "constant." JavaScript actually does something right by having separate let and const keywords for variables and constants rather than keyword-stacking.

&. We're explicitly passing by reference twice in this bitty code sample. I much prefer languages that just pass everything by reference, but whatever; why in the first instance do we have to do &mut guess instead of just &guess?

For now, all you need to know is that like variables, references are immutable by default. Hence, you need to write &mut guess rather than &guess to make it mutable.

…Fuck me with a shovel. If you pass a variable by reference, it becomes a constant unless you add a keyword to make it otherwise. The fuck?

Well, whatever. I guess we'll finish up by doing enum bullshit to compare the guessed number with the random number because > and < and == are for plebs, fuck you.

Rust at first glance looks noisy and over-complicated - much like the troons that use it, I guess.
 
Last edited:
What sucks? println!() is an obvious one. Apparently methods with exclamation marks in Rust are actually macros; the code around its parameters gets expanded to several other lines of code when compiled. The function to print a line to the terminal is not a built-in or stdlib function. Apparently this is necessary because Rust doesn't natively support variadic functions (functions with an arbitrary/undefined number of parameters), but it can be faked with macros. And rather than just having the second parameter be an array or something, they decided that's how they'd implement println and you can just litter your code with exclamation points and fuck off.
That's how C's printf works too.
 
  • Disagree
Reactions: Kosher Dill
Rust at first glance looks noisy and over-complicated - much like the troons that use it, I guess.
I'd never really looked into it so thanks for the summary. Something about Rust and its cult of Redditors just creeps me the fuck out on a pragmatic level. Rust aficionados seem to get a sexual thrill from rewriting perfectly-good software in Rust just so that they can say that they coded it in Rust.

It's obvious what happened, I think. We obviously didn't smack the Haskell faggots hard enough and now they've all bailed to their new meme language.
 
I'd never really looked into it so thanks for the summary. Something about Rust and its cult of Redditors just creeps me the fuck out on a pragmatic level. Rust aficionados seem to get a sexual thrill from rewriting perfectly-good software in Rust just so that they can say that they coded it in Rust.

It's obvious what happened, I think. We obviously didn't smack the Haskell faggots hard enough and now they've all bailed to their new meme language.
One of the "value propositions" in Rust is "safety" which makes you wonder how correlated it is to modern safety culture in general.
Its reason to exist is lowering barriers to entry to systems programming by solving memory management for people who can't remember what sex they were born in.
It's just OCaml with shit syntax and a pedantic compiler instead of GC and crappy async
 
varargs in C are implemented with macro fuckery.
Access to varargs is typically done via macro, but in terms of implementation varargs are the same as any other function argument. They still come in on the stack, the compiler just doesn't automatically give you variables with their names, types, and addresses like it does for named parameters.
The contrast here is supposed to be versus having the macro preprocessor spit out a 7-argument copy of your "function" inline if you call it with 7 arguments.
 
Back