Hey :android-wave: Things have beens a little bit ...
# webassembly
c
Hey 👋 Things have beens a little bit quiet on the chasm front as I’ve been navigating a move between jobs, I’m glad to say thats all now sorted and I’m back on the project! Today I’m releasing something I’ve been meaning to do for a long time, chasm now has a gradle plugin which simplifies it’s usage. It’s really simple, drop a wasm binary into a module, apply the plugin and chasm will generate you a kotlin interface and implementation which completely hides chasms lower level virtual machine api. It’s early days for the plugin but it can already do some magic, it can be configured to transform strings automatically, functions which return multiple values in wasm will be marshalled into a data class. I’ve updated the example project here if you want to see it in action. Documentation on the plugin can be found here, and details on the release are here
❤️ 4
🦜 1
c
Project links should go to #C0BJ0GTE2 . This is a channel for discussions. Always consider channel topics when posting in open communities.
🤣 1
🧐 2
m
I prefer it here because it is 100% Webassembly and there is a lot that might be discussed. I’ll make a start: I like the idea of a plugin to automatically generate an interface in Kotlin but I am wondering whether you are planning more configuration options. At the moment there is no real standard of how parameters are passed and every language or tool seems to do it differently. So I’d expect some way to configure the mapping that should be utilized by the plugin.
c
Hey @Michael Paus. absolutely we’ll evolve the plugin/codegen as we better understand the usecases. In terms of mappings we could easily extend the plugins dsl to let people configure things on a function level. I.e.
Copy code
chasm {
    modules {
        create("ExampleModule") {
            function("foo") {
                ...
            }
        }
    }
}
Or if that gets to verbose to have in the gradle config we could have separate mappings file which gives this extra codegen information. I’ve designed this initial version to work with sensible defaults so that people can get going with minimum config but we can definitely improve this. Could you tell me a little more about what you would like to do?
m
The following use cases would need to be considered. 1. E.g., I have adopted the scheme to store pointer/length combinations in a single i64 type, created from two i32 types. 2. For consistency I use the same scheme for input parameters as well as the single return value of a function. 3. I use the same scheme for all array types, e.g. byte arrays. 4. I have also adopted the scheme to export an explicit alloc and dealloc function. 5. A function can have more than one argument and could even use different array types at the same time. 6. Some compilers, e.g., Emscripten, create a function _initialize which is supposed to be called before any other function. These are just my conventions but other people may come up with additional or different ones. I guess in the end the result would look like the upcoming Wasm Component Model 😉.
c
Is this I64 scheme just something you’ve come up with personally? I haven’t seen a compiler do this before myself? Typically its either two I32s or one I32 where the string is either null terminated or has the length prefixed at the start of the pointer
m
I don’t know of any particular compiler but I have seen this scheme described in some examples and so I adopted it for my code. If there is any documented standard way how compilers deal with this then I’d be happy to adopt that but up to now I haven’t found such a document.
c
Ah, so are you creating the wasm by hand? By writing wat?
m
No, I primarily use Emscripten but I did the parameter passing for the exported functions manually because I could not find any documentation of how the compiler does the mapping itself. If you could point me to such documentation I’d like to have another look at this.