https://kotlinlang.org logo
Join Slack
Powered by
Hey, I am working on updating some of my repositor...
# webassembly
s
Hey, I am working on updating some of my repositories to Kotlin 1.9.20, I missed latest progresses, so I may need a bit of help. I have updated https://github.com/sdeleuze/wasm-footprint/tree/kotlin-1.9.20/kotlin to use the new Wasm WASI support, taking inspiration from https://github.com/Kotlin/kotlin-wasm-examples/tree/main/wasi-example, but I get the following error: 
ompileError: WebAssembly.Module(): supertype count of 1705 exceeds internal limit of 1 @+366
when runing 
./gradlew wasmWasiNodeTest
. What did I miss? It looks like there is no 
wasmWasiNodeRun
task, why?
s
It seems that 
1.9.20-Beta
uses old pre-standard Wasm GC opcodes. Bumping Kotlin version to the latest stable 
1.9.22
fixes 
wasmWasiNodeTest
.
s
Hey, thanks for your feedback, using 
1.9.22
fixed both issues.
👍 1
s
And 
wasmWasiNodeRun
is there too
s
Not sure why I used the beta, likely bad copy and past.
s
If you are interested in measuring the cutting-edge footprint, 
2.0.0-Beta2
allows for 
applyBinaryen()
in 
wasmWasi
target.
2.0.0-Beta2.patch.diff
s
53K output, pretty good!
Any thought on enabling Binaryen automatically for production builds?
(I keep seeing people forgetting using it beause they are just not aware and we have the "production" explicit signal)
The behavior I would expect: • Enabled automatically for production build, provide a way to disable it (property that I can set to false?) • Disabled for dev build
s
Yes, we should enable it by default in prod builds
👍 2
s
I will continue to test more, great work, merry Christmas!
s
s
Is it expected that Kotlin/Wasm 
1.9.22
and 
2.0.0-Beta2
do not work work with Node 21.5.0?
Copy code
CompileError: WebAssembly.Module(): supertype count of 1360 exceeds internal limit of 1 @+360
    at file:///home/seb/workspace/wasm-footprint/kotlin/build/compileSync/wasmWasi/main/developmentExecutable/kotlin/add-wasm-wasi.mjs:15:20

Node.js v21.5.0
If yes, do you plan to update Kotlin 
2.0.0
upcoming beta/RC to fix that? I am a bit surprised since I thought WasmGC opcodes were final.
Am I right in understanding for now there is no 
wasm
"abstract" architecture and I need to use 
common
if I want to share code between 
wasmJs
and 
wasmWasi
?
👌 1
Which version of 
id("org.jetbrains.compose")
am I expected to use with Kotlin 
1.9.22
?
I try to upgrade KoWasm to Kotlin 1.9.22 (WIP branch) using for now 
wasmJs
, I get breakage on bitwise OR with 
or
on a type alias for 
Short
(
Long
seems ok), is it expected? What should be used instead?
I also see errors like 
Type Number cannot be used in external function parameter. Only external, primitive, string and function types are supported in Kotlin/Wasm JS interop.
, any guideline on how to handle that?
s
> Is it expected that Kotlin/Wasm 
1.9.22
and 
2.0.0-Beta2
do not work work with Node 21.5.0? Yes > If yes, do you plan to update Kotlin 
2.0.0
upcoming beta/RC to fix that? Kotlin is fine. Stable node needs to update to a recent v8.
Copy code
$ node --version
v21.5.0
$ node -p process.versions.v8
11.8.172.17-node.18
Copy code
$ node --version
v21.0.0-v8-canary202309143a48826a08
$ node -p process.versions.v8
11.9.85-node.5
👍 1
Which version of 
id("org.jetbrains.compose")
am I expected to use with Kotlin 
1.9.22
?
Based on https://www.jetbrains.com/help/kotlin-multiplatform-dev/compose-compatibility-and-versioning.html#kotlin-compatibility it seems that the latest supported Kotlin version is 
1.9.21
I try to upgrade KoWasm to Kotlin 1.9.22 (WIP branch) using for now 
wasmJs
, I get breakage on bitwise OR with 
or
on a type alias for 
Short
(
Long
seems ok), is it expected? What should be used instead?
It is expected. Add 
import kotlin.experimental.or
I also see errors like 
Type Number cannot be used in external function parameter. Only external, primitive, string and function types are supported in Kotlin/Wasm JS interop.
, any guideline on how to handle that?
Use concrete 
Double
or 
Int
instead.
s
Thanks!
When running 
node --experimental-wasi-unstable-preview1 --experimental-wasm-gc runner.mjs
with
Copy code
import { instantiate } from "./build/compileSync/wasmJs/main/productionExecutable/kotlin/kowasm-samples-wasi-sample-wasm-js.uninstantiated.mjs";
import { WASI } from "wasi";

export const wasi = new WASI({
    args: ["argument1", "argument2"],
    env: {
        "PATH" : "/usr/local/bin:/usr/bin",
        "HOME": "/home/seb"
    },
    preopens: {
        '/sandbox': process.cwd() + '/build/'
    }
});

const { exports, instance } = await instantiate({ wasi_snapshot_preview1 : wasi.wasiImport }, false);
wasi.initialize(instance);

exports.__init()
I get:
Copy code
node:internal/errors:496
    ErrorCaptureStackTrace(err);
    ^

TypeError [ERR_INVALID_ARG_TYPE]: The "options.version" property must be of type string. Received undefined
    at new NodeError (node:internal/errors:405:5)
    at validateString (node:internal/validators:162:11)
    at new WASI (node:wasi:51:5)
    at file:///home/seb/workspace/kowasm/samples/wasi-sample/runner.mjs:4:21
    at ModuleJob.run (node:internal/modules/esm/module_job:217:25)
    at async ModuleLoader.import (node:internal/modules/esm/loader:308:24)
    at async loadESM (node:internal/process/esm_loader:42:7)
    at async handleMainPromise (node:internal/modules/run_main:66:12) {
  code: 'ERR_INVALID_ARG_TYPE'
}

Node.js v21.0.0-v8-canary202309143a48826a08
Any idea of the cause?
s
I guess it requires 
version: 'preview1'
now. See https://nodejs.org/api/wasi.html
👍 1
> I suspect a bug in transitive dependency resolution Do you suspect 1.9.22 behaviour to be wrong? To me it looks legit now, because 
:samples:fullstack-sample:common
is not exposing these dependencies transitively, see implementation deps. Looks like a false-negative bug in the past.
s
Do you suspect 1.9.22 behaviour to be wrong?
No should be good, it was likely related to the fact Kotlin 1.9 enforces more strictly visibility based in Gradle dependencies, all good with 
api
.
KoWasm migration to Kotlin 1.9 complete! The 2 next steps will likely be: • kowasm#31 Leverage the new 
wasmWasi
target • kowasm#25 Leverage 
uvwasi
sock_accept()
instead of Node.js HTTP API
🎉 7
r
kotlinx-datetime 0.5.0 supports wasmJs, you can probably replace your copy with the original lib
s
Good point, I will.
👍 1
Looks like kotlinx-datetime#324 will be required for kotlinx-datetime support for wasmWasi, right?
110 Views
Open in Slack
PreviousNext
Powered by