-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Investigate / add Kotlin native support #63
Comments
I'd love this for a project I'm working on, but I realize the Jline replacement piece would be tough. Maybe I can find some cycles to help. :) |
If you want to explore this any time, let me know and I'll give you all the
cycles I can! Happy to meet first at some point and tell you all known
pitfalls.
…On Mon, Jul 18, 2022, 4:24 PM James Ward ***@***.***> wrote:
I'd love this for a project I'm working on, but I realize the Jline
replacement piece would be tough. Maybe I can find some cycles to help. :)
—
Reply to this email directly, view it on GitHub
<#63 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AKNONASRH6MG4RRLVA3PV4LVUXRSHANCNFSM5FMJECLA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
We are working on building a CLI application and this library looks like something that would be perfect for our use case. The only issue is that our CLI has to have native targets, and hence kotlin-native support is imperative. Talking about the JLine functionality, is there an interface (or interfaces) that abstracts out the JLine functionality - such that a native implementation of the same would suffice for a |
Hey! Thanks for your interest in Kotter! I'd be happy to set up some time to meet, to share with you over video chat the current situation and perhaps accelerate any quick experiments you want to try. I'll send a message to your github account with details after writing this. To answer your question, Kotter has a Terminal interface which is pretty minimal, and it sounds like what you're looking for. If you can implement it effectively for native, then you won't need JLine. Check out TestTerminal for a in-memory terminal I created for tests, and the SystemTerminal implementation which is the only part of the code that references JLine. Note that there will still be some difficulties ahead, particularly threading. I am not too familiar with how threading works in Kotlin/native, because as far as I can tell the docs kind of suck. Note here how they bounce you to the "modern memory management" docs but those don't talk about threading at all. There are a few places where I kick off threads (usually via coroutines, but in one case from an executor).
You'll want to make sure you understand all those cases. Getting this to work for native may be a trivial case of adding Beyond that, you should clone the project and do a search for Otherwise, in theory you just need to move the following packages from
and then move At this point, brace yourself for a bunch of compile errors :) Finally, here are some alternate solutions to make sure you've considered other options:
|
I heard that Mosaic went multiplatform recently. If I can see how they did it and it doesn't seem that hard, I'll give a shot porting Kotter to multiplatform. At one point, I did some experiments with GraalVM which seemed promising at first, and I really wanted to make that my recommended solution, but soon I got a class not found exception from the kotlin standard library (kotlin.random.Random wasn't found??!), and I didn't enjoy the runaround to try to figure out how to fix it. I found the docs for GraalVM occasionally as inscrutable as I sometimes find Gradle docs to be. I also found a bug reported against the GraalVM Gradle plugin for someone who had a similar exception to what I have, including they did some leg work where they reported the exact line that needed to get fixed, and after that -- nothing. No response or change from the GraalVM team. Anyway, since even my initial impressions with GraalVM were frustration, I think multiplatform (if I can get it to work) will be a much easier thing for me to recommend to kotter users. |
The code is *still* only producing JVM artifacts, but in followup commits we can try extracting out common code. Bug #63
First hurdle - Kotter makes use of reentrant locks. It seems like this is not officially supported in Kotlin/Native. There's atomicfu which provides reentrant locks but says that it's a heavily experimental feature and that library authors should not use them. I may be able to reimplement what I need using expect / actual but this could get ugly... |
Initial prototype success: Final debug exe size: 7.6MB, release exe size: 1.4MB. That's not bad.... Still, best to temper any excitement with the following points:
Got farther than I expected to today, but I'm still not sure yet I'm sold on the extra maintenance burden / complexity this change might bring. If I could get GraalVM working consistently instead, that would be so tempting... |
In case anyone is still around who is interested in helping me test this in the next few days, please ping me or give a thumbs up to this comment. It would really help the library to get other eyes on this besides mine. Lots of improvements today. Kotter native is on track. kotter-native-input.mp4
In summary, still to do...
|
Kotlin/Native looking solid on Linux at this point. Main thing left at this point is figuring out Windows (which it seems will need its own Terminal implementation, and then publishing artifacts on Maven. It's my top priority for the next few days, hopefully no major snags. |
Loving this progress! Thank you @bitspittle :) |
Thank you @jamesward! It's a testament to Kotlin/Native how smoothly this has been going. I was sure I was going to run into those memory freeze exceptions I heard so much about, or other problems that would crop up since I didn't really consider Kotlin/Native when I first built Kotter. But the Kotlin standard library is pretty impressive at this point. And it wasn't long before I had some samples running locally in Kotlin/Native. My only real regret with Kotter was using Java durations instead of Kotlin durations. I believe Kotlin durations were still experimental when I started writing Kotter, but still -- I should have been more confident that at that point it was probably safe to use them. The documentation on JB's side for Kotlin/Native is a little meh (JB has a style where they dump a bunch of information on you all at once, much of it intimidating and unrelated, where what I think most people are looking for is a step-by-step book or codelab that introduces concepts in layers). But once I got going, it was pretty neat to write C-style code with the magic of Anyway, let's see how Windows goes today... |
😌 kotter-native-input-win.mp4Aiming to drop 1.1.0-rc1 on Friday. We'll see how that goes. P.S. Dealing with the Windows API was a PITA :) It didn't help that I was working on a slow ass virtual machine. Anyway, hopefully I can put this dark memory behind me... |
Good news -- I have a multiplatform project with a simpler setup than Kotter (https://github.com/varabyte/truthish for the curious) which I used as a test run for figuring out publishing Kotlin / Native artifacts on maven central. Took a bit longer than I expected to set up, but as of this morning, it's working. It shouldn't be too complicated to carry that logic over to Kotter. At this point, Kotlin / Native support for Kotter is close. New ETA: should be up within a few days, maybe even tomorrow if things go smoothly. The scariest thing that could hit me, I think, is a subtle race condition showing up in tests. The final checklist:
|
Alright folks! If anyone is eager to try Kotter+Multiplatform out right now, you can grab some dev snapshots I just published. 🕵️ With multiplatform increasing the surface of things that can go wrong, I can really use as many eyes as I can get on this! Especially if you use Windows, Mac Intel, and/or Mac M1. Non US-keyboards on Windows a plus. THANK YOU! 🕵️ First, you'll need to declare the following repository: repositories {
maven("https://s01.oss.sonatype.org/content/repositories/snapshots/")
} Then, declare your dependency: JVM project dependencies {
// IMPORTANT! This *used* to be "com.varabyte.kotter:kotter:..."
implementation("com.varabyte.kotter:kotter-jvm:1.1.0-SNAPSHOT")
} Multiplatform project kotlin {
// declare targets, e.g. linuxX64(), mingwX64()...
sourceSets {
val commonMain by getting {
dependencies {
implementation("com.varabyte.kotter:kotter:1.1.0-SNAPSHOT")
}
}
}
} If you've never set up a Kotlin/Native project before, please see the official docs. You can also confer with the Kotter native example. Migration from Kotter 1.0.x
I still have a fair bit of busy work to do, so a stable release may take a few more days. But, at this point, the snapshots should be a really solid representation of the final release. I'm expecting mostly docs and bug fixes from here on out. Questions? Feedback? If I'm awake, you can usually catch me on my Discord server. My timezone is US Pacific Time (UTC-8) |
The code is *still* only producing JVM artifacts, but in followup commits we can try extracting out common code. Bug #63
The code is *still* only producing JVM artifacts, but in followup commits we can try extracting out common code. Bug #63
Kotlin 1.1.0-rc1 has been released!I'm really hoping I can turn this as is into 1.1.0 in a week or two. However, I'm nervous because I'm just one guy. Despite all my pounding on it, it's easy to feel paranoid about missing something. If anyone in here wouldn't mind spending a few minutes even just trying to set up a quick dummy project, any confirmation that this is working for others would help me immensely. Thank you all very much for your interest in Kotter. Getting Kotter+Native to work was an interesting journey. I hope the feature ultimately helps even one person get a Kotter app out when they might not have otherwise. |
Has anyone had a chance to try out Kotter 1.1.0-rc1? I've been using it myself non-stop and haven't had any issues, so I may just put out 1.1.0 in the next day or two. However, if anyone seeing this message could commit giving it a try, I'd be happy to wait a few more days, to make sure I don't send out a 1.1.0 that's fundamentally busted in some way I'm just not running into in my own environment. |
This is awesome! I'm giving it a try and hitting a strange runtime exception. Code:
Getting:
Any ideas? Note that I'll add input prompt into this loop. |
@jamesward Moved this specific issue to #98. Let's move the discussion over there and squash this! |
OK folks, Kotter 1.1.0 is out. It's always a little terrifying releasing something to mavenCentral. If you try this and find any problems with Kotlin/Native, please open a new issue. Thanks!! |
Context: https://www.reddit.com/r/Kotlin/comments/q17zjq/introducing_konsole_a_kotlinidiomatic_library_for/hfggbsv/
Currently, this library is JVM only. Adding native support would allow users to use this library in a Kotlin native context, which would:
Current challenges:
This bug isn't a priority for me at the moment because it's not clear to me how many people actually want this support, but hey, if you do, please indicate so by adding a thumbs up reaction to it (and consider leaving a comment on why you don't want to just use the JVM, I'd be curious!)
The text was updated successfully, but these errors were encountered: