Chris Fillmore
05/25/2022, 10:58 PMjared
05/25/2022, 11:58 PMJose Garcia
05/26/2022, 8:07 AMJose Garcia
05/26/2022, 8:41 AMJack Darlington
05/26/2022, 7:55 PMld: warning: Could not find or use auto-linked library 'swiftCore'
ld: warning: Could not find or use auto-linked library 'swiftQuartzCore'
ld: warning: Could not find or use auto-linked library 'swiftCoreGraphics'
ld: warning: Could not find or use auto-linked library 'swift_Concurrency'
ld: warning: Could not find or use auto-linked library 'swiftFoundation'
ld: warning: Could not find or use auto-linked library 'swiftCompatibility51'
ld: warning: Could not find or use auto-linked library 'swiftObjectiveC'
ld: warning: Could not find or use auto-linked library 'swiftDispatch'
ld: warning: Could not find or use auto-linked library 'swiftDarwin'
ld: warning: Could not find or use auto-linked library 'swiftUIKit'
ld: warning: Could not find or use auto-linked library 'swiftCoreFoundation'
ld: warning: Could not find or use auto-linked library 'swiftCompatibility50'
ld: warning: Could not find or use auto-linked library 'swiftCoreImage'
ld: warning: Could not find or use auto-linked library 'swiftCompatibilityDynamicReplacements'
ld: warning: Could not find or use auto-linked library 'swiftMetal'
ld: warning: Could not find or use auto-linked library 'swiftFileProvider'
ld: warning: Could not find or use auto-linked library 'swiftDataDetection'
ld: warning: Could not find or use auto-linked library 'swiftCompatibilityConcurrency'
kevin.cianfarini
05/26/2022, 10:01 PMCloseable
as a feature Kotlin developers desire in the common stdlib. Here's an associated YouTrack Issue.
This conversation has been brought up several times, and the argument against Closeable
being defined in common was that the stdlib doesn't use it anywhere.
Library maintainers have coped by creating their own implementations of Closeable
and use
. This is undesirable because:
1. Consumers of these libraries have to rectify multiple different namespaces of what is essentially the same interface.
2. Library maintainers need to recreate closeable for every one of their projects.
Right now, Okio, SQLDelight, and Ktor all have their own implementations of Closeable
. I'm sure there's many more libraries which do the same.
I personally feel that coalescing around a single implementation of Closeable
is import in the Kotlin ecosystem now that we've shown it to be a common use case in multiplatform code.Alex Logan
05/27/2022, 8:59 AMMarek Niedbach
05/27/2022, 12:56 PMgradle check
? I have some logic that rely on `Locale`/`NSLocale` and the unit tests are using the machine locale which may be out of control..Landry Norris
05/27/2022, 9:40 PMxiaobailong24
05/29/2022, 11:31 AMKwabena Berko
05/30/2022, 11:17 AMDimitri Giani
05/31/2022, 9:36 AMRonny Remesnik
05/31/2022, 1:19 PMcommonMain
folder on the root, all imported well.
But all code compiles well, no problem on compilation, only visual… problem started since upgrading Kotlin to 1.6.21
Thanks in advance…martmists
05/31/2022, 2:59 PMAli Khaleqi Yekta
05/31/2022, 3:24 PM...
kotlin {
android {
compilations.all { kotlinOptions.jvmTarget = "1.8" }
}
jvm {
compilations.all { kotlinOptions.jvmTarget = "17" }
}
...
}
...
inside the build.gradle.kts
of my common module, but when building the project, it fails with:
... error: cannot inline bytecode built with JVM target 17 into bytecode that is being built with JVM target 1.8. Please specify proper '-jvm-target' option ...
Sam
05/31/2022, 7:44 PMBeta is expected in spring 2022Anyone got any more detail?
Sam
05/31/2022, 8:18 PMRan
06/01/2022, 6:14 AMManApart
06/01/2022, 11:49 AM:cleanJvmTest :jvmTest
passes the tests, but doing a junit 'all in package' (or running the jvm main file/entry point) test fails with an error that seems to indicate that the expect / actual classes aren't being correctly understood. I get a bunch of errors like the one below, despite the IDE finding the corresponding declarations / gradle-run tests passing.
\src\jvmMain\kotlin\core\history\SessionHistory.kt:9:15
Kotlin: Actual object 'SessionHistory' has no corresponding expected declaration
I'm wondering if I need to modify the run configuration somehow to understand the module structure?
I've done a hello world project with the same setup of having a jvm main call code in common that has expect/actual and it worked as I expected. So I assume I've done something wrong with this more complicated setup. I realize this is a more vague ask but would appreciate any pointers of things to track down. Thanks!Matt Nelson
06/01/2022, 2:25 PMMarco Righini
06/01/2022, 6:40 PMRachel Carandang
06/01/2022, 6:48 PMiosSimulatorArm64()
as a target to my build.gradle.kts, then the build complains that my “expect” classes are missing for that target with: Expected class 'SettingsStorage' has no actual declaration in module <shared> for Native.
What is the proper way to get around this error and build for the simulator?Marko Novakovic
06/01/2022, 9:03 PMClass … is compiled by a pre-release version of Kotlin and cannot be loaded by this version of the compiler
for classes and top level functions in shared
module. Am using Kotlin version 1.6.21
for month now and today I started to get those errors. I don’t understand thisRachel Carandang
06/01/2022, 10:33 PM<unknown>:0: error: unable to load standard library for target 'arm64-apple-ios10.0'
I’ve tried everything suggested online, clean derived data, restart xcode, clear environment, download ios 10 simulators (there are none). I strongly suspect it’s related to errors I had earlier compiling the shared KMM framework: https://kotlinlang.slack.com/archives/C3PQML5NU/p1654109309669219
Does anyone know why this might be happening? Its pretty ambiguous and nothing online has helped so far. This seems to be a problem with the simulator target only.ribesg
06/02/2022, 2:23 PMNo matching variant of <myKmpLib> was found. The consumer was configured to find a usage of 'kotlin-api' of a component, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'common'
While trying to build a shared
module of a KMM app having a dependency on a KMP library defined in its commonMain
sourceSetjean
06/02/2022, 3:04 PMimport kotlinx.coroutines.newSingleThreadContext
and import kotlinx.coroutines.runBlocking
even though I added the native-mt
version of coroutines. Am I missing something?
val commonMain by getting {
dependencies {
implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.6.1-native-mt")
}
}
val commonTest by getting {
dependencies {
implementation(kotlin("test"))
implementation(kotlin("test-common"))
implementation(kotlin("test-annotations-common"))
implementation("org.jetbrains.kotlinx:kotlinx-coroutines-test:1.6.1-native-mt")
}
}
Claude Brisson
06/02/2022, 3:54 PM.idea
folder, the sync succeeds and everything goes back to normal, with source and test roots properly detected in commonMain, jvmMain, jsMain and the same for test.
Somehow, IntellijIdea mixes gradle build models between multiplatform and java plugins from different modules, and I don't have any clue why it happens.
Versions:
+ IntelliJ IDEA 2021.3.3 (Ultimate Edition) Build #IU-213.7172.25, built on March 15, 2022
+ Kotlin plugin 213-1.6.21-release-334-IJ6777.52
+ gradle 7.1 or 7.4.2Nacho Ruiz Martin
06/02/2022, 4:24 PMAli Khaleqi Yekta
06/02/2022, 6:35 PMmartmists
06/02/2022, 7:51 PM