-
Notifications
You must be signed in to change notification settings - Fork 58
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
Support wasmJs target #771
Support wasmJs target #771
Conversation
...adleConfiguration/src/main/kotlin/com/badoo/reaktive/configuration/MppConfigurationPlugin.kt
Outdated
Show resolved
Hide resolved
Thanks! I've been working on this, and been waiting for stable coroutines version. Could you please sync with my branch? master...arkivanov:Reaktive:wasm |
Sure =) |
650e174
to
9f1534c
Compare
@arkivanov I've cherry-picked changes from your branch which were relevant:
|
...adleConfiguration/src/main/kotlin/com/badoo/reaktive/configuration/MppConfigurationPlugin.kt
Outdated
Show resolved
Hide resolved
...adleConfiguration/src/main/kotlin/com/badoo/reaktive/configuration/MppConfigurationPlugin.kt
Outdated
Show resolved
Hide resolved
...adleConfiguration/src/main/kotlin/com/badoo/reaktive/configuration/MppConfigurationPlugin.kt
Outdated
Show resolved
Hide resolved
...adleConfiguration/src/main/kotlin/com/badoo/reaktive/configuration/MppConfigurationPlugin.kt
Outdated
Show resolved
Hide resolved
...adleConfiguration/src/main/kotlin/com/badoo/reaktive/configuration/MppConfigurationPlugin.kt
Show resolved
Hide resolved
includedBuild/gradleConfiguration/src/main/kotlin/com/badoo/reaktive/configuration/Target.kt
Show resolved
Hide resolved
…chronizedCompat`. cleanup.
reaktive/src/wasmJsMain/kotlin/com/badoo/reaktive/scheduler/JsFunctions.kt
Outdated
Show resolved
Hide resolved
reaktive/src/jsCommonTest/kotlin/com/badoo/reaktive/scheduler/MainSchedulerTest.kt
Outdated
Show resolved
Hide resolved
reaktive/src/jsCommonTest/kotlin/com/badoo/reaktive/scheduler/MainSchedulerTest.kt
Outdated
Show resolved
Hide resolved
reaktive/src/jsCommonTest/kotlin/com/badoo/reaktive/scheduler/MainSchedulerTest.kt
Outdated
Show resolved
Hide resolved
reaktive/src/jsCommonTest/kotlin/com/badoo/reaktive/scheduler/MainSchedulerTest.kt
Outdated
Show resolved
Hide resolved
reaktive/src/jsCommonTest/kotlin/com/badoo/reaktive/scheduler/MainSchedulerTest.kt
Outdated
Show resolved
Hide resolved
Detekt seems failing.
|
479aff3
to
f37282e
Compare
@arkivanov WDYT about merging/releasing? Merge now or later when coroutines are not RC? The same for the release process. |
I think we could merge now and release |
Should we also enable You can debug CI by creating sub-bracnch from yours and opening PR to master of your fork. |
I think for now we don't need |
I will take a look soon |
Follow up: I'm still fixing this. Linux build hangs on |
…ly removes timeout and interval ids on first task execution.
e87de8c
to
d32fd31
Compare
5d97800
to
e39b45f
Compare
I'm able to reproduce it locally, I can take a look. |
@arkivanov I've fixed all issues |
@arkivanov Please take a look at my changes inside of MainScheduler. There was a bug (as far as I can tell, maybe I'm wrong 🙂 ) - interval and timeout ids were removed from list of interval ids/timeout ids immediately after task is executed first time. That's a strange logic, I've removed it. |
It appears that a Node test hangs if there are any pending task (that are not executed yet). I was able to fix the test by just removing this line. Looks like this is an actual bug, as we are removing the interval (periodic) task id after the first execution, and so later it can't be cancelled. What do you think? |
I think we can revert the rest of the unrelated changes after the commit f37282e? |
Are you sure it's unrelated?
I can squash some commits to make history cleaner, if you want |
Hmm, I will refactor the |
e39b45f
to
1af5326
Compare
@arkivanov I once again refactored a bit. |
Sorry, I will fix detekt complaints in a moment |
1af5326
to
11174af
Compare
@@ -0,0 +1,33 @@ | |||
package com.badoo.reaktive.scheduler | |||
|
|||
internal actual fun jsSetTimeout(task: () -> Unit, delayMillis: Int): TimeoutId = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can still return Int
and avoid TimeoutId
. This actual
function could be as follows:
internal actual fun jsSetTimeout(task: () -> Unit, delayMillis: Int): Int =
window.setTimeout(
handler = { task().toJsReference() },
timeout = delayMillis,
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about NodeJS runtime where setTimeout
returns Timeout
object instead of Int
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, you are correct. Let's use the current approach with expect/actual TimeoutId.
id = | ||
globalThis.setTimeout( | ||
{ | ||
timeoutIds.remove(id) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we still need to remove this id. The task is only executed once. Otherwise ids will accumulate and consume memory.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Year, sure
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is the root of the bug 🙂
Someone wanted to remove id only for timeout, but somehow managed to do the same for interval =)
assertEquals(expectedResults, results) | ||
// Required to pass test on NodeJS environment since runtime waits | ||
// for all tasks to cancel or finish their work. | ||
executor.cancel() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This callback is only called on success. It's better to dispose the executor as follows:
return checkTicks.toList()
.doOnBeforeFinally(executor::dispose)
.testAwait { ... }
11174af
to
a4fe69f
Compare
@@ -0,0 +1,33 @@ | |||
package com.badoo.reaktive.scheduler | |||
|
|||
internal actual fun jsSetTimeout(task: () -> Unit, delayMillis: Int): TimeoutId = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, you are correct. Let's use the current approach with expect/actual TimeoutId.
Fixes #767
In this PR:
js
sources withwasmJs
by introducing thejsWasmJsCommon
sourceSets.