I've just published another version of our fork: https://bintray.com/mipt-npm/dev/kotlinx-io/0.2.0-npm-dev-6. It is much closer to mainstream than the previous version. The only difference is addition of Binary. It should not break anything, so you can play around with it. Use it on your own risk though. Some Node tests are failing and the API is deffietely not stable.

Has anyone been able to use jitpack to get this since there aren't any io-2 builds?

Since it's planned for

Bytes

to go internal, do we plan to have any equivalent to

ByteString

from okio? Input doesn't seem to entirely fit the bill

@e5l There is a request for native flavor of IO library. It seems like appropriate targets are not generated unless

idea.active

flag is set in the system. Could you explain what does it mean?

@kevin.cianfarini I think this thread answers your question. Sadly, I currently do not have time to play with native flavors. I do not have experience with them. Maybe somebody could contribure something.

@kevin.cianfarini I've published a new version, which includes native artifacts for windows and Linux: https://bintray.com/mipt-npm/dev/kotlinx-io/0.2.0-npm-dev-8. All tests are passing, but I've never actually tested native binaries.

I've just published a new version of my kotlinx-io fork: https://bintray.com/mipt-npm/dev/kotlinx-io/0.2.0-npm-dev-10. We use it internally in our projects and you are free to use it to test capabilities. This release is done for compatibility with new Kotlin-JS IR (it uses BOTH-mode). WARNING! This is not the official JB release or JB repository. This is a fork with little added Binary functionality.

This looks useful!

So, is this library going to go into development again soon? I believe one of the main things holding it up was the serialization library work, which has now reached full 1.0 release. The io library got mentioned (very briefly) during the 1.4 event, so I know it isn't forgotten.

Something to keep an eye on:

Is it alive? https://github.com/Kotlin/kotlinx-io

@e5l I am tired of tryitng to support my kotlinx-io fork, so I am trying to migrate to ktor-io. Some things are uggly but manageable, but I've just spent almost the whold day with the following problem: it seems that

readBytes

method does not actually advance the input read pointer. Is it intentional?

Hi I started a small Pr to update the project dependencies to the kotlin version 1.5.30. I am only having a few question, regarding errors that came up with Annotations - I leave them below this thread 🙂

there's been a lot of work on this with relatively little attention. https://github.com/caffeine-mgn/pw.binom.io

Sorry if that has been asked before but is there an mpp version of a ByteBuffer? or is it just using Bytechannel ?

Hi all! I observe a lot of fragmentation and duplication of effort around buffers. As there is no standard APIs for multiplatform buffers, you have to do a lot of work if you want to share a buffer across a stack of libraries. For instance, one of my use-cases is to: (1) receive a packet from a

ktor-network

socket, (2) parse a message using

google-flatbuffers

which contains a packed scalar array, (3) that is itself fed to

multik

to make a multi-dimensional array of it. Along all this processing line, it is possible to have a single byte array backing multiple buffers and not have to copy any bytes. However, it is a lot of work currently because there is no standard buffer API. For instance,

google-flatbuffers

is defining their own Buffer API to support this no-copy principle: https://github.com/google/flatbuffers/blob/master/kotlin/flatbuffers-kotlin/src/commonMain/kotlin/com/google/flatbuffers/kotlin/Buffers.kt In the above-mentioned use-case for instance, I have to implement my own

com.google.flatbuffers.kotlin.ReadBuffer

above `ktor-io`'s

<http://io.ktor.utils.io|io.ktor.utils.io>.core.ByteReadPacket

, etc Isn't it time that people from Okio, Ktor and others get together to define a standard Buffer API and revive

kotlinx-io

?? (Sorry for the kinda rant but it is a little irritating...)

Taken from Ktor 2023 Roadmap :

We’re extracting the IO functionality into a separate library. This is a long-standing task that we’ve been working on gradually, and aim to finalize in 2023.

❤️ K @e5l, @Oleg Yukhnevich Will this also include

ktor-network

?

Fwiw looks like the alpha version of the revamped kotlinx-io is out: https://github.com/Kotlin/kotlinx-io! Based off Okio.

I've created a branch implementing dataforge-io on top of new kotlinx-io: https://github.com/SciProgCentre/dataforge-core/tree/kotlinx-io. Seems to be working. But I had to add some APIs.

Is there a way to create a kotlinx-io

Buffer

with an initial size? I need to write quite some data, so an initial optimization would be good to have

Hi @Filipp Zhinkin! I ping you because you seem to be the most involved in

kotlinx-io

reincarnation. I would like to write a

kotlinx-io

adapter for `flatbuffers-kotlin`'

ReadWriteBuffer

. To do that I would need random-access read and write to buffers. Is this something that is on the roadmap? I stumbled upon this issue but it was created for the previous incarnation of

kotlinx-io

. To clarify my use-case: •

flatbuffers-kotlin

's

ReadBuffer

interface has a

limit

property indicating the read limit and only offers random-access reads (up to

limit

). •

flatbuffers-kotlin

's

ReadWriteBuffer

interface extends

ReadBuffer

, has a

writePosition

(equals

limit

) property, a

writeLimit

property and a

capacity

property, and offers both sequential writes (updating

writePosition

adequately) and random-access writes (up to

capacity

). • All read and write operations are in Little Endian byte order.

What's the equivalent pattern for writing a temporary length prefix, delegating to some other code to encode something of unknown length, then backtracking to update the length prefix? i.e. something like this, with Netty's ByteBuf:

// Length placeholder...
        int lengthStartIndex = buffer.writerIndex();
        buffer.writeShort(0);

        buffer.writeInt((int) packet.getSessionHandle());
        buffer.writeInt(packet.getStatus().getStatus());
        buffer.writeLong(packet.getSenderContext());
        buffer.writeInt(0);

        int dataStartIndex = buffer.writerIndex();

        if (packet.getCommand() != null) {
            encodeCommand(packet.getCommand(), buffer);
        }

        // Go back and update the length.
        int bytesWritten = buffer.writerIndex() - dataStartIndex;
        buffer.markWriterIndex();
        buffer.writerIndex(lengthStartIndex);
        buffer.writeShort(bytesWritten);
        buffer.resetWriterIndex();

Hi! I am using Okio on a project where I need to index a file. I was naively looking for a

BufferedSource

property that tells me how many bytes I have already read. It seems there is no direct mean to do that. I have routines that read individual packets from a

BufferedSource

. How would you proceed?

how can I set a new head position (an arbitrary offset) to start consuming in

Buffer

?

Are there any resources or suggestions out there on how to unit test stdin methods like 'readln'? I see some suggestions online on how to do this with Java API's like 'Scanner' and 'BufferedReader' but there is a real dearth of information on how to do this with the Kotlin 'Console' API. I currently have some logic in an infinite loop which awaits input from stdin before proceeding. I have wrapped 'readln' in a class function which is derived from an interface. I am then using this interface to mock stdin for unit tests but I am at a bit of a loss as to how I await input.

I added Okio, but I see no

SYSTEM

on

FileSystem

(only

SYSTEM_TEMPORARY_DIRECTORY

) am I missing anything?

what am I doing wrong?

val path = "/home/elect/IdeaProjects/scifio-lifesci/test.sdt".toPath()
println(HostFileSystem.exists(path))
println(HostFileSystem.source(path).buffer().buffer.size)

> true > 0 but test.sdt is not empty.. > -rw-rw-r-- 1 elect elect 4892652 ott 15 17:38 test.sdt I have my logic expecting a

Buffer

, that's what I understood is something I can "consume" (I need to read sequentially and sparse)