Vsevolod Tolstopyatov

> it's supposed to be the supported path for this library. `atomicfu` is more or less experimental and was always developed for our own needs, not for public use. This...

It's unlikely we are going to implement regular atomics transformation. The number of "bugged" devices in use is reducing each year and without them, such change has no benefits, only...

Thanks! We are working internally on guarantees that we are ready to provide for each individual target (as well as the overall understanding which targets we are going to support)...

Unfortunately, `kotlin-android` and `com.android.library` interact in an unpredictable way that prevents major libs from updating (#103, as well as few other libs I've tested). Unfortunately, I'm short on time in...

The first bug in the implementation is its non-laziness, which misses the applied kotlin-android plugin in some scenarios (the expected way to check is `project.pluginManager.hasPlugin(...)`. The problem itself is deeper...

No need to hurry, bugs happen. I've rather posted it here so it's easier to catch the fix when somebody is ready to work on it

Unfortunately, we cannot merge it as we weren't yet updated to Java 8 and our internal experiments have shown that there is a lot of potential impact to handle

After the complete channels rewrite and six years down the road, we still have decided not to `yield` forcefully, delegating this solution to `Channel` users who know better whether their...

Thanks! Will take care of it during this week

I've started the internal testing (mostly our internal projects, Ktor and some Android apps) process and, as soon as all perturbations are resolved, will publish the dev build for everybody...