Morning.

Lies

Yes, served fresh all day. May I pour you a cup?

It turns out including modules or just files in JS is ridiculously complicated. I almost regret using ANTRL, though it's not entirely their fault.

I thought C++ was the worst at including libraries and that therefore other languages would be better, especially when it comes to JS which has been behaving surprisingly well so far.

@Tyyppi_77 It turns out that doesn't work in browsers. At least not in the const stuff = require('stuff') way. But that's the way ANTLR wants it.

@nwp I find that to be true of dealing with files in general: it gets complicated, it's not their fault, I have regrets about using/needing them.

ANTLR promised to generate parsers that are roughly 10% the size of a handwritten recursive descent parser. Unfortunately they also require a 50 file runtime environment to make that parser run.

Much more rarely, I find something that abstracts away the complications, and initially I'm glad for that, but it almost inevitably paints me into a corner somehow & turns out to be an equally big hassle to deal w/ after all.

@Pikalek That's a natural law I think. The solution to every problem produces a new problem of equal complexity.

I think Einstein said that. Or maybe not.

"You can attribute whatever you want to anyone" - Confucius

I think I have very strong confirmation bias, but I see that actually hold surprisingly often.

For sufficiently poorly defined metrics of "equal complexity".

It seems like I immediately get punished for implying C++ build systems are not the worst. It turns out one library has a file with the same file name as another. And since build systems are garbage and dump all object files into a single directory I get one of the file's definitions twice and the other not at all.

Ugh, that sounds gross to deal w/. Sucks when tools create problems instead of solving them.

Boost is also great. It has a bootstrap.bat that picks out MSVC and gets ready to build. But I wanted gcc. Thankfully at the end it tells me what to do:

Bootstrapping is done. To build, run:
    .\b2
To adjust configuration, edit 'project-config.jam'.

And the project-config.jam indeed has using msvc ; you can replace with using gcc ;. Awesome. Except the bootstrapping tool overwrites the config.

I guess I'll attempt to just let it configure with MSVC and then build with gcc? That sounds really wrong.

Gotta love seeing those std::auto_ptr warnings.

It's also fun using code that compiles in MSVC and gcc complains about taking addresses of temporaries.

Writing proper software is so difficult.

Lets say we only have one Vector3 as some sort of object-position and another Vector3 as a position we are moving towards. Theres also a system which interpolates the object position towards the target position. We want to fire an "Start moving" event once the object started moving towards its target. Is this possible without an history and inside an ecs ? I just cant find a condition that fits :p but probably its just not possible

Thats "Moving", "Start moving" is the first time an object changes its position after it reached its destination. The more i think about this, the need for some sort of history increases.

Well... Because we dont know if the target position changed. Theres no notification for this inside an ecs, and i dont wanna fire extra events by my own, thats why i hoped theres a cleaner solution for determining the exact point when a position starts to interpolate towards a target

Hmmm... thats a good idea, thanks :)