fkrauthan
03/10/2020, 5:59 PMfkrauthan
03/10/2020, 7:17 PMfkrauthan
03/10/2020, 11:11 PMjvm
, macosX64
and linuxX64
as targets as well as a commonMain
with most of my code and a posixMain
source set where macos and linux main source sets are depending on. But for some reason I don't seem to have access to any of the default interops e,g, platform.posix
nether in posixMain
nor in linuxMain
and macosMain
. Is there anything else I need to configure to be able to access them (preferable in my posixMain
source set?Arthur Brum
03/11/2020, 12:11 PMKris Wong
03/11/2020, 2:38 PMLuoqiaoyou
03/11/2020, 2:43 PMspierce7
03/11/2020, 3:31 PMNew Gradle Sync is not supported due to containing Kotlin modules
That’s all the information provided in the IDE, and I can’t repro via command line. Anyone have any idea/Sebastien Leclerc Lavallee
03/11/2020, 3:49 PMapplication
plugin and when I installDist
, everything seems to work as expected. I see my app in the build dir and the associated jar file. The problem is when I run the app, I have an error saying it can’t find the main class I did specifiy in my build.gradle. When checking my jar file, it is totally empty. There is only the MANIFEST.MF
. Most of my classes are in the commonMain sourceset and some actual in the jvmMain sourceset. Anyone has encountered this ? Any things to check? Thanks 🙂spierce7
03/11/2020, 6:31 PMios
platform target for multiplatform, is it possible to get rid of this error when placing actual declarations in the Platform
file?
Object ‘Platform’ has several compatible actual declarations in modules ab-testing-firebase.client.iosArm64Main, ab-testing-firebase.client.iosMain
Object ‘Platform’ has several compatible actual declarations in modules ab-testing-firebase.client.iosX64Main, ab-testing-firebase.client.iosMain
fkrauthan
03/11/2020, 6:54 PMLuoqiaoyou
03/12/2020, 9:38 AMspierce7
03/12/2020, 4:41 PMUnresolved reference: coroutines
Unresolved reference: coroutines
Unresolved reference: CoroutineDispatcher
Unresolved reference: Dispatchers
val iosMain by getting {
dependencies {
implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core-native:${Versions.kotlinxCoroutines}")
implementation(Deps.ktor.client.ios)
implementation(Deps.ktor.feature.serialization.native)
}
}
magnumrocha
03/12/2020, 5:30 PM/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld invocation reported errors
Shawn Karber_
03/12/2020, 9:05 PMLuoqiaoyou
03/13/2020, 8:27 AM"id:$id,error:$error"
i got error in runtime.both of them are object pass by ios framework callback. the second way is fine:
"id:" + id +",error:" + error
CLOVIS
03/13/2020, 10:31 PMCHROME_BIN=chromium-browser
however it complains that Running as root without --no-sandbox is not supported.
. I'm trying to add the --no-sandbox
option, however I can't add it to CHROME_BIN
. Is there an option somewhere in the multiplatform plugin to handle this? And if not, what are the solutions?altavir
03/14/2020, 11:22 AMdataforge-meta-jvm
alongside with normal versions.
• When I try to push to a package which did not exist before, I get 404.
Do you know some ways around those problems?coletz
03/15/2020, 1:38 PMdennis
03/15/2020, 2:24 PMkrtko
03/15/2020, 7:16 PM//LoginViewController is a pure kotlin class that inherits from the MPP class ViewController. ViewController contains several platform specific fields such as `context` on Android
class LoginViewController: ViewController {
fun someButtonWasPressed() {
//A button was pressed callback
//uh oh we need to drop into native code for some reason
android { //An auto generated inlined lambda for the Android MMP
this.context //we have access to LoginViewController's Android side
this.androidDoSomething(this.context)
}
ios { //An auto generated inlined lambda for the iOS MMP
NSLog("You have access to anything from the iOS MP project")
val appDelegate = UIApplication.shared.delegate as AppDelegate
}
}
@platform("android") fun androidDoSomething(context: Context) { //can have platform specific arguments
//this method can only be called from an android context
Log.d("hi","from android")
}
//this could also be nested in some "subclass" like structure like `android { fun androidDoSomething(context: Context) {} }`
}
This produces messier and harder to read code in most circumstances, however I think it provides huge benefits in these particular cases:
1. Onboarding new users and beginners. Explaining the current MP project set up is not easy. I think if someone can start a project or contribute to a code base in the fashion above it will be significantly more clear to them. It's also a lot simpler to grasp out of the box vs the Actual/Expect system. Theres no indirection weaving back and forth between the different subproject for each platform.
2. Prototyping. The current Actual/Expect system works very well. It forces you to cleanly separate platform specific code from common code. Thats great except this can get in the way for when you are prototyping something and you just need to get the whole thing running in the most quick and simple fashion possible. I think the above system helps solve that as it reduces the need for nested platform code.
3. Simple platform calls. The current Actual/Expect system adds a lot of overhead for small platform specific methods. If the method is only ever going to be 1-3 lines per platform, its a lot of boiler plate to have a separate file for each platform specific instance of the method
----
2. Abstract classes with the ability to declare abstract specific platform code:
Ex.
Library author
abstract class ViewController {
@platform("android") abstract fun getView(context: Context): View //even tho we are in common kotlin, the method declaration can access Android
@platform("iOS") abstract fun getView(): UIView //even tho we are in common kotlin, the method declaration can access iOS
}
Library consumer
class LoginViewController: ViewController {
@platform("android") override fun getView(context: Context): View {
//inflate and return a view
}
@platform("iOS") override fun getView(): UIView {
val view = UIView()
return view
}
}
Library authors can currently do something like this by having an Actual/Expect abstract class with specific abstract methods for a given platform. My main issue with doing this is its not as clear to the library consumer and it requires more class nesting than the example above
----Luoqiaoyou
03/16/2020, 9:37 AMKurt Renzo Acosta
03/16/2020, 2:45 PMJeff
03/16/2020, 4:36 PMJan Stoltman
03/16/2020, 8:38 PMspierce7
03/17/2020, 4:38 AMFlow
.Archie
03/17/2020, 7:55 AMJoey
03/17/2020, 8:14 AMEvaS
03/17/2020, 10:43 AMkotlin_test_junit : "org.jetbrains.kotlin:kotlin-test-junit:$ver.kotlin",
kotlin_test : "org.jetbrains.kotlin:kotlin-test:$ver.kotlin",
ktor_client_mock: "io.ktor:ktor-client-mock-native:$ver.ktor",
kotlin_couroutine_test: "org.jetbrains.kotlinx:kotlinx-coroutines-test:$ver.kotlinx_coroutine"
Now it compiles but some tests fail. I guess it's because my coroutine's dep is wrong (or ktor, I don't know). I have a big trace at io.ktor.client
and at kotlinx.coroutines
Any hint ?alex009
03/17/2020, 2:49 PMfkrauthan
03/17/2020, 7:15 PMfkrauthan
03/17/2020, 7:15 PMDominaezzz
03/17/2020, 7:18 PMCasey Brooks
03/17/2020, 7:23 PMfkrauthan
03/17/2020, 9:27 PMlouiscad
03/17/2020, 10:04 PMfkrauthan
03/17/2020, 10:30 PMcharleskorn
03/18/2020, 7:21 AMlibyaml
(or similar) to do the parsing, but I haven’t gotten around to it yet - biggest blocker is the lack of support for K/N in Spek.magnumrocha
03/18/2020, 8:31 AMraniejade
03/18/2020, 2:03 PM1.3.70
- significant changes to the compiler plugin api)