Call remote tasks of service workspace #75

Closed
winter-yuki wants to merge 25 commits from winter-yuki/distributed into 0.6
7 changed files with 410 additions and 3 deletions
Showing only changes of commit a4044c82a0 - Show all commits

View File

@ -29,4 +29,7 @@ public fun <T : Any> Data<T>.named(name: Name): NamedData<T> = if (this is Named
NamedDataImpl(name, this.data)
} else {
NamedDataImpl(name, this)
}
}
public operator fun <T : Any> NamedData<T>.component1(): Name = name
public operator fun <T : Any> NamedData<T>.component2(): Data<T> = data

View File

@ -5,16 +5,37 @@ plugins {
kotlin {
sourceSets {
commonMain{
commonMain {
dependencies {
api(project(":dataforge-context"))
api(project(":dataforge-data"))
api(project(":dataforge-io"))
}
}
jvmMain {
dependencies {
// TODO include fat jar of lambdarpc
api(files("lambdarpc-core-0.0.1.jar"))
runtimeOnly("io.grpc:grpc-netty-shaded:1.44.0")
api("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.6.0")
api("io.grpc:grpc-protobuf:1.44.0")
api("com.google.protobuf:protobuf-java-util:3.19.4")
api("com.google.protobuf:protobuf-kotlin:3.19.4")
api("io.grpc:grpc-kotlin-stub:1.2.1")
api("org.jetbrains.kotlinx:kotlinx-serialization-json:1.3.2")
api("org.slf4j:slf4j-simple:1.7.36")
api("io.github.microutils:kotlin-logging-jvm:2.1.21")
}
}
}
}
readme{
kscience {
useSerialization {
json()
}
}
readme {
maturity = ru.mipt.npm.gradle.Maturity.EXPERIMENTAL
}

View File

@ -17,6 +17,11 @@ import kotlin.reflect.typeOf
@Type(TYPE)
public interface Task<out T : Any> : Described {
/**
* Type of the task result data.
*/
public val resultType: KType
/**
* Compute a [TaskResult] using given meta. In general, the result is lazy and represents both computation model
* and a handler for actual result
@ -55,6 +60,9 @@ public fun <T : Any> Task(
builder: suspend TaskResultBuilder<T>.() -> Unit,
): Task<T> = object : Task<T> {
override val resultType: KType
get() = resultType
override val descriptor: MetaDescriptor? = descriptor
override suspend fun execute(

View File

@ -0,0 +1,31 @@
altavir commented 2022-05-04 17:56:58 +03:00 (Migrated from github.com)
Review

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.
altavir commented 2022-05-04 17:56:58 +03:00 (Migrated from github.com)
Review

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.
altavir commented 2022-05-04 17:57:32 +03:00 (Migrated from github.com)
Review

There is already WorkspacePlugin that does similar thing.

There is already WorkspacePlugin that does similar thing.
altavir commented 2022-05-04 17:57:32 +03:00 (Migrated from github.com)
Review

There is already WorkspacePlugin that does similar thing.

There is already WorkspacePlugin that does similar thing.
winter-yuki commented 2022-05-09 19:26:55 +03:00 (Migrated from github.com)
Review

KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration:

private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin(
    MyPlugin.tag,
    endpoint,
    "task".asName() to typeOf<Int>()
)
KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration: ```kotlin private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin( MyPlugin.tag, endpoint, "task".asName() to typeOf<Int>() ) ```
winter-yuki commented 2022-05-09 19:26:55 +03:00 (Migrated from github.com)
Review

KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration:

private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin(
    MyPlugin.tag,
    endpoint,
    "task".asName() to typeOf<Int>()
)
KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration: ```kotlin private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin( MyPlugin.tag, endpoint, "task".asName() to typeOf<Int>() ) ```
winter-yuki commented 2022-05-09 19:29:38 +03:00 (Migrated from github.com)
Review

WorkspacePlugin is also a TaskContainer, which I did not want to. ClientPlugin is just a port to existing remote plugin and has no tasks locally.

`WorkspacePlugin` is also a `TaskContainer`, which I did not want to. `ClientPlugin` is just a port to existing remote plugin and has no tasks locally.
winter-yuki commented 2022-05-09 19:29:38 +03:00 (Migrated from github.com)
Review

WorkspacePlugin is also a TaskContainer, which I did not want to. ClientPlugin is just a port to existing remote plugin and has no tasks locally.

`WorkspacePlugin` is also a `TaskContainer`, which I did not want to. `ClientPlugin` is just a port to existing remote plugin and has no tasks locally.
package space.kscience.dataforge.workspace.distributed
altavir commented 2022-05-04 17:56:58 +03:00 (Migrated from github.com)
Review

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.
altavir commented 2022-05-04 17:57:32 +03:00 (Migrated from github.com)
Review

There is already WorkspacePlugin that does similar thing.

There is already WorkspacePlugin that does similar thing.
winter-yuki commented 2022-05-09 19:26:55 +03:00 (Migrated from github.com)
Review

KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration:

private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin(
    MyPlugin.tag,
    endpoint,
    "task".asName() to typeOf<Int>()
)
KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration: ```kotlin private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin( MyPlugin.tag, endpoint, "task".asName() to typeOf<Int>() ) ```
winter-yuki commented 2022-05-09 19:29:38 +03:00 (Migrated from github.com)
Review

WorkspacePlugin is also a TaskContainer, which I did not want to. ClientPlugin is just a port to existing remote plugin and has no tasks locally.

`WorkspacePlugin` is also a `TaskContainer`, which I did not want to. `ClientPlugin` is just a port to existing remote plugin and has no tasks locally.
altavir commented 2022-05-04 17:56:58 +03:00 (Migrated from github.com)
Review

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.
altavir commented 2022-05-04 17:57:32 +03:00 (Migrated from github.com)
Review

There is already WorkspacePlugin that does similar thing.

There is already WorkspacePlugin that does similar thing.
winter-yuki commented 2022-05-09 19:26:55 +03:00 (Migrated from github.com)
Review

KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration:

private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin(
    MyPlugin.tag,
    endpoint,
    "task".asName() to typeOf<Int>()
)
KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration: ```kotlin private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin( MyPlugin.tag, endpoint, "task".asName() to typeOf<Int>() ) ```
winter-yuki commented 2022-05-09 19:29:38 +03:00 (Migrated from github.com)
Review

WorkspacePlugin is also a TaskContainer, which I did not want to. ClientPlugin is just a port to existing remote plugin and has no tasks locally.

`WorkspacePlugin` is also a `TaskContainer`, which I did not want to. `ClientPlugin` is just a port to existing remote plugin and has no tasks locally.
import io.lambdarpc.utils.Endpoint
altavir commented 2022-05-04 17:56:58 +03:00 (Migrated from github.com)
Review

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.
altavir commented 2022-05-04 17:57:32 +03:00 (Migrated from github.com)
Review

There is already WorkspacePlugin that does similar thing.

There is already WorkspacePlugin that does similar thing.
winter-yuki commented 2022-05-09 19:26:55 +03:00 (Migrated from github.com)
Review

KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration:

private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin(
    MyPlugin.tag,
    endpoint,
    "task".asName() to typeOf<Int>()
)
KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration: ```kotlin private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin( MyPlugin.tag, endpoint, "task".asName() to typeOf<Int>() ) ```
winter-yuki commented 2022-05-09 19:29:38 +03:00 (Migrated from github.com)
Review

WorkspacePlugin is also a TaskContainer, which I did not want to. ClientPlugin is just a port to existing remote plugin and has no tasks locally.

`WorkspacePlugin` is also a `TaskContainer`, which I did not want to. `ClientPlugin` is just a port to existing remote plugin and has no tasks locally.
import space.kscience.dataforge.context.AbstractPlugin
altavir commented 2022-05-04 17:56:58 +03:00 (Migrated from github.com)
Review

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.
altavir commented 2022-05-04 17:57:32 +03:00 (Migrated from github.com)
Review

There is already WorkspacePlugin that does similar thing.

There is already WorkspacePlugin that does similar thing.
winter-yuki commented 2022-05-09 19:26:55 +03:00 (Migrated from github.com)
Review

KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration:

private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin(
    MyPlugin.tag,
    endpoint,
    "task".asName() to typeOf<Int>()
)
KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration: ```kotlin private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin( MyPlugin.tag, endpoint, "task".asName() to typeOf<Int>() ) ```
winter-yuki commented 2022-05-09 19:29:38 +03:00 (Migrated from github.com)
Review

WorkspacePlugin is also a TaskContainer, which I did not want to. ClientPlugin is just a port to existing remote plugin and has no tasks locally.

`WorkspacePlugin` is also a `TaskContainer`, which I did not want to. `ClientPlugin` is just a port to existing remote plugin and has no tasks locally.
import space.kscience.dataforge.context.PluginTag
altavir commented 2022-05-04 17:56:58 +03:00 (Migrated from github.com)
Review

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.
altavir commented 2022-05-04 17:57:32 +03:00 (Migrated from github.com)
Review

There is already WorkspacePlugin that does similar thing.

There is already WorkspacePlugin that does similar thing.
winter-yuki commented 2022-05-09 19:26:55 +03:00 (Migrated from github.com)
Review

KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration:

private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin(
    MyPlugin.tag,
    endpoint,
    "task".asName() to typeOf<Int>()
)
KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration: ```kotlin private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin( MyPlugin.tag, endpoint, "task".asName() to typeOf<Int>() ) ```
winter-yuki commented 2022-05-09 19:29:38 +03:00 (Migrated from github.com)
Review

WorkspacePlugin is also a TaskContainer, which I did not want to. ClientPlugin is just a port to existing remote plugin and has no tasks locally.

`WorkspacePlugin` is also a `TaskContainer`, which I did not want to. `ClientPlugin` is just a port to existing remote plugin and has no tasks locally.
import space.kscience.dataforge.names.Name
altavir commented 2022-05-04 17:56:58 +03:00 (Migrated from github.com)
Review

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.
altavir commented 2022-05-04 17:57:32 +03:00 (Migrated from github.com)
Review

There is already WorkspacePlugin that does similar thing.

There is already WorkspacePlugin that does similar thing.
winter-yuki commented 2022-05-09 19:26:55 +03:00 (Migrated from github.com)
Review

KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration:

private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin(
    MyPlugin.tag,
    endpoint,
    "task".asName() to typeOf<Int>()
)
KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration: ```kotlin private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin( MyPlugin.tag, endpoint, "task".asName() to typeOf<Int>() ) ```
winter-yuki commented 2022-05-09 19:29:38 +03:00 (Migrated from github.com)
Review

WorkspacePlugin is also a TaskContainer, which I did not want to. ClientPlugin is just a port to existing remote plugin and has no tasks locally.

`WorkspacePlugin` is also a `TaskContainer`, which I did not want to. `ClientPlugin` is just a port to existing remote plugin and has no tasks locally.
import space.kscience.dataforge.workspace.Task
altavir commented 2022-05-04 17:56:58 +03:00 (Migrated from github.com)
Review

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.
altavir commented 2022-05-04 17:57:32 +03:00 (Migrated from github.com)
Review

There is already WorkspacePlugin that does similar thing.

There is already WorkspacePlugin that does similar thing.
winter-yuki commented 2022-05-09 19:26:55 +03:00 (Migrated from github.com)
Review

KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration:

private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin(
    MyPlugin.tag,
    endpoint,
    "task".asName() to typeOf<Int>()
)
KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration: ```kotlin private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin( MyPlugin.tag, endpoint, "task".asName() to typeOf<Int>() ) ```
winter-yuki commented 2022-05-09 19:29:38 +03:00 (Migrated from github.com)
Review

WorkspacePlugin is also a TaskContainer, which I did not want to. ClientPlugin is just a port to existing remote plugin and has no tasks locally.

`WorkspacePlugin` is also a `TaskContainer`, which I did not want to. `ClientPlugin` is just a port to existing remote plugin and has no tasks locally.
import kotlin.reflect.KType
altavir commented 2022-05-04 17:56:58 +03:00 (Migrated from github.com)
Review

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.
altavir commented 2022-05-04 17:57:32 +03:00 (Migrated from github.com)
Review

There is already WorkspacePlugin that does similar thing.

There is already WorkspacePlugin that does similar thing.
winter-yuki commented 2022-05-09 19:26:55 +03:00 (Migrated from github.com)
Review

KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration:

private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin(
    MyPlugin.tag,
    endpoint,
    "task".asName() to typeOf<Int>()
)
KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration: ```kotlin private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin( MyPlugin.tag, endpoint, "task".asName() to typeOf<Int>() ) ```
winter-yuki commented 2022-05-09 19:29:38 +03:00 (Migrated from github.com)
Review

WorkspacePlugin is also a TaskContainer, which I did not want to. ClientPlugin is just a port to existing remote plugin and has no tasks locally.

`WorkspacePlugin` is also a `TaskContainer`, which I did not want to. `ClientPlugin` is just a port to existing remote plugin and has no tasks locally.
altavir commented 2022-05-04 17:56:58 +03:00 (Migrated from github.com)
Review

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.
altavir commented 2022-05-04 17:57:32 +03:00 (Migrated from github.com)
Review

There is already WorkspacePlugin that does similar thing.

There is already WorkspacePlugin that does similar thing.
winter-yuki commented 2022-05-09 19:26:55 +03:00 (Migrated from github.com)
Review

KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration:

private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin(
    MyPlugin.tag,
    endpoint,
    "task".asName() to typeOf<Int>()
)
KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration: ```kotlin private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin( MyPlugin.tag, endpoint, "task".asName() to typeOf<Int>() ) ```
winter-yuki commented 2022-05-09 19:29:38 +03:00 (Migrated from github.com)
Review

WorkspacePlugin is also a TaskContainer, which I did not want to. ClientPlugin is just a port to existing remote plugin and has no tasks locally.

`WorkspacePlugin` is also a `TaskContainer`, which I did not want to. `ClientPlugin` is just a port to existing remote plugin and has no tasks locally.
/**
altavir commented 2022-05-04 17:56:58 +03:00 (Migrated from github.com)
Review

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.
altavir commented 2022-05-04 17:57:32 +03:00 (Migrated from github.com)
Review

There is already WorkspacePlugin that does similar thing.

There is already WorkspacePlugin that does similar thing.
winter-yuki commented 2022-05-09 19:26:55 +03:00 (Migrated from github.com)
Review

KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration:

private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin(
    MyPlugin.tag,
    endpoint,
    "task".asName() to typeOf<Int>()
)
KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration: ```kotlin private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin( MyPlugin.tag, endpoint, "task".asName() to typeOf<Int>() ) ```
winter-yuki commented 2022-05-09 19:29:38 +03:00 (Migrated from github.com)
Review

WorkspacePlugin is also a TaskContainer, which I did not want to. ClientPlugin is just a port to existing remote plugin and has no tasks locally.

`WorkspacePlugin` is also a `TaskContainer`, which I did not want to. `ClientPlugin` is just a port to existing remote plugin and has no tasks locally.
* Plugin that purpose is to communicate with remote plugins.
altavir commented 2022-05-04 17:56:58 +03:00 (Migrated from github.com)
Review

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.
altavir commented 2022-05-04 17:57:32 +03:00 (Migrated from github.com)
Review

There is already WorkspacePlugin that does similar thing.

There is already WorkspacePlugin that does similar thing.
winter-yuki commented 2022-05-09 19:26:55 +03:00 (Migrated from github.com)
Review

KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration:

private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin(
    MyPlugin.tag,
    endpoint,
    "task".asName() to typeOf<Int>()
)
KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration: ```kotlin private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin( MyPlugin.tag, endpoint, "task".asName() to typeOf<Int>() ) ```
winter-yuki commented 2022-05-09 19:29:38 +03:00 (Migrated from github.com)
Review

WorkspacePlugin is also a TaskContainer, which I did not want to. ClientPlugin is just a port to existing remote plugin and has no tasks locally.

`WorkspacePlugin` is also a `TaskContainer`, which I did not want to. `ClientPlugin` is just a port to existing remote plugin and has no tasks locally.
* @param tag Tag og the [ClientWorkspacePlugin] should be equal to the tag of the corresponding remote plugin.
altavir commented 2022-05-04 17:56:58 +03:00 (Migrated from github.com)
Review

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.
altavir commented 2022-05-04 17:57:32 +03:00 (Migrated from github.com)
Review

There is already WorkspacePlugin that does similar thing.

There is already WorkspacePlugin that does similar thing.
winter-yuki commented 2022-05-09 19:26:55 +03:00 (Migrated from github.com)
Review

KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration:

private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin(
    MyPlugin.tag,
    endpoint,
    "task".asName() to typeOf<Int>()
)
KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration: ```kotlin private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin( MyPlugin.tag, endpoint, "task".asName() to typeOf<Int>() ) ```
winter-yuki commented 2022-05-09 19:29:38 +03:00 (Migrated from github.com)
Review

WorkspacePlugin is also a TaskContainer, which I did not want to. ClientPlugin is just a port to existing remote plugin and has no tasks locally.

`WorkspacePlugin` is also a `TaskContainer`, which I did not want to. `ClientPlugin` is just a port to existing remote plugin and has no tasks locally.
* @param endpoint Endpoint of the remote plugin.
altavir commented 2022-05-04 17:56:58 +03:00 (Migrated from github.com)
Review

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.
altavir commented 2022-05-04 17:57:32 +03:00 (Migrated from github.com)
Review

There is already WorkspacePlugin that does similar thing.

There is already WorkspacePlugin that does similar thing.
winter-yuki commented 2022-05-09 19:26:55 +03:00 (Migrated from github.com)
Review

KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration:

private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin(
    MyPlugin.tag,
    endpoint,
    "task".asName() to typeOf<Int>()
)
KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration: ```kotlin private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin( MyPlugin.tag, endpoint, "task".asName() to typeOf<Int>() ) ```
winter-yuki commented 2022-05-09 19:29:38 +03:00 (Migrated from github.com)
Review

WorkspacePlugin is also a TaskContainer, which I did not want to. ClientPlugin is just a port to existing remote plugin and has no tasks locally.

`WorkspacePlugin` is also a `TaskContainer`, which I did not want to. `ClientPlugin` is just a port to existing remote plugin and has no tasks locally.
* @param tasks Enumeration of names of remote tasks and their result types.
altavir commented 2022-05-04 17:56:58 +03:00 (Migrated from github.com)
Review

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.
altavir commented 2022-05-04 17:57:32 +03:00 (Migrated from github.com)
Review

There is already WorkspacePlugin that does similar thing.

There is already WorkspacePlugin that does similar thing.
winter-yuki commented 2022-05-09 19:26:55 +03:00 (Migrated from github.com)
Review

KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration:

private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin(
    MyPlugin.tag,
    endpoint,
    "task".asName() to typeOf<Int>()
)
KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration: ```kotlin private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin( MyPlugin.tag, endpoint, "task".asName() to typeOf<Int>() ) ```
winter-yuki commented 2022-05-09 19:29:38 +03:00 (Migrated from github.com)
Review

WorkspacePlugin is also a TaskContainer, which I did not want to. ClientPlugin is just a port to existing remote plugin and has no tasks locally.

`WorkspacePlugin` is also a `TaskContainer`, which I did not want to. `ClientPlugin` is just a port to existing remote plugin and has no tasks locally.
*/
altavir commented 2022-05-04 17:56:58 +03:00 (Migrated from github.com)
Review

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.
altavir commented 2022-05-04 17:57:32 +03:00 (Migrated from github.com)
Review

There is already WorkspacePlugin that does similar thing.

There is already WorkspacePlugin that does similar thing.
winter-yuki commented 2022-05-09 19:26:55 +03:00 (Migrated from github.com)
Review

KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration:

private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin(
    MyPlugin.tag,
    endpoint,
    "task".asName() to typeOf<Int>()
)
KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration: ```kotlin private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin( MyPlugin.tag, endpoint, "task".asName() to typeOf<Int>() ) ```
winter-yuki commented 2022-05-09 19:29:38 +03:00 (Migrated from github.com)
Review

WorkspacePlugin is also a TaskContainer, which I did not want to. ClientPlugin is just a port to existing remote plugin and has no tasks locally.

`WorkspacePlugin` is also a `TaskContainer`, which I did not want to. `ClientPlugin` is just a port to existing remote plugin and has no tasks locally.
public abstract class ClientWorkspacePlugin(
altavir commented 2022-05-04 17:56:58 +03:00 (Migrated from github.com)
Review

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.
altavir commented 2022-05-04 17:57:32 +03:00 (Migrated from github.com)
Review

There is already WorkspacePlugin that does similar thing.

There is already WorkspacePlugin that does similar thing.
winter-yuki commented 2022-05-09 19:26:55 +03:00 (Migrated from github.com)
Review

KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration:

private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin(
    MyPlugin.tag,
    endpoint,
    "task".asName() to typeOf<Int>()
)
KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration: ```kotlin private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin( MyPlugin.tag, endpoint, "task".asName() to typeOf<Int>() ) ```
winter-yuki commented 2022-05-09 19:29:38 +03:00 (Migrated from github.com)
Review

WorkspacePlugin is also a TaskContainer, which I did not want to. ClientPlugin is just a port to existing remote plugin and has no tasks locally.

`WorkspacePlugin` is also a `TaskContainer`, which I did not want to. `ClientPlugin` is just a port to existing remote plugin and has no tasks locally.
override val tag: PluginTag,
altavir commented 2022-05-04 17:56:58 +03:00 (Migrated from github.com)
Review

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.
altavir commented 2022-05-04 17:57:32 +03:00 (Migrated from github.com)
Review

There is already WorkspacePlugin that does similar thing.

There is already WorkspacePlugin that does similar thing.
winter-yuki commented 2022-05-09 19:26:55 +03:00 (Migrated from github.com)
Review

KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration:

private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin(
    MyPlugin.tag,
    endpoint,
    "task".asName() to typeOf<Int>()
)
KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration: ```kotlin private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin( MyPlugin.tag, endpoint, "task".asName() to typeOf<Int>() ) ```
winter-yuki commented 2022-05-09 19:29:38 +03:00 (Migrated from github.com)
Review

WorkspacePlugin is also a TaskContainer, which I did not want to. ClientPlugin is just a port to existing remote plugin and has no tasks locally.

`WorkspacePlugin` is also a `TaskContainer`, which I did not want to. `ClientPlugin` is just a port to existing remote plugin and has no tasks locally.
endpoint: Endpoint,
altavir commented 2022-05-04 17:56:58 +03:00 (Migrated from github.com)
Review

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.
altavir commented 2022-05-04 17:57:32 +03:00 (Migrated from github.com)
Review

There is already WorkspacePlugin that does similar thing.

There is already WorkspacePlugin that does similar thing.
winter-yuki commented 2022-05-09 19:26:55 +03:00 (Migrated from github.com)
Review

KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration:

private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin(
    MyPlugin.tag,
    endpoint,
    "task".asName() to typeOf<Int>()
)
KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration: ```kotlin private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin( MyPlugin.tag, endpoint, "task".asName() to typeOf<Int>() ) ```
winter-yuki commented 2022-05-09 19:29:38 +03:00 (Migrated from github.com)
Review

WorkspacePlugin is also a TaskContainer, which I did not want to. ClientPlugin is just a port to existing remote plugin and has no tasks locally.

`WorkspacePlugin` is also a `TaskContainer`, which I did not want to. `ClientPlugin` is just a port to existing remote plugin and has no tasks locally.
vararg tasks: Pair<Name, KType>,
altavir commented 2022-05-04 17:56:58 +03:00 (Migrated from github.com)
Review

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.
altavir commented 2022-05-04 17:57:32 +03:00 (Migrated from github.com)
Review

There is already WorkspacePlugin that does similar thing.

There is already WorkspacePlugin that does similar thing.
winter-yuki commented 2022-05-09 19:26:55 +03:00 (Migrated from github.com)
Review

KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration:

private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin(
    MyPlugin.tag,
    endpoint,
    "task".asName() to typeOf<Int>()
)
KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration: ```kotlin private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin( MyPlugin.tag, endpoint, "task".asName() to typeOf<Int>() ) ```
winter-yuki commented 2022-05-09 19:29:38 +03:00 (Migrated from github.com)
Review

WorkspacePlugin is also a TaskContainer, which I did not want to. ClientPlugin is just a port to existing remote plugin and has no tasks locally.

`WorkspacePlugin` is also a `TaskContainer`, which I did not want to. `ClientPlugin` is just a port to existing remote plugin and has no tasks locally.
) : AbstractPlugin() {
altavir commented 2022-05-04 17:56:58 +03:00 (Migrated from github.com)
Review

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.
altavir commented 2022-05-04 17:57:32 +03:00 (Migrated from github.com)
Review

There is already WorkspacePlugin that does similar thing.

There is already WorkspacePlugin that does similar thing.
winter-yuki commented 2022-05-09 19:26:55 +03:00 (Migrated from github.com)
Review

KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration:

private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin(
    MyPlugin.tag,
    endpoint,
    "task".asName() to typeOf<Int>()
)
KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration: ```kotlin private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin( MyPlugin.tag, endpoint, "task".asName() to typeOf<Int>() ) ```
winter-yuki commented 2022-05-09 19:29:38 +03:00 (Migrated from github.com)
Review

WorkspacePlugin is also a TaskContainer, which I did not want to. ClientPlugin is just a port to existing remote plugin and has no tasks locally.

`WorkspacePlugin` is also a `TaskContainer`, which I did not want to. `ClientPlugin` is just a port to existing remote plugin and has no tasks locally.
altavir commented 2022-05-04 17:56:58 +03:00 (Migrated from github.com)
Review

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.
altavir commented 2022-05-04 17:57:32 +03:00 (Migrated from github.com)
Review

There is already WorkspacePlugin that does similar thing.

There is already WorkspacePlugin that does similar thing.
winter-yuki commented 2022-05-09 19:26:55 +03:00 (Migrated from github.com)
Review

KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration:

private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin(
    MyPlugin.tag,
    endpoint,
    "task".asName() to typeOf<Int>()
)
KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration: ```kotlin private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin( MyPlugin.tag, endpoint, "task".asName() to typeOf<Int>() ) ```
winter-yuki commented 2022-05-09 19:29:38 +03:00 (Migrated from github.com)
Review

WorkspacePlugin is also a TaskContainer, which I did not want to. ClientPlugin is just a port to existing remote plugin and has no tasks locally.

`WorkspacePlugin` is also a `TaskContainer`, which I did not want to. `ClientPlugin` is just a port to existing remote plugin and has no tasks locally.
private val tasks: Map<Name, Task<*>> = tasks.associate { (name, type) ->
altavir commented 2022-05-04 17:56:58 +03:00 (Migrated from github.com)
Review

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.
altavir commented 2022-05-04 17:57:32 +03:00 (Migrated from github.com)
Review

There is already WorkspacePlugin that does similar thing.

There is already WorkspacePlugin that does similar thing.
winter-yuki commented 2022-05-09 19:26:55 +03:00 (Migrated from github.com)
Review

KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration:

private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin(
    MyPlugin.tag,
    endpoint,
    "task".asName() to typeOf<Int>()
)
KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration: ```kotlin private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin( MyPlugin.tag, endpoint, "task".asName() to typeOf<Int>() ) ```
winter-yuki commented 2022-05-09 19:29:38 +03:00 (Migrated from github.com)
Review

WorkspacePlugin is also a TaskContainer, which I did not want to. ClientPlugin is just a port to existing remote plugin and has no tasks locally.

`WorkspacePlugin` is also a `TaskContainer`, which I did not want to. `ClientPlugin` is just a port to existing remote plugin and has no tasks locally.
name to RemoteTask<Any>(endpoint, type)
altavir commented 2022-05-04 17:56:58 +03:00 (Migrated from github.com)
Review

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.
altavir commented 2022-05-04 17:57:32 +03:00 (Migrated from github.com)
Review

There is already WorkspacePlugin that does similar thing.

There is already WorkspacePlugin that does similar thing.
winter-yuki commented 2022-05-09 19:26:55 +03:00 (Migrated from github.com)
Review

KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration:

private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin(
    MyPlugin.tag,
    endpoint,
    "task".asName() to typeOf<Int>()
)
KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration: ```kotlin private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin( MyPlugin.tag, endpoint, "task".asName() to typeOf<Int>() ) ```
winter-yuki commented 2022-05-09 19:29:38 +03:00 (Migrated from github.com)
Review

WorkspacePlugin is also a TaskContainer, which I did not want to. ClientPlugin is just a port to existing remote plugin and has no tasks locally.

`WorkspacePlugin` is also a `TaskContainer`, which I did not want to. `ClientPlugin` is just a port to existing remote plugin and has no tasks locally.
}
altavir commented 2022-05-04 17:56:58 +03:00 (Migrated from github.com)
Review

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.
altavir commented 2022-05-04 17:57:32 +03:00 (Migrated from github.com)
Review

There is already WorkspacePlugin that does similar thing.

There is already WorkspacePlugin that does similar thing.
winter-yuki commented 2022-05-09 19:26:55 +03:00 (Migrated from github.com)
Review

KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration:

private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin(
    MyPlugin.tag,
    endpoint,
    "task".asName() to typeOf<Int>()
)
KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration: ```kotlin private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin( MyPlugin.tag, endpoint, "task".asName() to typeOf<Int>() ) ```
winter-yuki commented 2022-05-09 19:29:38 +03:00 (Migrated from github.com)
Review

WorkspacePlugin is also a TaskContainer, which I did not want to. ClientPlugin is just a port to existing remote plugin and has no tasks locally.

`WorkspacePlugin` is also a `TaskContainer`, which I did not want to. `ClientPlugin` is just a port to existing remote plugin and has no tasks locally.
altavir commented 2022-05-04 17:56:58 +03:00 (Migrated from github.com)
Review

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.
altavir commented 2022-05-04 17:57:32 +03:00 (Migrated from github.com)
Review

There is already WorkspacePlugin that does similar thing.

There is already WorkspacePlugin that does similar thing.
winter-yuki commented 2022-05-09 19:26:55 +03:00 (Migrated from github.com)
Review

KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration:

private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin(
    MyPlugin.tag,
    endpoint,
    "task".asName() to typeOf<Int>()
)
KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration: ```kotlin private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin( MyPlugin.tag, endpoint, "task".asName() to typeOf<Int>() ) ```
winter-yuki commented 2022-05-09 19:29:38 +03:00 (Migrated from github.com)
Review

WorkspacePlugin is also a TaskContainer, which I did not want to. ClientPlugin is just a port to existing remote plugin and has no tasks locally.

`WorkspacePlugin` is also a `TaskContainer`, which I did not want to. `ClientPlugin` is just a port to existing remote plugin and has no tasks locally.
override fun content(target: String): Map<Name, Any> =
altavir commented 2022-05-04 17:56:58 +03:00 (Migrated from github.com)
Review

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.
altavir commented 2022-05-04 17:57:32 +03:00 (Migrated from github.com)
Review

There is already WorkspacePlugin that does similar thing.

There is already WorkspacePlugin that does similar thing.
winter-yuki commented 2022-05-09 19:26:55 +03:00 (Migrated from github.com)
Review

KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration:

private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin(
    MyPlugin.tag,
    endpoint,
    "task".asName() to typeOf<Int>()
)
KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration: ```kotlin private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin( MyPlugin.tag, endpoint, "task".asName() to typeOf<Int>() ) ```
winter-yuki commented 2022-05-09 19:29:38 +03:00 (Migrated from github.com)
Review

WorkspacePlugin is also a TaskContainer, which I did not want to. ClientPlugin is just a port to existing remote plugin and has no tasks locally.

`WorkspacePlugin` is also a `TaskContainer`, which I did not want to. `ClientPlugin` is just a port to existing remote plugin and has no tasks locally.
when (target) {
altavir commented 2022-05-04 17:56:58 +03:00 (Migrated from github.com)
Review

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.
altavir commented 2022-05-04 17:57:32 +03:00 (Migrated from github.com)
Review

There is already WorkspacePlugin that does similar thing.

There is already WorkspacePlugin that does similar thing.
winter-yuki commented 2022-05-09 19:26:55 +03:00 (Migrated from github.com)
Review

KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration:

private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin(
    MyPlugin.tag,
    endpoint,
    "task".asName() to typeOf<Int>()
)
KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration: ```kotlin private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin( MyPlugin.tag, endpoint, "task".asName() to typeOf<Int>() ) ```
winter-yuki commented 2022-05-09 19:29:38 +03:00 (Migrated from github.com)
Review

WorkspacePlugin is also a TaskContainer, which I did not want to. ClientPlugin is just a port to existing remote plugin and has no tasks locally.

`WorkspacePlugin` is also a `TaskContainer`, which I did not want to. `ClientPlugin` is just a port to existing remote plugin and has no tasks locally.
Task.TYPE -> tasks
altavir commented 2022-05-04 17:56:58 +03:00 (Migrated from github.com)
Review

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.
altavir commented 2022-05-04 17:57:32 +03:00 (Migrated from github.com)
Review

There is already WorkspacePlugin that does similar thing.

There is already WorkspacePlugin that does similar thing.
winter-yuki commented 2022-05-09 19:26:55 +03:00 (Migrated from github.com)
Review

KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration:

private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin(
    MyPlugin.tag,
    endpoint,
    "task".asName() to typeOf<Int>()
)
KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration: ```kotlin private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin( MyPlugin.tag, endpoint, "task".asName() to typeOf<Int>() ) ```
winter-yuki commented 2022-05-09 19:29:38 +03:00 (Migrated from github.com)
Review

WorkspacePlugin is also a TaskContainer, which I did not want to. ClientPlugin is just a port to existing remote plugin and has no tasks locally.

`WorkspacePlugin` is also a `TaskContainer`, which I did not want to. `ClientPlugin` is just a port to existing remote plugin and has no tasks locally.
else -> emptyMap()
altavir commented 2022-05-04 17:56:58 +03:00 (Migrated from github.com)
Review

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.
altavir commented 2022-05-04 17:57:32 +03:00 (Migrated from github.com)
Review

There is already WorkspacePlugin that does similar thing.

There is already WorkspacePlugin that does similar thing.
winter-yuki commented 2022-05-09 19:26:55 +03:00 (Migrated from github.com)
Review

KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration:

private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin(
    MyPlugin.tag,
    endpoint,
    "task".asName() to typeOf<Int>()
)
KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration: ```kotlin private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin( MyPlugin.tag, endpoint, "task".asName() to typeOf<Int>() ) ```
winter-yuki commented 2022-05-09 19:29:38 +03:00 (Migrated from github.com)
Review

WorkspacePlugin is also a TaskContainer, which I did not want to. ClientPlugin is just a port to existing remote plugin and has no tasks locally.

`WorkspacePlugin` is also a `TaskContainer`, which I did not want to. `ClientPlugin` is just a port to existing remote plugin and has no tasks locally.
}
altavir commented 2022-05-04 17:56:58 +03:00 (Migrated from github.com)
Review

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.
altavir commented 2022-05-04 17:57:32 +03:00 (Migrated from github.com)
Review

There is already WorkspacePlugin that does similar thing.

There is already WorkspacePlugin that does similar thing.
winter-yuki commented 2022-05-09 19:26:55 +03:00 (Migrated from github.com)
Review

KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration:

private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin(
    MyPlugin.tag,
    endpoint,
    "task".asName() to typeOf<Int>()
)
KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration: ```kotlin private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin( MyPlugin.tag, endpoint, "task".asName() to typeOf<Int>() ) ```
winter-yuki commented 2022-05-09 19:29:38 +03:00 (Migrated from github.com)
Review

WorkspacePlugin is also a TaskContainer, which I did not want to. ClientPlugin is just a port to existing remote plugin and has no tasks locally.

`WorkspacePlugin` is also a `TaskContainer`, which I did not want to. `ClientPlugin` is just a port to existing remote plugin and has no tasks locally.
}
altavir commented 2022-05-04 17:56:58 +03:00 (Migrated from github.com)
Review

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.

Can we avoid inheriting both client and server plugins for each workspace? Context configuration is more or less serializeable, so it is better to share only configuration, not duplicate plugins.
altavir commented 2022-05-04 17:57:32 +03:00 (Migrated from github.com)
Review

There is already WorkspacePlugin that does similar thing.

There is already WorkspacePlugin that does similar thing.
winter-yuki commented 2022-05-09 19:26:55 +03:00 (Migrated from github.com)
Review

KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration:

private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin(
    MyPlugin.tag,
    endpoint,
    "task".asName() to typeOf<Int>()
)
KType is not serializable. Maybe it is possible to partially serialize remote plugin configuration, but I see no way to avoid a little bit of configuration: ```kotlin private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin( MyPlugin.tag, endpoint, "task".asName() to typeOf<Int>() ) ```
winter-yuki commented 2022-05-09 19:29:38 +03:00 (Migrated from github.com)
Review

WorkspacePlugin is also a TaskContainer, which I did not want to. ClientPlugin is just a port to existing remote plugin and has no tasks locally.

`WorkspacePlugin` is also a `TaskContainer`, which I did not want to. `ClientPlugin` is just a port to existing remote plugin and has no tasks locally.

View File

@ -0,0 +1,36 @@
winter-yuki commented 2022-05-01 10:24:32 +03:00 (Migrated from github.com)
Review

Use ConnectionPool

Use `ConnectionPool`
winter-yuki commented 2022-05-01 10:24:32 +03:00 (Migrated from github.com)
Review

Use ConnectionPool

Use `ConnectionPool`
altavir commented 2022-05-04 18:23:28 +03:00 (Migrated from github.com)
Review

Is it possible to avoid the cast? For example specialize output for this workspace?

Is it possible to avoid the cast? For example specialize output for this workspace?
altavir commented 2022-05-04 18:23:28 +03:00 (Migrated from github.com)
Review

Is it possible to avoid the cast? For example specialize output for this workspace?

Is it possible to avoid the cast? For example specialize output for this workspace?
package space.kscience.dataforge.workspace.distributed
winter-yuki commented 2022-05-01 10:24:32 +03:00 (Migrated from github.com)
Review

Use ConnectionPool

Use `ConnectionPool`
altavir commented 2022-05-04 18:23:28 +03:00 (Migrated from github.com)
Review

Is it possible to avoid the cast? For example specialize output for this workspace?

Is it possible to avoid the cast? For example specialize output for this workspace?
winter-yuki commented 2022-05-01 10:24:32 +03:00 (Migrated from github.com)
Review

Use ConnectionPool

Use `ConnectionPool`
altavir commented 2022-05-04 18:23:28 +03:00 (Migrated from github.com)
Review

Is it possible to avoid the cast? For example specialize output for this workspace?

Is it possible to avoid the cast? For example specialize output for this workspace?
import io.lambdarpc.dsl.ServiceDispatcher
winter-yuki commented 2022-05-01 10:24:32 +03:00 (Migrated from github.com)
Review

Use ConnectionPool

Use `ConnectionPool`
altavir commented 2022-05-04 18:23:28 +03:00 (Migrated from github.com)
Review

Is it possible to avoid the cast? For example specialize output for this workspace?

Is it possible to avoid the cast? For example specialize output for this workspace?
import io.lambdarpc.utils.Endpoint
winter-yuki commented 2022-05-01 10:24:32 +03:00 (Migrated from github.com)
Review

Use ConnectionPool

Use `ConnectionPool`
altavir commented 2022-05-04 18:23:28 +03:00 (Migrated from github.com)
Review

Is it possible to avoid the cast? For example specialize output for this workspace?

Is it possible to avoid the cast? For example specialize output for this workspace?
import kotlinx.coroutines.withContext
winter-yuki commented 2022-05-01 10:24:32 +03:00 (Migrated from github.com)
Review

Use ConnectionPool

Use `ConnectionPool`
altavir commented 2022-05-04 18:23:28 +03:00 (Migrated from github.com)
Review

Is it possible to avoid the cast? For example specialize output for this workspace?

Is it possible to avoid the cast? For example specialize output for this workspace?
import space.kscience.dataforge.data.DataSet
winter-yuki commented 2022-05-01 10:24:32 +03:00 (Migrated from github.com)
Review

Use ConnectionPool

Use `ConnectionPool`
altavir commented 2022-05-04 18:23:28 +03:00 (Migrated from github.com)
Review

Is it possible to avoid the cast? For example specialize output for this workspace?

Is it possible to avoid the cast? For example specialize output for this workspace?
import space.kscience.dataforge.meta.Meta
winter-yuki commented 2022-05-01 10:24:32 +03:00 (Migrated from github.com)
Review

Use ConnectionPool

Use `ConnectionPool`
altavir commented 2022-05-04 18:23:28 +03:00 (Migrated from github.com)
Review

Is it possible to avoid the cast? For example specialize output for this workspace?

Is it possible to avoid the cast? For example specialize output for this workspace?
import space.kscience.dataforge.meta.descriptors.MetaDescriptor
winter-yuki commented 2022-05-01 10:24:32 +03:00 (Migrated from github.com)
Review

Use ConnectionPool

Use `ConnectionPool`
altavir commented 2022-05-04 18:23:28 +03:00 (Migrated from github.com)
Review

Is it possible to avoid the cast? For example specialize output for this workspace?

Is it possible to avoid the cast? For example specialize output for this workspace?
import space.kscience.dataforge.names.Name
winter-yuki commented 2022-05-01 10:24:32 +03:00 (Migrated from github.com)
Review

Use ConnectionPool

Use `ConnectionPool`
altavir commented 2022-05-04 18:23:28 +03:00 (Migrated from github.com)
Review

Is it possible to avoid the cast? For example specialize output for this workspace?

Is it possible to avoid the cast? For example specialize output for this workspace?
import space.kscience.dataforge.workspace.Task
winter-yuki commented 2022-05-01 10:24:32 +03:00 (Migrated from github.com)
Review

Use ConnectionPool

Use `ConnectionPool`
altavir commented 2022-05-04 18:23:28 +03:00 (Migrated from github.com)
Review

Is it possible to avoid the cast? For example specialize output for this workspace?

Is it possible to avoid the cast? For example specialize output for this workspace?
import space.kscience.dataforge.workspace.TaskResult
winter-yuki commented 2022-05-01 10:24:32 +03:00 (Migrated from github.com)
Review

Use ConnectionPool

Use `ConnectionPool`
altavir commented 2022-05-04 18:23:28 +03:00 (Migrated from github.com)
Review

Is it possible to avoid the cast? For example specialize output for this workspace?

Is it possible to avoid the cast? For example specialize output for this workspace?
import space.kscience.dataforge.workspace.Workspace
winter-yuki commented 2022-05-01 10:24:32 +03:00 (Migrated from github.com)
Review

Use ConnectionPool

Use `ConnectionPool`
altavir commented 2022-05-04 18:23:28 +03:00 (Migrated from github.com)
Review

Is it possible to avoid the cast? For example specialize output for this workspace?

Is it possible to avoid the cast? For example specialize output for this workspace?
import space.kscience.dataforge.workspace.wrapResult
winter-yuki commented 2022-05-01 10:24:32 +03:00 (Migrated from github.com)
Review

Use ConnectionPool

Use `ConnectionPool`
altavir commented 2022-05-04 18:23:28 +03:00 (Migrated from github.com)
Review

Is it possible to avoid the cast? For example specialize output for this workspace?

Is it possible to avoid the cast? For example specialize output for this workspace?
import kotlin.reflect.KType
winter-yuki commented 2022-05-01 10:24:32 +03:00 (Migrated from github.com)
Review

Use ConnectionPool

Use `ConnectionPool`
altavir commented 2022-05-04 18:23:28 +03:00 (Migrated from github.com)
Review

Is it possible to avoid the cast? For example specialize output for this workspace?

Is it possible to avoid the cast? For example specialize output for this workspace?
winter-yuki commented 2022-05-01 10:24:32 +03:00 (Migrated from github.com)
Review

Use ConnectionPool

Use `ConnectionPool`
altavir commented 2022-05-04 18:23:28 +03:00 (Migrated from github.com)
Review

Is it possible to avoid the cast? For example specialize output for this workspace?

Is it possible to avoid the cast? For example specialize output for this workspace?
/**
winter-yuki commented 2022-05-01 10:24:32 +03:00 (Migrated from github.com)
Review

Use ConnectionPool

Use `ConnectionPool`
altavir commented 2022-05-04 18:23:28 +03:00 (Migrated from github.com)
Review

Is it possible to avoid the cast? For example specialize output for this workspace?

Is it possible to avoid the cast? For example specialize output for this workspace?
* Proxy task that communicates with the corresponding remote task.
winter-yuki commented 2022-05-01 10:24:32 +03:00 (Migrated from github.com)
Review

Use ConnectionPool

Use `ConnectionPool`
altavir commented 2022-05-04 18:23:28 +03:00 (Migrated from github.com)
Review

Is it possible to avoid the cast? For example specialize output for this workspace?

Is it possible to avoid the cast? For example specialize output for this workspace?
*/
winter-yuki commented 2022-05-01 10:24:32 +03:00 (Migrated from github.com)
Review

Use ConnectionPool

Use `ConnectionPool`
altavir commented 2022-05-04 18:23:28 +03:00 (Migrated from github.com)
Review

Is it possible to avoid the cast? For example specialize output for this workspace?

Is it possible to avoid the cast? For example specialize output for this workspace?
internal class RemoteTask<T : Any>(
winter-yuki commented 2022-05-01 10:24:32 +03:00 (Migrated from github.com)
Review

Use ConnectionPool

Use `ConnectionPool`
altavir commented 2022-05-04 18:23:28 +03:00 (Migrated from github.com)
Review

Is it possible to avoid the cast? For example specialize output for this workspace?

Is it possible to avoid the cast? For example specialize output for this workspace?
endpoint: Endpoint,
winter-yuki commented 2022-05-01 10:24:32 +03:00 (Migrated from github.com)
Review

Use ConnectionPool

Use `ConnectionPool`
altavir commented 2022-05-04 18:23:28 +03:00 (Migrated from github.com)
Review

Is it possible to avoid the cast? For example specialize output for this workspace?

Is it possible to avoid the cast? For example specialize output for this workspace?
override val resultType: KType,
winter-yuki commented 2022-05-01 10:24:32 +03:00 (Migrated from github.com)
Review

Use ConnectionPool

Use `ConnectionPool`
altavir commented 2022-05-04 18:23:28 +03:00 (Migrated from github.com)
Review

Is it possible to avoid the cast? For example specialize output for this workspace?

Is it possible to avoid the cast? For example specialize output for this workspace?
override val descriptor: MetaDescriptor? = null,
winter-yuki commented 2022-05-01 10:24:32 +03:00 (Migrated from github.com)
Review

Use ConnectionPool

Use `ConnectionPool`
altavir commented 2022-05-04 18:23:28 +03:00 (Migrated from github.com)
Review

Is it possible to avoid the cast? For example specialize output for this workspace?

Is it possible to avoid the cast? For example specialize output for this workspace?
) : Task<T> {
winter-yuki commented 2022-05-01 10:24:32 +03:00 (Migrated from github.com)
Review

Use ConnectionPool

Use `ConnectionPool`
altavir commented 2022-05-04 18:23:28 +03:00 (Migrated from github.com)
Review

Is it possible to avoid the cast? For example specialize output for this workspace?

Is it possible to avoid the cast? For example specialize output for this workspace?
private val dispatcher = ServiceDispatcher(ServiceWorkspace.serviceId to endpoint)
winter-yuki commented 2022-05-01 10:24:32 +03:00 (Migrated from github.com)
Review

Use ConnectionPool

Use `ConnectionPool`
altavir commented 2022-05-04 18:23:28 +03:00 (Migrated from github.com)
Review

Is it possible to avoid the cast? For example specialize output for this workspace?

Is it possible to avoid the cast? For example specialize output for this workspace?
winter-yuki commented 2022-05-01 10:24:32 +03:00 (Migrated from github.com)
Review

Use ConnectionPool

Use `ConnectionPool`
altavir commented 2022-05-04 18:23:28 +03:00 (Migrated from github.com)
Review

Is it possible to avoid the cast? For example specialize output for this workspace?

Is it possible to avoid the cast? For example specialize output for this workspace?
@Suppress("UNCHECKED_CAST")
winter-yuki commented 2022-05-01 10:24:32 +03:00 (Migrated from github.com)
Review

Use ConnectionPool

Use `ConnectionPool`
altavir commented 2022-05-04 18:23:28 +03:00 (Migrated from github.com)
Review

Is it possible to avoid the cast? For example specialize output for this workspace?

Is it possible to avoid the cast? For example specialize output for this workspace?
override suspend fun execute(
winter-yuki commented 2022-05-01 10:24:32 +03:00 (Migrated from github.com)
Review

Use ConnectionPool

Use `ConnectionPool`
altavir commented 2022-05-04 18:23:28 +03:00 (Migrated from github.com)
Review

Is it possible to avoid the cast? For example specialize output for this workspace?

Is it possible to avoid the cast? For example specialize output for this workspace?
workspace: Workspace,
winter-yuki commented 2022-05-01 10:24:32 +03:00 (Migrated from github.com)
Review

Use ConnectionPool

Use `ConnectionPool`
altavir commented 2022-05-04 18:23:28 +03:00 (Migrated from github.com)
Review

Is it possible to avoid the cast? For example specialize output for this workspace?

Is it possible to avoid the cast? For example specialize output for this workspace?
taskName: Name,
winter-yuki commented 2022-05-01 10:24:32 +03:00 (Migrated from github.com)
Review

Use ConnectionPool

Use `ConnectionPool`
altavir commented 2022-05-04 18:23:28 +03:00 (Migrated from github.com)
Review

Is it possible to avoid the cast? For example specialize output for this workspace?

Is it possible to avoid the cast? For example specialize output for this workspace?
taskMeta: Meta,
winter-yuki commented 2022-05-01 10:24:32 +03:00 (Migrated from github.com)
Review

Use ConnectionPool

Use `ConnectionPool`
altavir commented 2022-05-04 18:23:28 +03:00 (Migrated from github.com)
Review

Is it possible to avoid the cast? For example specialize output for this workspace?

Is it possible to avoid the cast? For example specialize output for this workspace?
): TaskResult<T> = withContext(dispatcher) {
winter-yuki commented 2022-05-01 10:24:32 +03:00 (Migrated from github.com)
Review

Use ConnectionPool

Use `ConnectionPool`
altavir commented 2022-05-04 18:23:28 +03:00 (Migrated from github.com)
Review

Is it possible to avoid the cast? For example specialize output for this workspace?

Is it possible to avoid the cast? For example specialize output for this workspace?
val dataset = ServiceWorkspace.execute(taskName) as LazyDecodableDataSet
winter-yuki commented 2022-05-01 10:24:32 +03:00 (Migrated from github.com)
Review

Use ConnectionPool

Use `ConnectionPool`
altavir commented 2022-05-04 18:23:28 +03:00 (Migrated from github.com)
Review

Is it possible to avoid the cast? For example specialize output for this workspace?

Is it possible to avoid the cast? For example specialize output for this workspace?
dataset.finishDecoding(resultType)
winter-yuki commented 2022-05-01 10:24:32 +03:00 (Migrated from github.com)
Review

Use ConnectionPool

Use `ConnectionPool`
altavir commented 2022-05-04 18:23:28 +03:00 (Migrated from github.com)
Review

Is it possible to avoid the cast? For example specialize output for this workspace?

Is it possible to avoid the cast? For example specialize output for this workspace?
workspace.wrapResult(dataset as DataSet<T>, taskName, taskMeta)
winter-yuki commented 2022-05-01 10:24:32 +03:00 (Migrated from github.com)
Review

Use ConnectionPool

Use `ConnectionPool`
altavir commented 2022-05-04 18:23:28 +03:00 (Migrated from github.com)
Review

Is it possible to avoid the cast? For example specialize output for this workspace?

Is it possible to avoid the cast? For example specialize output for this workspace?
}
winter-yuki commented 2022-05-01 10:24:32 +03:00 (Migrated from github.com)
Review

Use ConnectionPool

Use `ConnectionPool`
altavir commented 2022-05-04 18:23:28 +03:00 (Migrated from github.com)
Review

Is it possible to avoid the cast? For example specialize output for this workspace?

Is it possible to avoid the cast? For example specialize output for this workspace?
}
winter-yuki commented 2022-05-01 10:24:32 +03:00 (Migrated from github.com)
Review

Use ConnectionPool

Use `ConnectionPool`
altavir commented 2022-05-04 18:23:28 +03:00 (Migrated from github.com)
Review

Is it possible to avoid the cast? For example specialize output for this workspace?

Is it possible to avoid the cast? For example specialize output for this workspace?

View File

@ -0,0 +1,202 @@
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
package space.kscience.dataforge.workspace.distributed
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
import io.ktor.utils.io.core.*
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
import io.lambdarpc.coding.Coder
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
import io.lambdarpc.coding.CodingContext
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
import io.lambdarpc.dsl.LibService
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
import io.lambdarpc.dsl.def
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
import io.lambdarpc.transport.grpc.Entity
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
import io.lambdarpc.transport.serialization.Entity
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
import io.lambdarpc.transport.serialization.RawData
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
import io.lambdarpc.utils.Address
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
import io.lambdarpc.utils.Port
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
import io.lambdarpc.utils.toSid
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
import kotlinx.coroutines.CompletableDeferred
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
import kotlinx.coroutines.CoroutineScope
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
import kotlinx.coroutines.Deferred
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
import kotlinx.coroutines.flow.Flow
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
import kotlinx.coroutines.flow.asFlow
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
import kotlinx.coroutines.flow.map
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
import kotlinx.coroutines.flow.toList
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
import kotlinx.coroutines.runBlocking
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
import kotlinx.serialization.Serializable
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
import kotlinx.serialization.json.Json
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
import kotlinx.serialization.serializer
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
import space.kscience.dataforge.context.Context
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
import space.kscience.dataforge.context.Global
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
import space.kscience.dataforge.context.gather
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
import space.kscience.dataforge.data.Data
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
import space.kscience.dataforge.data.DataSet
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
import space.kscience.dataforge.data.DataTree
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
import space.kscience.dataforge.data.Goal
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
import space.kscience.dataforge.data.NamedData
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
import space.kscience.dataforge.data.await
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
import space.kscience.dataforge.data.component1
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
import space.kscience.dataforge.data.component2
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
import space.kscience.dataforge.meta.Meta
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
import space.kscience.dataforge.names.Name
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
import space.kscience.dataforge.names.asName
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
import space.kscience.dataforge.workspace.Task
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
import space.kscience.dataforge.workspace.TaskResult
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
import space.kscience.dataforge.workspace.Workspace
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
import space.kscience.dataforge.workspace.wrapResult
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
import java.nio.charset.Charset
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
import kotlin.reflect.KType
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
/**
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
* Workspace that exposes its tasks for remote clients.
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
*/
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
public class ServiceWorkspace(
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
address: String = "localhost",
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
port: Int? = null,
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
override val context: Context = Global.buildContext("workspace".asName()),
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
data: DataSet<*> = runBlocking { DataTree<Any> {} },
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
override val targets: Map<String, Meta> = mapOf(),
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
) : Workspace, Closeable {
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
override val data: TaskResult<*> = wrapResult(data, Name.EMPTY, Meta.EMPTY)
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
override val tasks: Map<Name, Task<*>>
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
get() = context.gather(Task.TYPE)
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
private val service = LibService(serviceId, address, port) {
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
execute of { name -> println("service = $name"); produce(name, Meta.EMPTY) } // TODO
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
}
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
/**
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
* Address this workspace is available on.
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
*/
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
public val address: Address = Address(address)
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
/**
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
* Port this workspace is available on.
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
*/
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
public val port: Port
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
get() = service.port
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
/**
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
* Start [ServiceWorkspace] as a service.
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
*/
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
public fun start(): Unit = service.start()
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
/**
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
* Await termination of the service.
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
*/
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
public fun awaitTermination(): Unit = service.awaitTermination()
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
/**
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
* Shutdown service.
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
*/
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
public fun shutdown(): Unit = service.shutdown()
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
override fun close(): Unit = service.shutdown()
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
public companion object {
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
internal val serviceId = "d41b95b1-828b-4444-8ff0-6f9c92a79246".toSid()
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
internal val execute by serviceId.def(NameCoder, DataSetCoder)
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
}
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
}
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
private object NameCoder : Coder<Name> {
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
override fun decode(entity: Entity, context: CodingContext): Name {
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
require(entity.hasData()) { "Entity should contain data" }
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
val string = entity.data.toString(Charset.defaultCharset())
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
return Name.parse(string)
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
}
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
override fun encode(value: Name, context: CodingContext): Entity =
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
Entity(RawData.copyFrom(value.toString(), Charset.defaultCharset()))
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
}
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
/**
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
* Data class that represents serializable [DataSet].
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
*/
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
@Serializable
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
private data class DataSetPrototype(
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
val data: Map<String, String>,
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
)
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
/**
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
* [DataSetPrototype] builder.
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
*/
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
private fun <T : Any> DataSet<T>.toPrototype(): DataSetPrototype = runBlocking {
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
val serializer = serializer(dataType)
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
val map = mutableListOf<Pair<String, String>>()
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
flowData().map { (name, data) ->
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
name.toString() to Json.encodeToString(serializer, data.await())
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
}.toList(map)
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
DataSetPrototype(map.associate { it })
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
}
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
/**
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
* Trivial [Data] implementation.
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
*/
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
private class SimpleData(override val type: KType, val data: Any) : Data<Any> {
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
override val meta: Meta
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
get() = Meta.EMPTY
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
override val dependencies: Collection<Goal<*>>
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
get() = emptyList()
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
override val deferred: Deferred<Any>
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
get() = CompletableDeferred(data)
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
override fun async(coroutineScope: CoroutineScope): Deferred<Any> = deferred
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
override fun reset() = Unit
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
}
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
/**
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
* Trivial named data implementation.
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
*/
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
private class SimpleNamedData(
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
override val name: Name,
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
override val data: Data<Any>,
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
) : NamedData<Any>, Data<Any> by data
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
/**
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
* Represents [DataSet] that should be initialized before usage.
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
*/
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
internal interface LazyDecodableDataSet<T : Any> : DataSet<T> {
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
fun finishDecoding(type: KType)
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
}
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
/**
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
* Trivial [LazyDecodableDataSet] implementation.
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
*/
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
private class SimpleDataSet(private val prototype: DataSetPrototype) : LazyDecodableDataSet<Any> {
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
lateinit var type: KType
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
lateinit var data: Map<Name, Any>
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
override fun finishDecoding(type: KType) {
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
this.type = type
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
this.data = prototype.data.map { (name, data) ->
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
Name.parse(name) to Json.decodeFromString(serializer(type), data)
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
}.associate { (name, data) -> name to data!! }
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
}
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
override val dataType: KType
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
get() = type
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
override fun flowData(): Flow<NamedData<Any>> =
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
data.map { (name, data) ->
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
val wrapped = SimpleData(dataType, data)
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
SimpleNamedData(name, wrapped)
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
}.asFlow()
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
override suspend fun getData(name: Name): Data<Any>? = data[name]?.let { data ->
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
SimpleData(dataType, data)
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
}
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
}
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
private object DataSetCoder : Coder<DataSet<Any>> {
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
override fun decode(entity: Entity, context: CodingContext): DataSet<Any> {
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
val string = entity.data.toString(Charset.defaultCharset())
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
val prototype = Json.decodeFromString(serializer<DataSetPrototype>(), string)
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
return SimpleDataSet(prototype)
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
}
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
override fun encode(value: DataSet<*>, context: CodingContext): Entity {
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
val prototype = value.toPrototype()
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
val string = Json.encodeToString(serializer(), prototype)
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
return Entity(RawData.copyFrom(string, Charset.defaultCharset()))
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
}
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason
}
winter-yuki commented 2022-05-01 10:23:36 +03:00 (Migrated from github.com)
Review

Remove debug print

Remove debug print
altavir commented 2022-05-04 20:33:41 +03:00 (Migrated from github.com)
Review

Better to pass Adress from outside instead of constructor initialization.

Better to pass Adress from outside instead of constructor initialization.
altavir commented 2022-05-04 20:34:03 +03:00 (Migrated from github.com)
Review

Why?

Why?
altavir commented 2022-05-04 20:34:30 +03:00 (Migrated from github.com)
Review

There is existing one

There is existing one
winter-yuki commented 2022-05-09 19:48:37 +03:00 (Migrated from github.com)
Review

I think that may be not a good idea to expose lambdarpc dependency

I think that may be not a good idea to expose lambdarpc dependency
winter-yuki commented 2022-05-09 19:48:53 +03:00 (Migrated from github.com)
Review

Just temporary hole

Just temporary hole
winter-yuki commented 2022-05-09 19:49:39 +03:00 (Migrated from github.com)
Review

Yes, but it is private for some reason

Yes, but it is private for some reason

View File

@ -0,0 +1,106 @@
package space.kscience.dataforge.workspace
import io.lambdarpc.utils.Endpoint
import kotlinx.coroutines.runBlocking
import org.junit.jupiter.api.AfterAll
import org.junit.jupiter.api.BeforeAll
import org.junit.jupiter.api.Test
import org.junit.jupiter.api.TestInstance
import space.kscience.dataforge.context.Context
import space.kscience.dataforge.context.Global
import space.kscience.dataforge.context.PluginFactory
import space.kscience.dataforge.context.PluginTag
import space.kscience.dataforge.data.DataTree
import space.kscience.dataforge.data.await
import space.kscience.dataforge.data.getData
import space.kscience.dataforge.data.map
import space.kscience.dataforge.data.select
import space.kscience.dataforge.data.static
import space.kscience.dataforge.meta.Meta
import space.kscience.dataforge.names.Name
import space.kscience.dataforge.names.asName
import space.kscience.dataforge.workspace.distributed.ClientWorkspacePlugin
import space.kscience.dataforge.workspace.distributed.ServiceWorkspace
import kotlin.reflect.KClass
import kotlin.reflect.typeOf
import kotlin.test.assertEquals
private class MyPlugin : WorkspacePlugin() {
override val tag: PluginTag
get() = Factory.tag
val task by task<Int> {
val myInt = workspace.data.select<Int>()
val res = myInt.getData("int".asName())!!
emit("result".asName(), res.map { it + 1 })
}
companion object Factory : PluginFactory<MyPlugin> {
override fun invoke(meta: Meta, context: Context): MyPlugin = MyPlugin()
override val tag: PluginTag
get() = PluginTag("Plg")
override val type: KClass<out MyPlugin>
get() = MyPlugin::class
}
}
private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin(
MyPlugin.tag,
endpoint,
"task".asName() to typeOf<Int>()
)
@TestInstance(TestInstance.Lifecycle.PER_CLASS)
class ServiceWorkspaceTest {
private lateinit var worker1: ServiceWorkspace
private lateinit var workspace: Workspace
@BeforeAll
fun before() {
worker1 = ServiceWorkspace(
context = Global.buildContext("worker1".asName()) {
plugin(MyPlugin)
},
data = runBlocking {
DataTree<Any> {
static("int", 0)
}
},
)
worker1.start()
workspace = Workspace {
context {
val endpoint = Endpoint(worker1.address, worker1.port)
plugin(RemoteMyPlugin(endpoint))
}
}
}
@AfterAll
fun after() {
worker1.shutdown()
}
@Test
fun localExecution() = runBlocking {
assertEquals(0, worker1.data.getData("int")!!.await())
val res = worker1
.produce(Name.of("Plg", "task"), Meta.EMPTY)
.getData("result".asName())!!
.await()
assertEquals(1, res)
}
@Test
fun remoteExecution() = runBlocking {
val remoteRes = workspace
.produce(Name.of("Plg", "task"), Meta.EMPTY)
.getData("result".asName())!!
.await()
assertEquals(1, remoteRes)
}
}