Hi, is it possible to remove the ripple-effect?

I declared Int in shared kmm model I am successfully able to use that in Android but in iOS we have kotlinInt how to convert it in string in iOS I am new in iOS

java.lang.NoSuchMethodError: No static method setContent(Landroid/app/Activity;Lkotlin/jvm/functions/Function0;)Landroidx/compose/Composition; in class Landroidx/ui/core/WrapperKt; or its super classes

Does anyone have any idea why this happens when calling setContent { }? I have tried: • 0.1.0-dev05, dev06 and dev07 • Kotlin 1.3.61 and 1.3.70 • with and without buildFeatures { compose true } and/or composeOptions

I'm implementing a custom "long press drag" composable over a GoogleMap composable ( or trying to ). To wit, I've got a structure like the following: Box GoogleMap - fillMaxSize() Canvas - fillMaxSize() - pointerInput(Unit) { detectDragGesturesAfterLongPress( ... ) My drag works great. Unfortunately, it eats not only the long press drag, but all other events as well and nothing makes it through the map when my Canvas is active. I've read through the helpful https://developer.android.com/jetpack/compose/touch-input/pointer-input/understand-gestures, but I'm not finding the solution to this problem in there. My theory is that either a) there's something I could do with my setup to make the gesture detector more cooperative or b) I need to basically inline the gesture detector so that I can manage event consumption more selectively or c) I can't use pointerInput at all and should be using something lower level?

How can I solve the "The 'java' plugin has been applied, but it is not compatible with the Android plugins." problem if my KMM module has to target both platforms: jvm and android

I have this declaration in my kotlin/js gradle build:

kotlin {
  jvmToolchain(17)
}

but as soon as I add the

id("io.kotest.multiplatform") version "5.5.5"

declaration to my build, gradle fails with:

e: .../build.gradle.kts:89:16: The integer literal does not conform to the expected type Action<Any>

I'm pretty sure this is because the kotest gradle plugin is pulling a Kotlin 1.6 version and I'm hitting https://youtrack.jetbrains.com/issue/KT-47924/Remove-annoying-cast-in-toolchain-extension-method-for-Kotlin-DSL with was fixed in 1.7.0. Any ideas on the best workaround?

I'm experimenting with Arrow's

raise()

functionality and I try to find a library function similar to the following hypothetical

orElse()

:

context(Raise<String>)
fun f1() = 1

context(Raise<String>)
fun f2(): Nothing = raise("error")

suspend inline fun <R, A> Effect<R, A>.orElse(noinline block: suspend (R) -> A) =
    fold(
        recover = block,
        transform = ::identity
    )

val v1 = effect { f1() }.orElse { 33 }
assertEquals(1, v1)

val v2 = effect { f2() }.orElse { 33 }
assertEquals(33, v2)

I use arrow 1.1.6-alpha.36. Thanks.

I am trying to use SQLDelight 2.0.0-alpha02 but it seems like I'm missing something with the setup. Using the guide ( https://cashapp.github.io/sqldelight/android_sqlite/ ) but then replacing it with the new namespace

app.cash.sqldelight

and version

2.0.0-alpha02

gradle seems to be a bit unhappy. I'm using AS Dolphin Canary 9.

We are using SQLDelight with Coroutines in a Kotlin Multiplatform project. Hope this is the right place to ask. We couldn't really fully grasp the limitations on Kotlin Native. Our iOS team has pending questions regarding performance and whether if we will actually be doing database I/O operation on main thread. Can someone enlighten me and point me to right direction? Thanks.

Hi! Regarding MDC (with use of

withLoggingContext

). Is there considered any best practices for MDC and exceptions? The current implementation of withLoggingContext clears all MDC fields if an exception inside the flow occurs. I would very much like the exception to contain the MDC-information. One solution could be that

withLoggingContext

provides an option to provided an exception handler. (I think it is important not to couple the exception handling to close to the framework). Do you have any thoughts about this/what do you think? Or any suggestion on how the mdc is kept for exceptions? For my case I think the best use of an exception handler would be to add an “meta”-exception to the original exception (

addSuppressed

method ) (which is what I have done in my code, by creating a wrapper method around

withLoggingContext

)