How do I go about using the different versions of count leading zeroes from GCC and VS2017?
do I need some #ifndef,#define,#endif?

Successful build - Chance fights ever on the side of the prudent.

Successful build - Chance fights ever on the side of the prudent.

Successful build - Chance fights ever on the side of the prudent.

Successful build - Chance fights ever on the side of the prudent.

Successful build - Chance fights ever on the side of the prudent.

Successful build - Chance fights ever on the side of the prudent.

use default case

Successful build - Chance fights ever on the side of the prudent.

It's good to make it consistent.

Successful build - Chance fights ever on the side of the prudent.

use a switch (thanks @elexis)
rearange code in iife a bit neater

Successful build - Chance fights ever on the side of the prudent.

Fix function selection

Successful build - Chance fights ever on the side of the prudent.

Successful build - Chance fights ever on the side of the prudent.

In D3807#225157, @vladislavbelov wrote:

So we should guarantee that RunJobs will be called at the right moment and from a proper thread.

Yes.
Everything related to the scriptContext should be run in the proper thread.

In D5281#225155, @phosit wrote:

GetUsage is mostly used with IBuffer::Usage::DYNAMIC. Maybe the IsDynamic should be kept to deduplicated thous. That would make this diff a lot smaller.

I was thinking about that but didn't decide.

In D3807#225134, @phosit wrote:

I'm not sure what you want to ask. A naive answer: the continuation is executed _after_ the promise settles.

So we should guarantee that nobody will call RunJobs at the right moment and from a proper thread.

Looks sane at a first glimpse. I didn't test yet.

Successful build - Chance fights ever on the side of the prudent.

In D5276#225132, @phosit wrote:

Yes a27 isn't released yet...
Or do you think thous functions should be removed in a27?

In D5281#225145, @Stan wrote:

Maybe you could add a new type like storage_usage_t or something.

A more narrow type is preferred indeed. But it requires additional steps (mentioned in the inline comment).

Maybe you could add a new type like storage_usage_t or something.

Successful build - Chance fights ever on the side of the prudent.

In D3807#225124, @vladislavbelov wrote:

In D3807#225078, @phosit wrote:

It's not possible to run promise-continuation concurrently. (promises as such don't "run")

Sure. What I'm worrying about is the order of continuation and fulfilment.

I'm not sure what you want to ask. A naive answer: the continuation is executed _after_ the promise settles.

In D5276#225122, @vladislavbelov wrote:

But this should be commited afther a27 is released to let modders addopt.

Is that still relevant?

Yes a27 isn't released yet...
Or do you think thous functions should be removed in a27?

In D3807#225078, @phosit wrote:

It's not possible to run promise-continuation concurrently. (promises as such don't "run")

But this should be commited afther a27 is released to let modders addopt.

Is that still relevant?

Successful build - Chance fights ever on the side of the prudent.

RunJobs in other places. (every turn and every frame)

It's not possible to run promise-continuation concurrently. (promises as such don't "run")

So it's possible to use promises in the simulation code. Is it possible if they're running concurrently?

It doesn't prevent that.

How the diff avoids using promises in the simulation code?

Successful build - Chance fights ever on the side of the prudent.

Successful build - Chance fights ever on the side of the prudent.

change forestTreesAround to forestTreesSurrounding

In D3807#224715, @phosit wrote:

Actually we could use iteraables instead of promises: Mostly replacing await with yield*.
That way the tasks would be cancelable. And would force users to use the structured aproach.

The downside is that js-devs are more familiar with await when it coms to asyncronous programing. Also the aproach with iterators would be polling which is likely slower.

I'll commit it soon.

In D5244#223224, @Stan wrote:

So what happens here exactly when it cannot find the shader file?

This functions are deprecated for over a week now. I think it's time to remove thous functions XD

It's better to mentioned related changes explicitly.

Successful build - Chance fights ever on the side of the prudent.

In D5269#224957, @Stan wrote:

I wonder how many files are affected.

Not that many. From a quick count, there are around 10 files with olists in the game whose column's property would have to be changed, plus around 3 files implementing the feature.

Successful build - Chance fights ever on the side of the prudent.

rebase

Successful build - Chance fights ever on the side of the prudent.

Successful build - Chance fights ever on the side of the prudent.

Change descriptions again

By the way I could not find any drop in replacement for that lib, and the new version of it is significantly bigger and also under GPL3 and not 2 which sucks.

In D5254#224728, @Stan wrote:

Also how does the other code that uses mongoose use it ? That would be profiler2 not sure if there is something else.

In D5252#224725, @sera wrote:

The global header with the wfg styling I'd only use for global icons and links like forum, web, trac, irc and so forth; don't think reusing the global header style for application headers is a good idea.

Successful build - Chance fights ever on the side of the prudent.

This is not gonna be fun to fix in mods. But yeah probably needs another diff before this one.
I wonder how many files are affected.