Lets say hypothetically Kotlin WASM gains the abil...

# webassembly

[napperley]

Lets say hypothetically Kotlin WASM gains the ability to port a Kotlin Native library (incl ones that provide a Kotlin binding to a C library) over to the platform. How would the porting process work? This hypothetical situation came about out of what was done with Rust and the LVGL ( https://lvgl.io/ ) library to port it to WASM ( https://forum.lvgl.io/t/rust-bindings-for-littlevgl/2386/12 ).

[Svyatoslav Kuzmich [JB]]

Hypothetically:
1. Port libraries that provide C api to be compliable to Wasm, unless they are already ported. This would depend on the library language C, C++, Rust, etc. and its dependencies.
2. Replace K/N specifics with common code and expect-actuals. It would hypothetically make sense for K/Wasm to have a C interop similar to K/N, but it may end up having some limitations and deviations.

[napperley]

From a hypothetical impression the K/N library would need to be mostly rewritten as a K/W library that taps into the common code as mentioned, and uses the WASM version of the C library. Seems as though it would heavily rely on the C library maintainer providing a ready made WASM version. Would involve too much work otherwise.

[napperley]

Some people have already ported LVGL to WASM. Here is one of the popular LVGL forks: https://github.com/AppKaki/lvgl-wasm

This LVGL fork seems to have the LVGL graphics stuff converted to HTML (❓), and the WABT toolkit ( https://github.com/WebAssembly/wabt ) has been used as part of the porting process.

[napperley]

Hypothetically if K/W can access LVGL's WASM port (if it existed) then that would provide K/W with a great GUI option (also gives the K/W ecosystem a head start), which would be an excellent alternative to Compose Web, HTML, and Web Canvas 😄.

[napperley]

An approachable, non reactive GUI option that doesn't rely on JS/TypeScript is needed for the K/W platform.

[Svyatoslav Kuzmich [JB]]

Sounds good. The way I see it, wasm will have 3 major interop options to choose from: JS, C ABI and Interface Types. JS will be ready initially. C ABI and IT will come after.

[Svyatoslav Kuzmich [JB]]

Interface Types have a potential to give a big boost to cross-language Wasm ecosystem. Although interactions will probably be slower than using C ABI.

[napperley]

Are the Interface Types tied into some sort of WASM library format? Is there a web standard for a WASM library format?

[Svyatoslav Kuzmich [JB]]

Core Wasm is low level. Languages defined their own library formats on top of Wasm, they define some sort of ABI, very similar to what they do when compiled to native code. Interface Types is one of such formats designed to describe high-level types like strings, records, arrays in a way that every language can produce and consume them.

[bashor]

I personally more like an idea to be able load API from any wasm file instead of having C interop.

[Svyatoslav Kuzmich [JB]]

Loading any Wasm file could be a useful feature on its own. But I don't think this would be a good replacement for C interop because pure Wasm file no longer has information about high-level C types. All pointers would look like an Int and you would have to manually specify field offsets in your structs.

[napperley]

I think many of us can agree that K/W interop with C libraries is important (especially with porting some K/N libraries over to K/W), but would be lower priority than interop with JS/TS libraries. Last time I looked at the size of the K/N ecosystem (with only the Linux targets) it was about the same size as the K/JS ecosystem. If about 30% of the K/N ecosystem was ported over to K/W then the K/W ecosystem would get a good boost. This is a good way to increase the attractiveness of K/W and helps set Kotlin apart from many other high level languages that either already support WASM, or are planning to do so in the near future.

[napperley]

@Svyatoslav Kuzmich [JB] - It would be very useful to provide some feedback on WASM interop for the Wasm3 project ( https://github.com/wasm3/wasm3/issues/217 ), even though it is a different WASM runtime implementation which runs independently from a Web Browser, and K/W doesn't support that WASM runtime.

[napperley]

Sure, Interface Types have their place but it wouldn't be a good fit for C libraries that are being ported to WASM as mentioned earlier. One key question, Do Interface Types cover manual memory management?

[Svyatoslav Kuzmich [JB]]

Issue you linked seems to be about integrating LVGL interop Wasm3 natively without compiling it to Wasm. As far as I understand, the plan is to provide API via host imports, which looks fine. Do you have any specific questions?

Do Interface Types cover manual memory management?

Not directly. IT is not fond of sharing linear memory, and values are copied when passed between components. However, there will be handles to resources that could be freed. Memory allocation could be seen as such resources.

[napperley]

Would the manual memory management have shim type APIs (same signature, different behaviour) just like the ones for File system access with WASM?