Yep. It's really fascinating. MS is much more common (and well-known) so even though the diagnostic criteria can get quite complex (because you have to eliminate any other potential case), it's a well-trodden path.
So it's great that with anti-NMDA there is an actual singular test to determine this, but given it's so rare and little-known, getting to that point is very much not given :-(.
What BurntSushi said regarding these things being very nonspecific is absolutely true here.
E.g. Multiple Sclerosis can very well fit what you're describing, too. Commonly, there's a flare-up (we commonly use the term "attack" funilly enough)of some neurological symptoms (numb limbs, tingliness, diziness, vision issues are very common) that can last a few days/weeks and then mostly or completely subsides (until the next time).
Absolutely not suggesting that's what it was, just that it is what it could be too (or many other things — auto-immune diseases in particular can be really broad and nasty).
Sushi, I'm so glad you're doing better. Some of what you said (including just writing about it for awareness and sharing) resonates with my MS experience. I'm sorry you've experienced this and I hope things will keep looking up! <3
Thanks for this! I want to check the WEB-inspired approaches at some point, this is super useful.
The Markdown one seems interesting too.
I'll probably stick with this for stuff where there's some expectation of drive-by contributions (the tutorial has seen a bunch, it was one of the motivations behind this) because requiring additional tooling can often be a bar that's too high.
Agreed on the general literate programming note. I'm not sure I'll ever pick it up for something that doesn't have an obvious accompanying article/book to come with it, but if I ever write another tutorial or something, I'll definitely use it from the beginning.
But knowing what's out there is definitely important (and AsciiDoctor is extensible so these things could probably be added as plugins).
This comment feels like a bit of a non-sequitor, but I agree. Cogmind is amazing, my own roguelike is quite abstract and a lot of the ones that really gripped me are not yer classic orcs and trolls.
If this is the reaction to the theme in the Rust tutorial that the original post talks about, that's because it's basically a port of the classic Python+libtcod one. It implements the same game, but walks the reader through doing it in Rust.
I (not OP but the author of the article and the Rust tut) wanted to use the same game & structure so folks can compare and contrast. A lot of folks are coming from Python or are familiar with libtcod. Plus it's trained generations of RL devs for better or worse.
If you do want to see roguelike creators experimenting, check out the annual Seven Day Roguelike Challenge[1]. Lots of absolutely amazing stuff keeps coming out of that, including most of my favourites.
For what ever it's worth, anyone looking into starting a roguelike in Rust would probably do much better by folloving the The Bracket link above.
In addition to it being a pure Rust library (which does make a difference when you get started, but also when you try to distribute your game) it compiles to WebAssembly as well meaning you can use the same code to produce a game that runs on the desktop and the web. And the tutorial covers much more ground as well, including ECS for those interested.
And finally, both the tutorial and tcod-rs are barely maintained anymore. I try to address questions/fix serious issues from time to time, but the chances of this seeing any significant developments in the future are very slim. The RLTK stuff is actively maintained and developed.
(I'm not the OP, but I did write the linked post, the tutorial -- which is based on the classic Python+libtcod one as well as started tcod-rs)
I was about to say a similar thing. Yes, in a CS-sense anything you can do in one Turing-complete language you can do in any other Turing-complete lang. They almost certainly were not disputing that.
If you factor in the real world, the number shrinks as you get to things like performance, cross-platform support, ease of packaging and distribution.
But still, Nu could plausibly have been written in Assembly, C, C++, D, Go, Nim, Zig, Haskell and so on.
You would have lost some of Rust's strengths and weaknesses and imported another set (regarding the language, tooling, performance, ease of debugging and so on).
I took the comment to mean that as far as they (all people intimately familiar with the language, tooling and ecosystem) are concerned, this would be a trade-off that would be negative enough to not begin or finish the project in the first place.
I don't know what plans and requirements the Nu authors had. But for my own game (a roguelike written in Rust) the requirements on the performance, distribution, stability, ease of development and dependency management meant that Rust was (at the time) pretty much the only viable choice for me.
Could someone have written it in C? Sure. Could I have written it in C? Likely, yes. Would I have ever finish the game in C? Almost certainly no. For various reasons none of the other languages would have done in those circumstances, not really.
Human language is an imperfect method for transferring information and sometimes one trades off brevity for nuance.
(disclaimer: not a physicist, never looked into the maths, but I'm intrigued by QF)
There are deterministic interpretations that are very much on the table.
The Everett's Many Worlds[1] is fully deterministic (and depending on your view, the simplest one too): the universe is a quantum wave function evolving according to the Shrödinger's equation. That's it.
A lot (if not all) of the hidden variables theories are also deterministic. The apparent non-determinism stems from the aforementioned variables that we don't/can't see.
I keep hearing more and more about the Pilot wave theory[2] recently. And that's a hidden-variables deterministic interpretation.
Having them side by side, you can see that they contain the same vertical amount of space. Inconsolata's glyphs are smaller, but they're still in the box of the same height.
It does seem that the "font size" only refers to the height, though. The width is clearly variable.
To anyone who actually understands this properly: is the above correct or is that just an artefact of how the website renders the text?
(disclaimer: I work at Red Hat, not on any OS/distro)
This is a nitpick, but Red Hat did not get bought by IBM. What happened was IBM announcing the intention to buy Red Hat.
It's maybe a subtle, but possibly important distinction. Red Hat is still its own independent entity until the deal goes through (which means IIRC passing the board's approval, SEC and likely other stuff). This is expected to happen in late 2019 I believe, but it might still fall through.
This doesn't absolutely dispel any possibility of IBM's influence, but it should be very low/zero until the merger actually goes through. But I also don't know how all this works.
I haven't the faintest idea, which is why I asked aphextron. Indeed, until today I thought the Unreal Engine was FOSS, but seems to be just source-available. That said, didn't id Software / John Carmack release a bunch of engines under FLOSS licenses in the past?
There are many more or less serious potential explanations: not enough people care, it wasn't (or still isn't) financially feasible, the people able to develop AAA engines are actively against sharing source or ideas, there's an engine development cartel actively pushing against it to keep their revenue.
Or it might just be a social or historical accident -- we may just have been extremely lucky with Linux and projects on that scale will never come again.
Or maybe everyone thought it would be a great idea but they also thought it would never work and so no one seriously ever started an open source engine. Maybe Godot will be a true AAA engine that will surpass them all in a few years.
To be fair, it is a really difficult thing to read and comprehend. I've read the whole proposal around May this year, and it is tough. When I did get to the articles 11 and 13, a lot of the stuff people were really warning against wasn't even there.
It was in a reference to another law, already passed years ago and only referenced by its number. So you had to look that up and any references it had, too.
And at the end of it, you're still left with a deep unease that you've probably missed a lot of data and meaning because these things don't seem to be written in a way non-layers can understand.
To add a specific example here, I've recently compiled a roguelike I'm working on to WASM, not knowing what to expect when I started.
This required only a handful of changes across the codebase (mostly handling external resources such as the filesystem and the random generator) and then implementing a bit of JavaScript that took the drawcalls from the WASM core and rendered them on the canvas. And vice-versa, a bit of JS that passed the browser input into the WASM game.
Since the original game had no concept of a DOM, it didn't matter to it. I think WASM can be huge for browser games.
But like Steve said, you can call any JavaScript function and manipulate the DOM that way. At least for Rust, there's also a library that does this for you. So you can have Rust code that uses a DOM API and the WASM <-> JS bridge is handled for you:
So it's great that with anti-NMDA there is an actual singular test to determine this, but given it's so rare and little-known, getting to that point is very much not given :-(.