Kotlin/Native Support

[doyaaaaaken]

https://kotlinlang.org/docs/reference/multiplatform.html

[luca992]

Are there any bottlenecks preventing you from also targeting native?

[doyaaaaaken]

No, there's no bottleneck.
But I wait to implement it because the multiplatform feature is now experimental and I don't see how big the need for the multiplatform feature is in kotlin-csv.
If this feature is needed, I'll consider it.
Feel free to request it, and tell me the detail of the use case.

[luca992]

Got it, I was able to parse a csv with okio's new multiplatform file system feature so I'm all good now. You might find it interesting.

[itegulov]

@doyaaaaaken my team is interested in multiplatform version of kotlin-csv. We are developing a client-facing SDK that cross-compiles to JVM/Android/iOS/JS (both browser and NodeJS). I understand that some features would be unimplementable, specifically those working with files from browser, so some analysis would have to done in that respect.

We can probably even spare some manpower to work on enabling such support in kotlin-csv if you agree on the general direction.

[doyaaaaaken]

@itegulov
Thank you very much. I would be very grateful for your help.

As you can see from the following code, the common code is in the form of receiving String type as an argument, and the rest is defining methods to receive each platform's own type (java.io.File type for Java) as an argument.

• Multiplatform
• JVM

The first thing we would like to do is to make the minimal code defined in [the multiplatform code](https://github.com/doyaaaaaken/kotlin-csv/blob/master/src/commonMain/kotlin/com/github/doyaaaaaken/kotlincsv/client/
CsvReader.kt) work on a specific platform (e.g. JS).
What form of help would you be able to provide?

[itegulov]

@doyaaaaaken I see. Let me take this discussion internally and I will get back to you on our plans.

[doyaaaaaken]

The Kotlin/JS feature is implemented by #30. (released at version 1.0.0.)
This issue is renamed into "Kotlin/Native Support".

[mevdev]

I don't know why this library is listed as "A pure kotlin simple csv reader/writer." when it only supports Kotlin JS or Kotlin JVM (and not actual Kotlin native).

What would be needed to take it completely Kotlin native actually?

[onekinn1023]

Desperately hope to be able to support kotlin/common. I wanna phrase the csv in my shared module of KMM project, but I don't have a good way.

[luca992]

Desperately hope to be able to support kotlin/common. I wanna phrase the csv in my shared module of KMM project, but I don't have a good way.

@onekinn1023
If you need something now for reading data. Here's an example little helper function for you using okio and multik for reading doubles with null support, you just need to define the filesytem actual in each target. This if for tab separated data, replace \t in it.split('\t') with whatever your delimiter is.

Multik isn't needed if you are okay with lists of lists.

    expect val fileSystem : okio.FileSystem

    protected fun loadTrainingData(path: Path, skipFirstRows: Int): D2Array<Double> {
        val rows = fileSystem.read(path) {
            generateSequence { readUtf8Line() }.filterIndexed{ i, s -> i >= skipFirstRows}
                .map { it.split('\t').map { n -> if (n.contains("null")) 0.0 else n.toDouble() } }.toList()
        }
        return Mk.ndarray(rows)
    }

[onekinn1023]

I'm currently parsing line by line with pure kotlin code in my common module of KMM, but the resulting problem is that the format requirements of the source data need to be very standardized, and the maintenance of the code is also very troublesome. So I'm looking for a way that can be directly parsed from csv into a model or something... All in all, thanks for your @luca992 reply.

[vanniktech]

I guess the easiest solution would be to split the current library into two modules.

1. encoding / decoding logic
2. writing to IO

The first part could be truly multiplatform. The 2nd part could support the targets we have in place already and use the 1st part as a dependency.

In my personal preference, I'd even use okio for the second bit since you can't beat their APIs and I'm already leveraging it anyways.

[vanniktech]

Yeah so I quickly copied the sources into my project and was able to get encoding / decoding support on Kotlin Native. My implementation for ICsvFileWriter is very trivial though. I just use a StringBuilder and append characters into that instead of using the PrintWriter from Java World.

[gsteckman]

Splitting the common logic from the i/o is a good approach. It's been a couple of years since I looked under the hood of this library when I submitted #87. It may not be desirable to tie this library to Okio however since users may not want that dependency. Another approach would be to use Flows to communicate between the common logic and the platform-specific io, which could then be pluggable, with Okio as one implementation option.

[gsteckman]

kotlinx-io could be another option, which may be more acceptable to have as a direct dependency.