Call remote tasks of service workspace #75

Closed
winter-yuki wants to merge 25 commits from winter-yuki/distributed into 0.6
14 changed files with 365 additions and 301 deletions
Showing only changes of commit f62507e1b9 - Show all commits

View File

@ -0,0 +1,41 @@
plugins {
id("ru.mipt.npm.gradle.mpp")
}
kotlin {
sourceSets {
commonMain {
dependencies {
api(project(":dataforge-context"))
api(project(":dataforge-data"))
api(project(":dataforge-io"))
api(project(":dataforge-workspace"))
}
}
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")
}
}
}
}
kscience {
useSerialization {
json()
}
}
readme {
maturity = ru.mipt.npm.gradle.Maturity.PROTOTYPE
}

View File

@ -0,0 +1,37 @@
package space.kscience.dataforge.distributed
import io.lambdarpc.utils.Endpoint
import space.kscience.dataforge.context.AbstractPlugin
import space.kscience.dataforge.context.PluginTag
import space.kscience.dataforge.names.Name
import space.kscience.dataforge.workspace.Task
import kotlin.reflect.KType
/**
* Plugin that purpose is to communicate with remote plugins.
* @param endpoint Endpoint of the remote plugin.
*/
public abstract class ClientWorkspacePlugin(endpoint: Endpoint) : AbstractPlugin() {
/**
* Tag og the [ClientWorkspacePlugin] should be equal to the tag of the corresponding remote plugin.
*/
abstract override val tag: PluginTag
/**
* Enumeration of names of remote tasks and their result types.
*/
public abstract val tasks: Map<Name, KType>
private val _tasks: Map<Name, Task<*>> by lazy {
tasks.mapValues { (_, type) ->
RemoteTask<Any>(endpoint, type)
}
}
override fun content(target: String): Map<Name, Any> =
when (target) {
Task.TYPE -> _tasks
else -> emptyMap()
}
}

View File

@ -1,4 +1,4 @@
package space.kscience.dataforge.workspace.distributed
package space.kscience.dataforge.distributed
import io.lambdarpc.dsl.ServiceDispatcher
import io.lambdarpc.utils.Endpoint

View File

@ -0,0 +1,81 @@
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
package space.kscience.dataforge.distributed
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
import io.ktor.utils.io.core.*
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
import io.lambdarpc.dsl.LibService
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
import io.lambdarpc.dsl.def
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
import io.lambdarpc.utils.Address
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
import io.lambdarpc.utils.Port
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
import io.lambdarpc.utils.toSid
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
import kotlinx.coroutines.runBlocking
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
import space.kscience.dataforge.context.Context
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
import space.kscience.dataforge.context.Global
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
import space.kscience.dataforge.context.gather
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
import space.kscience.dataforge.data.DataSet
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
import space.kscience.dataforge.data.DataTree
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
import space.kscience.dataforge.distributed.serialization.DataSetCoder
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
altavir commented 2022-06-22 18:53:14 +03:00 (Migrated from github.com)
Review

I do not see, why we need it in the API on the server side the connection should be closeable, not the workspace. Maybe you should rename it to connection and remove inheritance from a workspace?

I do not see, why we need it in the API on the server side the connection should be closeable, not the workspace. Maybe you should rename it to connection and remove inheritance from a workspace?
import space.kscience.dataforge.distributed.serialization.NameCoder
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
import space.kscience.dataforge.distributed.serialization.SerializableDataSetAdapter
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
import space.kscience.dataforge.meta.Meta
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
import space.kscience.dataforge.names.Name
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
import space.kscience.dataforge.names.asName
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
import space.kscience.dataforge.workspace.Task
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
import space.kscience.dataforge.workspace.TaskResult
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
import space.kscience.dataforge.workspace.Workspace
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
import space.kscience.dataforge.workspace.wrapResult
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
/**
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
* Workspace that exposes its tasks for remote clients.
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
*/
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
public class ServiceWorkspace(
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
address: String = "localhost",
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
port: Int? = null,
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
override val context: Context = Global.buildContext("workspace".asName()),
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
data: DataSet<*> = runBlocking { DataTree<Any> {} },
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
override val targets: Map<String, Meta> = mapOf(),
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
) : Workspace, Closeable {
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
override val data: TaskResult<*> = wrapResult(data, Name.EMPTY, Meta.EMPTY)
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
override val tasks: Map<Name, Task<*>>
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
get() = context.gather(Task.TYPE)
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
private val service = LibService(serviceId, address, port) {
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
execute of { name ->
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
val res = produce(name, Meta.EMPTY)
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
SerializableDataSetAdapter(res)
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
}
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
}
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
/**
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
* Address this workspace is available on.
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
*/
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
public val address: Address = Address(address)
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
/**
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
* Port this workspace is available on.
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
*/
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
public val port: Port
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
get() = service.port
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
/**
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
* Start [ServiceWorkspace] as a service.
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
*/
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
public fun start(): Unit = service.start()
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
/**
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
* Await termination of the service.
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
*/
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
public fun awaitTermination(): Unit = service.awaitTermination()
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
/**
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
* Shutdown service.
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
*/
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
public fun shutdown(): Unit = service.shutdown()
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
override fun close(): Unit = service.shutdown()
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
public companion object {
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
internal val serviceId = "d41b95b1-828b-4444-8ff0-6f9c92a79246".toSid()
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
internal val execute by serviceId.def(NameCoder, DataSetCoder)
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
}
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.
}
altavir commented 2022-05-24 12:28:34 +03:00 (Migrated from github.com)
Review

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.

DataTree builder will be non-suspending in the next version, but it should be possible to create it without suspending now.
altavir commented 2022-05-24 12:29:17 +03:00 (Migrated from github.com)
Review

Need to think about better naming

Need to think about better naming
altavir commented 2022-05-24 12:29:54 +03:00 (Migrated from github.com)
Review

Why not suspended?

Why not suspended?
winter-yuki commented 2022-05-25 18:01:55 +03:00 (Migrated from github.com)
Review

I thought about WorkspaceNode or WorkerWorkspace. There is also DistributedWorkspace but it is not truly distributed itself.
Also ServiceWorkpace is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.

I thought about `WorkspaceNode` or `WorkerWorkspace`. There is also `DistributedWorkspace` but it is not truly distributed itself. Also `ServiceWorkpace` is good enought to my opinion. "Service" here means that this workspace should be run on some endpoint to be available.
winter-yuki commented 2022-05-25 18:04:12 +03:00 (Migrated from github.com)
Review

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

Because it is blocking in the google gRPC implementation. It can be made suspend and block separate thread but I do not see any reasons to do so.

View File

@ -0,0 +1,22 @@
package space.kscience.dataforge.distributed.serialization
import io.lambdarpc.coding.Coder
import io.lambdarpc.coding.CodingContext
import io.lambdarpc.transport.grpc.Entity
import io.lambdarpc.transport.serialization.Entity
import io.lambdarpc.transport.serialization.RawData
import java.nio.charset.Charset
internal object DataSetCoder : Coder<SerializableDataSet<Any>> {
override fun decode(entity: Entity, context: CodingContext): SerializableDataSet<Any> {
val string = entity.data.toString(Charset.defaultCharset())
val prototype = DataSetPrototype.fromJson(string)
return prototype.toDataSet()
}
override fun encode(value: SerializableDataSet<Any>, context: CodingContext): Entity {
val prototype = DataSetPrototype.of(value)
val string = prototype.toJson()
return Entity(RawData.copyFrom(string, Charset.defaultCharset()))
}
}

View File

@ -0,0 +1,20 @@
package space.kscience.dataforge.distributed.serialization
import io.lambdarpc.coding.Coder
import io.lambdarpc.coding.CodingContext
import io.lambdarpc.transport.grpc.Entity
import io.lambdarpc.transport.serialization.Entity
import io.lambdarpc.transport.serialization.RawData
import space.kscience.dataforge.names.Name
import java.nio.charset.Charset
internal object NameCoder : Coder<Name> {
override fun decode(entity: Entity, context: CodingContext): Name {
require(entity.hasData()) { "Entity should contain data" }
val string = entity.data.toString(Charset.defaultCharset())
return Name.parse(string)
}
override fun encode(value: Name, context: CodingContext): Entity =
Entity(RawData.copyFrom(value.toString(), Charset.defaultCharset()))
}

View File

@ -0,0 +1,16 @@
package space.kscience.dataforge.distributed.serialization
import space.kscience.dataforge.data.DataSet
import kotlin.reflect.KType
/**
* Represents [DataSet] that should be initialized before usage.
*/
internal interface SerializableDataSet<T : Any> : DataSet<T> {
fun finishDecoding(type: KType)
}
internal class SerializableDataSetAdapter<T : Any>(dataSet: DataSet<T>) :
SerializableDataSet<T>, DataSet<T> by dataSet {
override fun finishDecoding(type: KType) = Unit
}

View File

@ -0,0 +1,56 @@
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
package space.kscience.dataforge.distributed.serialization
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
import kotlinx.coroutines.CompletableDeferred
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
import kotlinx.coroutines.CoroutineScope
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
import kotlinx.coroutines.Deferred
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
import kotlinx.serialization.KSerializer
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
import kotlinx.serialization.Serializable
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
import kotlinx.serialization.json.Json
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
import space.kscience.dataforge.data.Data
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
import space.kscience.dataforge.data.Goal
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
import space.kscience.dataforge.data.await
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
import space.kscience.dataforge.meta.Meta
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
import space.kscience.dataforge.meta.MetaSerializer
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
import kotlin.reflect.KType
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
/**
altavir commented 2022-05-24 12:39:56 +03:00 (Migrated from github.com)
Review

This is unusable. I believe that it should be something like this:

class SerializeableData<T>(val data: Data<T>, val serializer: KSerializer<T>): Data<T> by data
This is unusable. I believe that it should be something like this: ```kotlin class SerializeableData<T>(val data: Data<T>, val serializer: KSerializer<T>): Data<T> by data ```
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
altavir commented 2022-06-22 18:53:56 +03:00 (Migrated from github.com)
Review

Is it used somewhere?

Is it used somewhere?
* [Data] representation that is trivially serializable.
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
*/
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
@Serializable
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
internal data class DataPrototype(
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
val meta: String,
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
val data: String,
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
) {
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
fun toData(type: KType): Data<Any> =
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
SimpleData(
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
type = type,
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
meta = Json.decodeFromString(MetaSerializer, meta),
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
data = Json.decodeFromString(kotlinx.serialization.serializer(type), data)!!
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
)
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
companion object {
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
suspend fun <T : Any> of(data: Data<T>, serializer: KSerializer<in T>): DataPrototype {
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
val meta = Json.encodeToString(MetaSerializer, data.meta)
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
val string = Json.encodeToString(serializer, data.await())
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
return DataPrototype(meta, string)
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
}
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
}
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
}
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
/**
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
* Trivial [Data] implementation.
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
*/
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
private class SimpleData<T : Any>(
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
override val type: KType,
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
override val meta: Meta,
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
val data: T,
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
) : Data<T> {
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
override val dependencies: Collection<Goal<*>>
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
get() = emptyList()
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
override val deferred: Deferred<T>
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
get() = CompletableDeferred(data)
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
override fun async(coroutineScope: CoroutineScope): Deferred<T> = deferred
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
override fun reset() = Unit
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that
}
altavir commented 2022-05-24 12:40:16 +03:00 (Migrated from github.com)
Review

There is existing class for that

There is existing class for that

View File

@ -0,0 +1,73 @@
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
package space.kscience.dataforge.distributed.serialization
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
import kotlinx.coroutines.flow.Flow
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
import kotlinx.coroutines.flow.asFlow
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
import kotlinx.coroutines.flow.map
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
import kotlinx.coroutines.flow.toList
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
import kotlinx.coroutines.runBlocking
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
import kotlinx.serialization.Serializable
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
import kotlinx.serialization.json.Json
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
import kotlinx.serialization.serializer
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
import space.kscience.dataforge.data.Data
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
import space.kscience.dataforge.data.DataSet
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
import space.kscience.dataforge.data.NamedData
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
import space.kscience.dataforge.data.component1
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
import space.kscience.dataforge.data.component2
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
import space.kscience.dataforge.names.Name
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
import kotlin.reflect.KType
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
/**
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
* [DataSet] representation that is trivially serializable.
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
*/
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
@Serializable
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
altavir commented 2022-06-22 18:55:42 +03:00 (Migrated from github.com)
Review

Do we need that?

Do we need that?
internal data class DataSetPrototype(val data: Map<String, DataPrototype>) {
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
fun toDataSet(): SerializableDataSet<Any> =
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
SerializableDataSetImpl(this)
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
fun toJson(): String = Json.encodeToString(serializer(), this)
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
companion object {
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
fun <T : Any> of(dataSet: DataSet<T>): DataSetPrototype = runBlocking {
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
val serializer = serializer(dataSet.dataType)
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
val map = mutableListOf<Pair<String, DataPrototype>>()
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
dataSet.flowData().map { (name, data) ->
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
name.toString() to DataPrototype.of(data, serializer)
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
}.toList(map)
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
DataSetPrototype(map.associate { it })
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
}
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
fun fromJson(string: String): DataSetPrototype = Json.decodeFromString(serializer(), string)
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
}
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
}
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
/**
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
* Trivial [SerializableDataSet] implementation.
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
*/
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
private class SerializableDataSetImpl(private val prototype: DataSetPrototype) : SerializableDataSet<Any> {
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
private lateinit var type: KType
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
private lateinit var data: Map<Name, Data<Any>>
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
override fun finishDecoding(type: KType) {
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
this.type = type
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
this.data = prototype.data
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
.mapKeys { (name, _) -> Name.of(name) }
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
.mapValues { (_, dataPrototype) -> dataPrototype.toData(type) }
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
}
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
override val dataType: KType
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
get() = type
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
override fun flowData(): Flow<NamedData<Any>> =
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
data.map { (name, data) -> SimpleNamedData(name, data) }.asFlow()
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
override suspend fun getData(name: Name): Data<Any>? = data[name]
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
/**
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
* Trivial named data implementation.
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
*/
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
private class SimpleNamedData(
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
override val name: Name,
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
override val data: Data<Any>,
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
) : NamedData<Any>, Data<Any> by data
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.
}
altavir commented 2022-05-24 12:42:07 +03:00 (Migrated from github.com)
Review

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.

Again, you do not need a separate structure. All you need is a generic DataSet with serializer.
winter-yuki commented 2022-05-25 20:53:44 +03:00 (Migrated from github.com)
Review

When ServiceWorkspace.execute returns result to the client, it do not know yet about serializer for the T. Then RemoteTask uses serializer to deserialize DataSet from prototype.

When `ServiceWorkspace.execute` returns result to the client, it do not know yet about serializer for the `T`. Then `RemoteTask` uses serializer to deserialize DataSet from prototype.

View File

@ -1,4 +1,4 @@
package space.kscience.dataforge.workspace
package space.kscience.dataforge.distributed
import io.lambdarpc.utils.Endpoint
import kotlinx.coroutines.runBlocking
@ -19,9 +19,11 @@ 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 space.kscience.dataforge.workspace.Workspace
import space.kscience.dataforge.workspace.WorkspacePlugin
import space.kscience.dataforge.workspace.task
import kotlin.reflect.KClass
import kotlin.reflect.KType
import kotlin.reflect.typeOf
import kotlin.test.assertEquals
@ -46,11 +48,15 @@ private class MyPlugin : WorkspacePlugin() {
}
}
private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin(
MyPlugin.tag,
endpoint,
"task".asName() to typeOf<Int>()
)
private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin(endpoint) {
override val tag: PluginTag
get() = MyPlugin.tag
override val tasks: Map<Name, KType>
get() = mapOf(
"task".asName() to typeOf<Int>()
)
}
@TestInstance(TestInstance.Lifecycle.PER_CLASS)
class ServiceWorkspaceTest {

View File

@ -12,30 +12,9 @@ kotlin {
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")
}
}
}
}
kscience {
useSerialization {
json()
}
}
readme {
maturity = ru.mipt.npm.gradle.Maturity.EXPERIMENTAL
}
}

View File

@ -1,31 +0,0 @@
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

@ -1,237 +0,0 @@
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.KSerializer
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.meta.MetaSerializer
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 ->
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 res = produce(name, 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
LazyDecodableDataSetAdapter(res)
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
/**
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
@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 DataPrototype(
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 meta: 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
val data: 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
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
suspend fun <T : Any> of(data: Data<T>, serializer: KSerializer<in T>): DataPrototype {
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 meta = Json.encodeToString(MetaSerializer, data.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
val string = 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
return DataPrototype(meta, 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
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, DataPrototype>,
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, DataPrototype>>()
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 DataPrototype.of(data, 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
}.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(
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 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
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
val 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
) : 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 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
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
private class LazyDecodableDataSetAdapter<T : Any>(val dataSet: 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
LazyDecodableDataSet<T>, DataSet<T> by 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
override fun finishDecoding(type: KType) = 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 [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, Pair<Meta, 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
val serializer = serializer(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
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
.mapKeys { (name, _) -> Name.of(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
.mapValues { (_, pair) ->
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 (meta, data) = pair
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
Pair(
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
Json.decodeFromString(MetaSerializer, 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
Json.decodeFromString(serializer, 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
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, pair) ->
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 (meta, data) = pair
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, meta, 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 { (meta, 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, meta, 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<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
override fun decode(entity: Entity, context: CodingContext): 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
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: LazyDecodableDataSet<Any>, 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

@ -22,5 +22,6 @@ include(
":dataforge-context",
":dataforge-data",
":dataforge-workspace",
":dataforge-scripting"
)
":dataforge-scripting",
":dataforge-distributed",
)