it's a separate artifact

so 0% overhead

oh perfect

however, we don't really support running arbitrary JS anymore. much of that is hidden underneath zipline which primarily deals with linking Kotlin JVM or Kotlin native to the Kotlin/JS inside the JS VM

you technically still can interact with the QuickJS runtime beneath Zipline for this, though

when you say not arbitrary js, is that because it's kotlin/js, or are there other limitations? My ideal env would be kotlin/js talking to a third party lib with some external declarations (that I don't mind hand-writing if needed)

(I'll probably mess around on my own some regardless, so we'll see how I do)

We’re hoping to switch from JS to WASM as soon as that tech is capable

Zipline 1.x won’t disappear, but our project goal is to run interpreted Kotlin code, not to run JS

I still sorta think we should pull QuickJS into its own module with the simple, stringly-typed API that it has and slap a giant opt-in annotation on it.

Then people who want a JS engine can have it, but eventually they'll have to either be stuck on an old version or fork when we switch engines

Plus we're forced to expose QuickJS in the Zipline API and that should have an opt-in annotation on it, too

yeah that would fit my use-case of "I don't want to do my own quickjs bindings"

the

QuickJs

type is fully usable on its own inside the Zipline artifact, for what it's worth. But you drag in the Zipline types and stuff along with it that you have to ignore

On this topic, I'm curious if you Zipline folks considered

androidx.javascriptengine

over

QuickJs

at any point. I got the impression

QuickJs

is abandoned but I also know it's a temporary solution until Kotlin/Wasm stabilizes

QuickJS is stable

we were using Duktape before it, but QuickJS was about 10x faster for the same binary cost

no we didn't look at androidx.javascriptengine because we need something that runs on Android, JVM, native iOS, native linux, and native macos

the host-side of the JS VM is itself a Kotlin multiplatform project that can run across many platforms

We have historically been concerned about Kotlin/JS being abandoned, not QuickJS. Kotlin targets a version of the JS spec from 2009.

Is there any problem using a

value class

in a function parameter in retrofit?

Retrofit will see the underlying value (boxed if a primitive) and not the value class wrapper box

boxed if a primitive

So this won't work:

@PUT("/someendpoint")
suspend fun foo(someId: SomeId): Unit

@JvmInline
value class SomeId(val value: Int)

and this will (since it won't see a boxed value?)

@PUT("/someendpoint")
suspend fun foo(someId: SomeSearch): Unit

@JvmInline
value class SomeSearch(val value: String)

I don't think I understand what the difference is between seeing a boxed primitive but not the value class wrapper box...

it will see a java.lang.Integer and java.lang.String, respectively

Thanks, now I got it 👍🏼

How can I read a csv file located in

assets

folder from the

commonMain

module? i’m using

okio

api to read the file. it requires the full path of the file to be read but I don’t know how to provide the full path or where to put the csv file

fun readCsvFile(filePath: String){
    val path = "words.txt".toPath() // where should I put this file?
    val csvContent = FileSystem.SYSTEM.read(path) {
        readUtf8()
    }
}

Assets are an Android concept

You would have to pass the path and the file system from Android code into the common code

can you please point me to a documentation or a project on how to do that?