Multiplatform?

[Dominaezzz]

I want to use this library in a multiplatform application.
Since the bulk of this library is written in pure Kotlin, going multiplatform would be fairly trivial.
The only possible issue I can think of is that JitPack may not work with it, breaking current users.
Would need to setup build for all platforms to publish to Bintray or Maven central.

[elect86]

With pleasure, however JitPack is enough for me at the moment

I know Bintray and Maven require going throw so much pain that makes me giving up.

But if you want to try, you are very welcome.. I sent you an invite :)

[Dominaezzz]

Ah sweet, I'll give it a try. I also just noticed it has a dependency on kotlin-unsigned, which will have to go multi-platform too. Unless you're thinking of migrating to kotlin's unsigned types.

[Wasabi375]

There is another problem you have to solve first. I think the way we handle native memory is dependent on lwjgl or at least dependent on java.nio. I don't think there is a multiplatform version of any of those. I think it should be possible to move all those dependencies to the jvm version, but I'm not sure how much work this is actually.

[Dominaezzz]

Well, I just did a search for ByteBuffer and it looks like there are a couple options. Migrate them to use kotlinx.io.core.IoBuffer which is multi-platform (except for android native), abstract away the JVM specific bits into a separate jvm "extension" library or only implement the java.nio related parts in the JVM source set.

How much do you care about breaking changes?

[Wasabi375]

I personally don't care. If we go multiplatform IoBuffer seems like the best choice for the future even though it's still experimental.
As for breaking changes, I don't think they will be any problem.

[elect86]

Oh man, I lost the reply mail..

anyway @Dominaezzz, the limitation with the stdlib unsigned is that they dont extend Number because inline classes cant extend classes, I explicitely asked to change Number to interface, but my request was turned down because it didnt seem like an issue for them

Extending Number is cool because you can pass it as generic and then converting to the type you want.

We may discuss if this is actually useful also for unsigned.. maybe we could switch to stdlib unsigned and make unsigned vectors somehow special compared to the others.

Regarding breaking changes, I personally repute that if the change makes sense, then we should just go for it

Although I'd pay attention for any regression performance-wise

[elect86]

any news, @Dominaezzz ?

[Dominaezzz]

I made a branch with some changes. Have you looked at it?

[Dominaezzz]

The current code is a bit of a tangle of interfaces, which is quite bothersome to make multiplatform. Would be easier to wait for io-2 or make the library more kotlin "friendly" (less like the C api). The former being easier.

[elect86]

I made a branch with some changes. Have you looked at it?

Yep, they are only confined to gradle or?

The current code is a bit of a tangle of interfaces, which is quite bothersome to make multiplatform. Would be easier to wait for io-2 or make the library more kotlin "friendly" (less like the C api). The former being easier.

I'm totally available to change the current structure if it makes sense.

By io-2 do you mean kotlin.io? is there already an ETA?

[Dominaezzz]

Yes, the new revamped kotlinx-io. It should be released sometime around Kotlin 1.4 release.

Oh, maybe I didn't push.
Structural changes would be required, it's been a while so I don't remember what exactly needed to change. I just remember pulling interfaces into common code required pulling so many other things at once.

Also, dependencies would also need to be made multiplatform. unsigned won't work well with Kotlin native, there would be a fair bit of copying involved.

It's a bit of work.

[elect86]

Yes, the new revamped kotlinx-io. It should be released sometime around Kotlin 1.4 release.

Where is possible to read something about that?

Oh, maybe I didn't push.
Structural changes would be required, it's been a while so I don't remember what exactly needed to change. I just remember pulling interfaces into common code required pulling so many other things at once.

What would you do then? Top functions inside the glm package?

Also, dependencies would also need to be made multiplatform. unsigned won't work well with Kotlin native, there would be a fair bit of copying involved.

Problem with the stdlib unsigned is that they do not extend the Number abstract class..

We could keep unsigned a jvm-only dep

[Dominaezzz]

Where is possible to read something about that?

The most official thing I can point to is the Kotlin 1.4 blog. Other places would be hand wavy estimates from Kotlin devs in Slack.

What would you do then? Top functions inside the glm package?

You would need to make a lot of the member functions into extension functions or top-level functions. This would make the library not very nice to use from Java.
You could start moving the smaller interfaces into common code, I'm not very familiar with the library so I wouldn't know exactly where to start.

Problem with the stdlib unsigned is that they do not extend the Number abstract class.

I understand the need for this but using Number means boxing very often. Also, I guess there isn't much Kotlin devs can do about it, it's a Java api. 🤷‍♂️

[elect86]

You would need to make a lot of the member functions into extension functions or top-level functions. This would make the library not very nice to use from Java.

No other ways?

Otherwise we can theoretical have the top level functions as the real multiplatform core and the jvm interfaces would just point to those (maybe inlined)

You could start moving the smaller interfaces into common code, I'm not very familiar with the library so I wouldn't know exactly where to start.

Ok, let's start with the projection matrix functions, if you can prepare the structure and point me to the right location I'll move a couple of those

I understand the need for this but using Number means boxing very often. Also, I guess there isn't much Kotlin devs can do about it, it's a Java api. 🤷‍♂

Yeah, but the convenience is huge. Otherwise we shall write a lot of boilerplate code (or auto-generate)