cpdt

And to elaborate on how the error message relates to this: std::addressof takes a reference which also can’t be null. So when you dereference the pointer you’re actually turning it into a reference (or binding the reference to the pointer, as the error message says).

From what I've heard, when dubbing shows they normally adapt the translations for the dub to fit better with the character's mouth movements and to make it more 'idiomatic' in the target language, but the subtitles keep the literal translation. It would be interesting to learn why, I find it drives me crazy as well.

I think jqbx.fm is what you’re looking for. Only works with Spotify Premium from what I’m aware though.

Since the OP is specifically talking about Discord, it’s worth mentioning that what you’re talking about doesn’t seem to be the case for them - they make money from Nitro subscriptions and their game store, and state in their privacy policy that they are “not in the business of selling your information” (https://discordapp.com/privacy, in the section ‘Our Disclosure of Your Information’).

So relating back to the post, their justification doesn’t necessarily make it right, but I think it’s incorrect to attribute it to a malicious cause.

Just had a look, and it turns out that's including running LLVM's optimizer as well, which takes roughly half the time. It's basically doing the equivalent of -O2 currently. That's probably more aggressive than what's needed, but I haven't taken the time to fine-tune it yet.

Other than that, you're right that it might be a bit high. There's very likely parts of the lowering code which can be optimized, I just haven't had the need to yet.

I'll look at writing that blog post soon then :)

Just did some proper testing on a reasonably complex project, looks like I was about an order of magnitude off (to be fair it was 2AM here at the time, and I wasn't reading the numbers right haha). 30-40ms is still fast enough that you don't notice for the most part though. For this specific project, it breaks down roughly like this:

- ~1ms to build the new MIR based on the editor state

- ~5ms to process/run passes on the MIR (this involves some funky graph traversal which could very likely be optimized a lot)

- ~12ms to generate LLVM IR

- ~14ms in the LLVM JIT

In a project that makes good use of groups (nodes that contain a surface inside and then expose some controls back out) I'd expect this to be lower, since we only need to perform those operations on the surfaces that change.

Yes, this was one of the initial inspirations for the design of Axiom! I never actually had the chance to play with it though... would be quite interested in learning how it works.

Yeah, you're not wrong that it's pretty dark. I have done a bit of work recently on lightening up (it was even darker before!), but I'll definitely look at brightening it further in the near future.

Yeah, it works quite well. In my case, I used ‘ExternalProject_Add’ to run the builds through Cargo, then setup a static lib target with that as a dependency, linking to the files built by Cargo and a few system libs it expects. From there you can treat it like any target in Cmake, and it just works(tm).

Edited for clarity

I haven't actually properly played around with PureData (other than watching a few videos on it back when I started this project), so I can't really comment too much on how that compares.

I was initially worried about how interactive compiling would be, however it turns out (at least with the projects we've tested it with so far), it's pretty easily able to keep up with around 3ms from a modification to codegen being complete. The LLVM IR we generate is pretty simple which helps, and we also try to only recompile as much as possible by putting everything in separate LLVM modules (hurts runtime performance a bit since we can't optimize across modules, but it doesn't end up mattering too much).

The graph operates per sample - we really needed that feature to be able to do feedback loops, for things like FM synthesis.

Edit: I started adding in an explanation of Axioms architecture in the hope that someone with knowledge of similar projects could chime in, but it was getting quite long... might look at writing a blog post on it sometime soon, if people would find that interesting.

Yep, that was one of the original ideas with using LLVM. The actual runtime that's needed is pretty small and the code optimizes well, so the output ends up being very close to if you'd written the code in, say C++, yourself.

But that said, I haven't actually gotten to writing the 'exporter' yet (up to this point I've mostly been focused on usability and stability), so I can understand that it's not entirely clear.

Hey friends!

This is a project I’ve been working on since the start of the year. We’ve just released 0.4.0, so I figured now would be a nice time to start making it a bit more public. There’s a bunch of interesting tech under the hood which I thought you all would definitely be interested in :)

Axiom’s a project that grew out of my third try at building a realtime software synthesizer for 64k intros in the demoscene. You can’t really fit an mp3 file in an executable that small and expect for it to sound any good, so instead we synthesize the audio and play it in realtime. A few other groups have written synthesizers for 4k and 64k productions, however I built this for two reasons: I wanted to make one myself, and I wanted to try some interesting things with combining node graphs and basic scripting. At some point, however, I realized that this could actually be a really useful tool for any musician to have, since it really flips things on its head and allows much more control than just stringing together a bunch of plugins (the question is, of course, do people who make music _want_ this control - I'm not sure on the answer yet).

Technology-wise, Axiom compiles 'node surfaces' with LLVM (no interpreters here, the code has to run comfortably 44100 times per second!). The editor, written in C++ with Qt, builds a MIR and passes it into the compiler, written in Rust. This was my first large project in C++ and first project in Rust... ultimately I think the Rust learning curve has definitely been worth it, as it's by far the stablest part of the program!

Ultimately I’m hoping to somehow be able to turn this into a real product, possibly by offering what you see as the core open-source software and then building on it, into something like a DAW or plugin for procedural audio in game engines (which a few people have suggested to me, and I think would be a really cool application of the technology!).

Check it out, let me know what you think (either here, or shoot me an email, chat on twitter, etc), ask questions, build something cool, have fun!

I have a super-beta build working, if you'd like to try it out/help bugfix shoot me an email at "copodt at the google email" and I'll send it to you :)

You're right that many demos simply exist to showcase technical brilliance, but many in the demoscene are starting to trend further towards expressing artistic ability. Some examples off the top of my head:

- Number One/Another One by CNCD/FLT: http://www.pouet.net/prod.php?which=77399

- When Silence Dims the Stars Above by Conspiracy: http://www.pouet.net/prod.php?which=75713

- Aurora by Excess: http://www.pouet.net/prod.php?which=75791

- Along for the Ride by Ümlaüt Design: http://www.pouet.net/prod.php?which=78053

Have you heard of the demoscene? The modern scene is, to a large degree, art as a computer-based audiovisual experience rendered in real time.

Previous discussion (on the video): https://news.ycombinator.com/item?id=17637834

What about Mercurial?

I think roenxi is referring to how the Fukisima nuclear accident wasn't the biggest deal that day, as the tsunami had a far greater impact (0 vs 18 500 direct casualties, respectively).

Correct, but it's still possible for the parent page to overlay invisible textboxes and buttons in order to capture input.

Especially in 64ks, assembly isn't particularly necessary - limited use of the standard API and a good exe packer will almost always get you under the limit (especially when a lot of your code is GLSL, as text compresses well).

Smaller intros like 4ks, on the other hand, will often use assembly (although completely shader-based ones are becoming more common).

I made a small project back when WSL was new to help tackle this, called Slinky: https://github.com/cpdt/slinky/

It allows you to run a command in the Windows prompt to 'link' a Linux command to a Windows one, allowing you to run the Windows command to run the Linux command (if that makes sense; the GIF in the Readme is probably better at explaining).

It's written in Bash and Batch so doesn't require external dependencies.

> I could imagine RTS style games or mods where you not only have to scavenge for resources, you also program your bots to do your bidding, like Dwarf Fortress with programmable drones instead of independently-minded Dwarves.

Sounds sort of like Screeps [1]. It's an MMO game where you write scripts in JS to control different robots (so, not logic programming, but still pretty fun with lots of depth). Parts of it are also open source [2].

[1] https://screeps.com/

[2] https://github.com/screeps/screeps