Kris Wong
01/13/2020, 8:45 PMBig Chungus
01/14/2020, 11:08 AMThomas
01/14/2020, 11:56 AMCoroutineScope
moved to a separate class?
See the following: https://github.com/touchlab/DroidconKotlin/blob/kpg/mt_coroutines/sessionize/lib/src/commonMain/kotlin/co/touchlab/sessionize/BaseModel.kt
If you check the master branch than you can see that BaseModel
just implements CoroutineScope
. In the kpg/mt_coroutines
branch that implementation was moved to a separate class, called MainScope
. Is there a reason behind this change to support mt coroutines? Is it possible that MainScope
can become frozen for some reason?Sam Schilling
01/14/2020, 5:08 PM10:06 AM Incompatible Kotlin/Native libraries
There are 227 libraries from the Kotlin/Native 1.3.50 distribution attached to the project: stdlib, ARKit, AVFoundation, AVFoundation, AVKit, ...
These libraries were compiled with an older Kotlin/Native compiler and can't be read in IDE. Please edit Gradle buildfile(s) to use Kotlin Gradle plugin version 1.3.61. Then re-import the project in IDE.
ribesg
01/15/2020, 9:16 AMdeinit
in Kotlin on iOS? I guess not but you never knowhooliooo
01/15/2020, 10:14 AMconst val kotlin_version = "1.3.61" previously "1.3.40"
const val coroutines_version = "1.3.3" previously "1.3.40"
const val ktor_version = "1.2.6" previously "1.2.2"
const val serialization_version = "0.14.0" previously "0.11.1"
const val mockk_version = "1.9.3"
The framework is created. The app works in debug mode. The issue is strictly archiving. I’m running into this issue:
Intrinsic has incorrect argument type!
i32 (i8*, i1, i1, i1)* @llvm.objectsize.i32.p0i8
Intrinsic has incorrect argument type!
i32 (i8*, i1, i1, i1)* @llvm.objectsize.i32.p0i8
Intrinsic has incorrect argument type!
i32 (i8*, i1, i1, i1)* @llvm.objectsize.i32.p0i8
Intrinsic has incorrect argument type!
i32 (i8*, i1, i1, i1)* @llvm.objectsize.i32.p0i8
Intrinsic has incorrect argument type!
i32 (i8*, i1, i1, i1)* @llvm.objectsize.i32.p0i8
Intrinsic has incorrect argument type!
i32 (i8*, i1, i1, i1)* @llvm.objectsize.i32.p0i8
Intrinsic has incorrect argument type!
i32 (i8*, i1, i1, i1)* @llvm.objectsize.i32.p0i8
Intrinsic has incorrect argument type!
i32 (i8*, i1, i1, i1)* @llvm.objectsize.i32.p0i8
Intrinsic has incorrect argument type!
i32 (i8*, i1, i1, i1)* @llvm.objectsize.i32.p0i8
Intrinsic has incorrect argument type!
i32 (i8*, i1, i1, i1)* @llvm.objectsize.i32.p0i8
Intrinsic has incorrect argument type!
i32 (i8*, i1, i1, i1)* @llvm.objectsize.i32.p0i8
Intrinsic has incorrect argument type!
i32 (i8*, i1, i1, i1)* @llvm.objectsize.i32.p0i8
Intrinsic has incorrect argument type!
i32 (i8*, i1, i1, i1)* @llvm.objectsize.i32.p0i8
Intrinsic has incorrect argument type!
i32 (i8*, i1, i1, i1)* @llvm.objectsize.i32.p0i8
Intrinsic has incorrect argument type!
i32 (i8*, i1, i1, i1)* @llvm.objectsize.i32.p0i8
Intrinsic has incorrect argument type!
i32 (i8*, i1, i1, i1)* @llvm.objectsize.i32.p0i8
Intrinsic has incorrect argument type!
i32 (i8*, i1, i1, i1)* @llvm.objectsize.i32.p0i8
Intrinsic has incorrect argument type!
i32 (i8*, i1, i1, i1)* @llvm.objectsize.i32.p0i8
Intrinsic has incorrect argument type!
i32 (i8*, i1, i1, i1)* @llvm.objectsize.i32.p0i8
Intrinsic has incorrect argument type!
i32 (i8*, i1, i1, i1)* @llvm.objectsize.i32.p0i8
Intrinsic has incorrect argument type!
i32 (i8*, i1, i1, i1)* @llvm.objectsize.i32.p0i8
Intrinsic has incorrect argument type!
i32 (i8*, i1, i1, i1)* @llvm.objectsize.i32.p0i8
Intrinsic has incorrect argument type!
i32 (i8*, i1, i1, i1)* @llvm.objectsize.i32.p0i8
Intrinsic has incorrect argument type!
i32 (i8*, i1, i1, i1)* @llvm.objectsize.i32.p0i8
Intrinsic has incorrect argument type!
i32 (i8*, i1, i1, i1)* @llvm.objectsize.i32.p0i8
Intrinsic has incorrect argument type!
i32 (i8*, i1, i1, i1)* @llvm.objectsize.i32.p0i8
Intrinsic has incorrect argument type!
i32 (i8*, i1, i1, i1)* @llvm.objectsize.i32.p0i8
Intrinsic has incorrect argument type!
i32 (i8*, i1, i1, i1)* @llvm.objectsize.i32.p0i8
Intrinsic has incorrect argument type!
i32 (i8*, i1, i1, i1)* @llvm.objectsize.i32.p0i8
Intrinsic has incorrect argument type!
i32 (i8*, i1, i1, i1)* @llvm.objectsize.i32.p0i8
LLVM ERROR: Broken module found, compilation aborted!
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Command Ld failed with a nonzero exit code
Has anyone encountered this issue? I’m quite sure it’s related to the changes in the KMP project because reverting the framework (via cocoapods) to the previous version results in a successful archiving. The minimum target for the app is iOS 10.0 so a 32 bit architecture is supportedRobert
01/15/2020, 3:48 PMWhitley
01/15/2020, 4:59 PMSam Schilling
01/15/2020, 10:36 PMThe referenced value. Gets the value or sets the new value. If new value is not null, it must be frozen or permanent object.What is a permanent object? I have not seen that language used elsewhere before
galex
01/16/2020, 12:26 PMSam Schilling
01/16/2020, 5:17 PMKClass.constructors
is only available in JVM/JSKavan
01/17/2020, 9:25 AMBig Chungus
01/17/2020, 10:19 AMbackground-colour
to GTK3 button? Preferably with inline css (no .css files)Big Chungus
01/17/2020, 10:20 AMKotlinNativeSourceSet
with cinterops?ribesg
01/17/2020, 11:50 AMdepends = Foundation
package = framework.MaterialTextFields
language = Objective-C
headers = MaterialTextFields.h MaterialTextFields+Theming.h
compilerOpts = -framework MaterialComponents
linkerOpts = -framework MaterialComponents
My problem is that when I run cinterops I get this error:
Exception in thread "main" java.lang.Error: /Users/ribesg/XcodeProjects/events/Pods/MaterialComponents/components/TextFields/src/Theming/MDCTextInputControllerFilled+MaterialTheming.h:15:9: fatal error: 'MaterialComponents/MaterialContainerScheme.h' file not found
I found that MDCTextInputControllerFilled+MaterialTheming.h
contains this line #import <MaterialComponents/MaterialContainerScheme.h>
and cinterops does not seem to understand it properly. I do have this MaterialContainerScheme.h
file in the context but it’s not in a folder/module/whatever called MaterialComponents
I guess. How do I make this work?basher
01/18/2020, 10:06 PMkotlinx.cinterop
imports are also redKavan
01/19/2020, 6:22 AMbasher
01/19/2020, 6:29 AMfatal error: could not build module X
because it's finding an error and failing org.jetbrains.kotlin.native.interop.indexer.UtilsKt.ensureNoCompileErrors(Utils.kt:146
?Dominaezzz
01/19/2020, 5:34 PMnapperley
01/20/2020, 3:49 AMPatrick
01/20/2020, 9:58 AMPatrick
01/20/2020, 11:07 AMKavan
01/20/2020, 1:16 PMKavan
01/20/2020, 1:41 PMnapperley
01/21/2020, 1:48 AMnapperley
01/21/2020, 2:35 AMe: /home/napperley/repos/gui_vista/guivista-core/src/linuxX64Main/kotlin/org/guiVista/core/gobject_utils.kt: (37, 12): Type mismatch: inferred type is gulong /* = UInt */ but ULong was expected
e: /home/napperley/repos/gui_vista/guivista-core/src/linuxX64Main/kotlin/org/guiVista/core/gobject_utils.kt: (52, 38): Type mismatch: inferred type is ULong but gulong /* = UInt */ was expected
Appears as though these are the only compile errors. Seem to be close to building the library for the linuxArm32Hfp target. Are there some subtle differences with data types between arm32hf and x64 I should be aware of with Kotlin Native?Kavan
01/21/2020, 11:43 AMPatrick
01/21/2020, 11:55 AMPatrick
01/21/2020, 2:49 PMjmullin
01/21/2020, 4:00 PMsomePointer.rawValue
corrects the issue. I’m not using the value, just putting that line as a statement. Are there some side-effects anyone is aware of to calling .rawValue
on a pointer (implemented as a getter of value.toNativePtr()
internally) that might explain what I’m seeing? I have a number of other things to debug into, but seeing this leads me to believe there’s more going on here that I need to understand first.jmullin
01/21/2020, 4:00 PMsomePointer.rawValue
corrects the issue. I’m not using the value, just putting that line as a statement. Are there some side-effects anyone is aware of to calling .rawValue
on a pointer (implemented as a getter of value.toNativePtr()
internally) that might explain what I’m seeing? I have a number of other things to debug into, but seeing this leads me to believe there’s more going on here that I need to understand first.kpgalligan
01/21/2020, 4:05 PMjmullin
01/21/2020, 4:26 PM.rawValue
call I alluded to above is in the implementation for another method which the JVM class calls via JNI on that side. It’s actually just a debug print message method used on both ends. I noticed that when I remove the call from the Kotlin/JVM source, this NPE situation happens. Introducing the call, even when the K/N implementation does nothing but take the jstring
pointer and call .rawValue
, causes everything to work properly. So something’s behaving strangely; I’m still hunting down stuff in the JNI bits I’m using, as I suspect it will end up being a GlobalRef vs LocalRef situation where the JVM has moved things out from under me. We’ll see..rawValue
in K/N was fixing/masking the issues, but I at least have a path forward.