A modern programming language that makes developers happier.

kotlinlang

Hey <@U8NMFHUGJ> are there plans to update <https://github.com/touchlab/cklib|cklib>? We started using it when we were working with the Touchlab team to help jump-start our SDK. I've noticed the note,

&gt; The main Kotlin project has changed how locally embedded C-like code is included in libraries. Use this project if you'd like, but outside of private projects we won't really be supporting it much.
And was wondering what the alternative is. Where should we be looking?

It _appears_ to work in Kotlin 1.8, but we're having test failures in native wrapper code that didn't previously fail pre-updated. I am unsure of whether the issue is caused by Kotlin native changes or cklib's compatibility with 1.8.

We don't have definite update plans right now. It's no longer part of the Kermit/CrashKiOS stack which was our main use-case internally. Kevin can probably speak better than I can to what good alternatives are, but he's on vacation this week so I'll try to draw his attention here when he gets back.

Thanks <@U2VU05RC4>, I appreciate the response :slightly_smiling_face: Interested in getting more information, or just a suggestion at an alternative we can use if cklib is no longer supported.

On vacation. Shakey wifi. We don't support cklib because the projects that need it are rather complex, generally speaking, so it's drifting towards more of a "paid support" situation. Cklib has a problem with 1.7.x and some watch architectures, but we never used those. 1.8 seems ok. This is the only public use of cklib at this point: <https://github.com/cashapp/zipline/|https://github.com/cashapp/zipline/>.

Hey Kevin, no need to respond on your vacation, we'll survive :slightly_smiling_face:

For when you're back, the errors are actually not hard errors, but soft ones. Basically, a number of the functions we're interfacing with from the C code no longer return the expected values (they just return 0 or empty string). We are wrapping generated FlatBuffers C code (`flatcc`) in a common interface and the tests no longer pass on native. The switch is as clear as day due to `1.7.10` --&gt; `1.7.20`. We're already on the `experimental` memory model in `1.7.10` so the change to `1.7.20` shouldn't have done anything big. _And yet_

And as far as platforms we've observed this on at least `macosArm64` and `linuxX64` and haven't tried other platforms.