Call remote tasks of service workspace #75
@ -29,4 +29,7 @@ public fun <T : Any> Data<T>.named(name: Name): NamedData<T> = if (this is Named
|
||||
NamedDataImpl(name, this.data)
|
||||
} else {
|
||||
NamedDataImpl(name, this)
|
||||
}
|
||||
}
|
||||
|
||||
public operator fun <T : Any> NamedData<T>.component1(): Name = name
|
||||
public operator fun <T : Any> NamedData<T>.component2(): Data<T> = data
|
||||
|
@ -5,16 +5,37 @@ plugins {
|
||||
|
||||
kotlin {
|
||||
sourceSets {
|
||||
commonMain{
|
||||
commonMain {
|
||||
dependencies {
|
||||
api(project(":dataforge-context"))
|
||||
api(project(":dataforge-data"))
|
||||
api(project(":dataforge-io"))
|
||||
}
|
||||
}
|
||||
jvmMain {
|
||||
dependencies {
|
||||
// TODO include fat jar of lambdarpc
|
||||
api(files("lambdarpc-core-0.0.1.jar"))
|
||||
runtimeOnly("io.grpc:grpc-netty-shaded:1.44.0")
|
||||
api("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.6.0")
|
||||
api("io.grpc:grpc-protobuf:1.44.0")
|
||||
api("com.google.protobuf:protobuf-java-util:3.19.4")
|
||||
api("com.google.protobuf:protobuf-kotlin:3.19.4")
|
||||
api("io.grpc:grpc-kotlin-stub:1.2.1")
|
||||
api("org.jetbrains.kotlinx:kotlinx-serialization-json:1.3.2")
|
||||
api("org.slf4j:slf4j-simple:1.7.36")
|
||||
api("io.github.microutils:kotlin-logging-jvm:2.1.21")
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
readme{
|
||||
kscience {
|
||||
useSerialization {
|
||||
json()
|
||||
}
|
||||
}
|
||||
|
||||
readme {
|
||||
maturity = ru.mipt.npm.gradle.Maturity.EXPERIMENTAL
|
||||
}
|
@ -17,6 +17,11 @@ import kotlin.reflect.typeOf
|
||||
@Type(TYPE)
|
||||
public interface Task<out T : Any> : Described {
|
||||
|
||||
/**
|
||||
* Type of the task result data.
|
||||
*/
|
||||
public val resultType: KType
|
||||
|
||||
/**
|
||||
* Compute a [TaskResult] using given meta. In general, the result is lazy and represents both computation model
|
||||
* and a handler for actual result
|
||||
@ -55,6 +60,9 @@ public fun <T : Any> Task(
|
||||
builder: suspend TaskResultBuilder<T>.() -> Unit,
|
||||
): Task<T> = object : Task<T> {
|
||||
|
||||
override val resultType: KType
|
||||
get() = resultType
|
||||
|
||||
override val descriptor: MetaDescriptor? = descriptor
|
||||
|
||||
override suspend fun execute(
|
||||
|
@ -0,0 +1,31 @@
|
||||
|
||||
package space.kscience.dataforge.workspace.distributed
|
||||
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.
There is already WorkspacePlugin that does similar thing. There is already WorkspacePlugin that does similar thing.
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:
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>()
)
```
`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.
|
||||
|
||||
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.
There is already WorkspacePlugin that does similar thing. There is already WorkspacePlugin that does similar thing.
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:
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>()
)
```
`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
|
||||
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.
There is already WorkspacePlugin that does similar thing. There is already WorkspacePlugin that does similar thing.
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:
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>()
)
```
`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
|
||||
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.
There is already WorkspacePlugin that does similar thing. There is already WorkspacePlugin that does similar thing.
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:
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>()
)
```
`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
|
||||
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.
There is already WorkspacePlugin that does similar thing. There is already WorkspacePlugin that does similar thing.
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:
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>()
)
```
`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
|
||||
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.
There is already WorkspacePlugin that does similar thing. There is already WorkspacePlugin that does similar thing.
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:
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>()
)
```
`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
|
||||
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.
There is already WorkspacePlugin that does similar thing. There is already WorkspacePlugin that does similar thing.
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:
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>()
)
```
`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
|
||||
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.
There is already WorkspacePlugin that does similar thing. There is already WorkspacePlugin that does similar thing.
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:
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>()
)
```
`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.
|
||||
|
||||
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.
There is already WorkspacePlugin that does similar thing. There is already WorkspacePlugin that does similar thing.
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:
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>()
)
```
`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.
|
||||
/**
|
||||
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.
There is already WorkspacePlugin that does similar thing. There is already WorkspacePlugin that does similar thing.
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:
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>()
)
```
`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.
|
||||
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.
There is already WorkspacePlugin that does similar thing. There is already WorkspacePlugin that does similar thing.
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:
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>()
)
```
`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.
|
||||
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.
There is already WorkspacePlugin that does similar thing. There is already WorkspacePlugin that does similar thing.
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:
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>()
)
```
`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.
|
||||
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.
There is already WorkspacePlugin that does similar thing. There is already WorkspacePlugin that does similar thing.
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:
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>()
)
```
`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.
|
||||
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.
There is already WorkspacePlugin that does similar thing. There is already WorkspacePlugin that does similar thing.
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:
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>()
)
```
`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.
|
||||
*/
|
||||
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.
There is already WorkspacePlugin that does similar thing. There is already WorkspacePlugin that does similar thing.
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:
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>()
)
```
`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(
|
||||
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.
There is already WorkspacePlugin that does similar thing. There is already WorkspacePlugin that does similar thing.
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:
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>()
)
```
`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,
|
||||
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.
There is already WorkspacePlugin that does similar thing. There is already WorkspacePlugin that does similar thing.
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:
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>()
)
```
`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,
|
||||
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.
There is already WorkspacePlugin that does similar thing. There is already WorkspacePlugin that does similar thing.
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:
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>()
)
```
`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>,
|
||||
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.
There is already WorkspacePlugin that does similar thing. There is already WorkspacePlugin that does similar thing.
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:
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>()
)
```
`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() {
|
||||
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.
There is already WorkspacePlugin that does similar thing. There is already WorkspacePlugin that does similar thing.
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:
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>()
)
```
`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.
|
||||
|
||||
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.
There is already WorkspacePlugin that does similar thing. There is already WorkspacePlugin that does similar thing.
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:
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>()
)
```
`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) ->
|
||||
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.
There is already WorkspacePlugin that does similar thing. There is already WorkspacePlugin that does similar thing.
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:
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>()
)
```
`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)
|
||||
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.
There is already WorkspacePlugin that does similar thing. There is already WorkspacePlugin that does similar thing.
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:
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>()
)
```
`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.
|
||||
}
|
||||
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.
There is already WorkspacePlugin that does similar thing. There is already WorkspacePlugin that does similar thing.
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:
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>()
)
```
`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.
|
||||
|
||||
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.
There is already WorkspacePlugin that does similar thing. There is already WorkspacePlugin that does similar thing.
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:
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>()
)
```
`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> =
|
||||
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.
There is already WorkspacePlugin that does similar thing. There is already WorkspacePlugin that does similar thing.
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:
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>()
)
```
`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) {
|
||||
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.
There is already WorkspacePlugin that does similar thing. There is already WorkspacePlugin that does similar thing.
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:
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>()
)
```
`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
|
||||
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.
There is already WorkspacePlugin that does similar thing. There is already WorkspacePlugin that does similar thing.
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:
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>()
)
```
`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()
|
||||
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.
There is already WorkspacePlugin that does similar thing. There is already WorkspacePlugin that does similar thing.
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:
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>()
)
```
`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.
|
||||
}
|
||||
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.
There is already WorkspacePlugin that does similar thing. There is already WorkspacePlugin that does similar thing.
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:
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>()
)
```
`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.
|
||||
}
|
||||
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.
There is already WorkspacePlugin that does similar thing. There is already WorkspacePlugin that does similar thing.
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:
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>()
)
```
`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.
|
@ -0,0 +1,36 @@
|
||||
Use Use `ConnectionPool`
Use Use `ConnectionPool`
Is it possible to avoid the cast? For example specialize output for this workspace? Is it possible to avoid the cast? For example specialize output for this workspace?
Is it possible to avoid the cast? For example specialize output for this workspace? Is it possible to avoid the cast? For example specialize output for this workspace?
|
||||
package space.kscience.dataforge.workspace.distributed
|
||||
Use Use `ConnectionPool`
Is it possible to avoid the cast? For example specialize output for this workspace? Is it possible to avoid the cast? For example specialize output for this workspace?
|
||||
|
||||
Use Use `ConnectionPool`
Is it possible to avoid the cast? For example specialize output for this workspace? Is it possible to avoid the cast? For example specialize output for this workspace?
|
||||
import io.lambdarpc.dsl.ServiceDispatcher
|
||||
Use Use `ConnectionPool`
Is it possible to avoid the cast? For example specialize output for this workspace? Is it possible to avoid the cast? For example specialize output for this workspace?
|
||||
import io.lambdarpc.utils.Endpoint
|
||||
Use Use `ConnectionPool`
Is it possible to avoid the cast? For example specialize output for this workspace? Is it possible to avoid the cast? For example specialize output for this workspace?
|
||||
import kotlinx.coroutines.withContext
|
||||
Use Use `ConnectionPool`
Is it possible to avoid the cast? For example specialize output for this workspace? Is it possible to avoid the cast? For example specialize output for this workspace?
|
||||
import space.kscience.dataforge.data.DataSet
|
||||
Use Use `ConnectionPool`
Is it possible to avoid the cast? For example specialize output for this workspace? Is it possible to avoid the cast? For example specialize output for this workspace?
|
||||
import space.kscience.dataforge.meta.Meta
|
||||
Use Use `ConnectionPool`
Is it possible to avoid the cast? For example specialize output for this workspace? Is it possible to avoid the cast? For example specialize output for this workspace?
|
||||
import space.kscience.dataforge.meta.descriptors.MetaDescriptor
|
||||
Use Use `ConnectionPool`
Is it possible to avoid the cast? For example specialize output for this workspace? Is it possible to avoid the cast? For example specialize output for this workspace?
|
||||
import space.kscience.dataforge.names.Name
|
||||
Use Use `ConnectionPool`
Is it possible to avoid the cast? For example specialize output for this workspace? Is it possible to avoid the cast? For example specialize output for this workspace?
|
||||
import space.kscience.dataforge.workspace.Task
|
||||
Use Use `ConnectionPool`
Is it possible to avoid the cast? For example specialize output for this workspace? Is it possible to avoid the cast? For example specialize output for this workspace?
|
||||
import space.kscience.dataforge.workspace.TaskResult
|
||||
Use Use `ConnectionPool`
Is it possible to avoid the cast? For example specialize output for this workspace? Is it possible to avoid the cast? For example specialize output for this workspace?
|
||||
import space.kscience.dataforge.workspace.Workspace
|
||||
Use Use `ConnectionPool`
Is it possible to avoid the cast? For example specialize output for this workspace? Is it possible to avoid the cast? For example specialize output for this workspace?
|
||||
import space.kscience.dataforge.workspace.wrapResult
|
||||
Use Use `ConnectionPool`
Is it possible to avoid the cast? For example specialize output for this workspace? Is it possible to avoid the cast? For example specialize output for this workspace?
|
||||
import kotlin.reflect.KType
|
||||
Use Use `ConnectionPool`
Is it possible to avoid the cast? For example specialize output for this workspace? Is it possible to avoid the cast? For example specialize output for this workspace?
|
||||
|
||||
Use Use `ConnectionPool`
Is it possible to avoid the cast? For example specialize output for this workspace? Is it possible to avoid the cast? For example specialize output for this workspace?
|
||||
/**
|
||||
Use Use `ConnectionPool`
Is it possible to avoid the cast? For example specialize output for this workspace? Is it possible to avoid the cast? For example specialize output for this workspace?
|
||||
* Proxy task that communicates with the corresponding remote task.
|
||||
Use Use `ConnectionPool`
Is it possible to avoid the cast? For example specialize output for this workspace? Is it possible to avoid the cast? For example specialize output for this workspace?
|
||||
*/
|
||||
Use Use `ConnectionPool`
Is it possible to avoid the cast? For example specialize output for this workspace? Is it possible to avoid the cast? For example specialize output for this workspace?
|
||||
internal class RemoteTask<T : Any>(
|
||||
Use Use `ConnectionPool`
Is it possible to avoid the cast? For example specialize output for this workspace? Is it possible to avoid the cast? For example specialize output for this workspace?
|
||||
endpoint: Endpoint,
|
||||
Use Use `ConnectionPool`
Is it possible to avoid the cast? For example specialize output for this workspace? Is it possible to avoid the cast? For example specialize output for this workspace?
|
||||
override val resultType: KType,
|
||||
Use Use `ConnectionPool`
Is it possible to avoid the cast? For example specialize output for this workspace? Is it possible to avoid the cast? For example specialize output for this workspace?
|
||||
override val descriptor: MetaDescriptor? = null,
|
||||
Use Use `ConnectionPool`
Is it possible to avoid the cast? For example specialize output for this workspace? Is it possible to avoid the cast? For example specialize output for this workspace?
|
||||
) : Task<T> {
|
||||
Use Use `ConnectionPool`
Is it possible to avoid the cast? For example specialize output for this workspace? Is it possible to avoid the cast? For example specialize output for this workspace?
|
||||
private val dispatcher = ServiceDispatcher(ServiceWorkspace.serviceId to endpoint)
|
||||
Use Use `ConnectionPool`
Is it possible to avoid the cast? For example specialize output for this workspace? Is it possible to avoid the cast? For example specialize output for this workspace?
|
||||
|
||||
Use Use `ConnectionPool`
Is it possible to avoid the cast? For example specialize output for this workspace? Is it possible to avoid the cast? For example specialize output for this workspace?
|
||||
@Suppress("UNCHECKED_CAST")
|
||||
Use Use `ConnectionPool`
Is it possible to avoid the cast? For example specialize output for this workspace? Is it possible to avoid the cast? For example specialize output for this workspace?
|
||||
override suspend fun execute(
|
||||
Use Use `ConnectionPool`
Is it possible to avoid the cast? For example specialize output for this workspace? Is it possible to avoid the cast? For example specialize output for this workspace?
|
||||
workspace: Workspace,
|
||||
Use Use `ConnectionPool`
Is it possible to avoid the cast? For example specialize output for this workspace? Is it possible to avoid the cast? For example specialize output for this workspace?
|
||||
taskName: Name,
|
||||
Use Use `ConnectionPool`
Is it possible to avoid the cast? For example specialize output for this workspace? Is it possible to avoid the cast? For example specialize output for this workspace?
|
||||
taskMeta: Meta,
|
||||
Use Use `ConnectionPool`
Is it possible to avoid the cast? For example specialize output for this workspace? Is it possible to avoid the cast? For example specialize output for this workspace?
|
||||
): TaskResult<T> = withContext(dispatcher) {
|
||||
Use Use `ConnectionPool`
Is it possible to avoid the cast? For example specialize output for this workspace? Is it possible to avoid the cast? For example specialize output for this workspace?
|
||||
val dataset = ServiceWorkspace.execute(taskName) as LazyDecodableDataSet
|
||||
Use Use `ConnectionPool`
Is it possible to avoid the cast? For example specialize output for this workspace? Is it possible to avoid the cast? For example specialize output for this workspace?
|
||||
dataset.finishDecoding(resultType)
|
||||
Use Use `ConnectionPool`
Is it possible to avoid the cast? For example specialize output for this workspace? Is it possible to avoid the cast? For example specialize output for this workspace?
|
||||
workspace.wrapResult(dataset as DataSet<T>, taskName, taskMeta)
|
||||
Use Use `ConnectionPool`
Is it possible to avoid the cast? For example specialize output for this workspace? Is it possible to avoid the cast? For example specialize output for this workspace?
|
||||
}
|
||||
Use Use `ConnectionPool`
Is it possible to avoid the cast? For example specialize output for this workspace? Is it possible to avoid the cast? For example specialize output for this workspace?
|
||||
}
|
||||
Use Use `ConnectionPool`
Is it possible to avoid the cast? For example specialize output for this workspace? Is it possible to avoid the cast? For example specialize output for this workspace?
|
@ -0,0 +1,202 @@
|
||||
Remove debug print Remove debug print
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
Why? Why?
There is existing one There is existing one
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
package space.kscience.dataforge.workspace.distributed
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
import io.ktor.utils.io.core.*
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
import io.lambdarpc.coding.Coder
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
import io.lambdarpc.coding.CodingContext
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
import io.lambdarpc.dsl.LibService
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
import io.lambdarpc.dsl.def
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
import io.lambdarpc.transport.grpc.Entity
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
import io.lambdarpc.transport.serialization.Entity
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
import io.lambdarpc.transport.serialization.RawData
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
import io.lambdarpc.utils.Address
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
import io.lambdarpc.utils.Port
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
import io.lambdarpc.utils.toSid
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
import kotlinx.coroutines.CompletableDeferred
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
import kotlinx.coroutines.CoroutineScope
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
import kotlinx.coroutines.Deferred
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
import kotlinx.coroutines.flow.Flow
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
import kotlinx.coroutines.flow.asFlow
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
import kotlinx.coroutines.flow.map
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
import kotlinx.coroutines.flow.toList
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
import kotlinx.coroutines.runBlocking
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
import kotlinx.serialization.Serializable
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
import kotlinx.serialization.json.Json
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
import kotlinx.serialization.serializer
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
import space.kscience.dataforge.context.Context
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
import space.kscience.dataforge.context.Global
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
import space.kscience.dataforge.context.gather
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
import space.kscience.dataforge.data.Data
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
import space.kscience.dataforge.data.DataSet
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
import space.kscience.dataforge.data.DataTree
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
import space.kscience.dataforge.data.Goal
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
import space.kscience.dataforge.data.NamedData
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
import space.kscience.dataforge.data.await
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
import space.kscience.dataforge.data.component1
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
import space.kscience.dataforge.data.component2
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
import space.kscience.dataforge.meta.Meta
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
import space.kscience.dataforge.names.Name
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
import space.kscience.dataforge.names.asName
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
import space.kscience.dataforge.workspace.Task
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
import space.kscience.dataforge.workspace.TaskResult
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
import space.kscience.dataforge.workspace.Workspace
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
import space.kscience.dataforge.workspace.wrapResult
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
import java.nio.charset.Charset
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
import kotlin.reflect.KType
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
/**
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
* Workspace that exposes its tasks for remote clients.
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
*/
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
public class ServiceWorkspace(
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
address: String = "localhost",
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
port: Int? = null,
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
override val context: Context = Global.buildContext("workspace".asName()),
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
data: DataSet<*> = runBlocking { DataTree<Any> {} },
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
override val targets: Map<String, Meta> = mapOf(),
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
) : Workspace, Closeable {
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
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)
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
override val tasks: Map<Name, Task<*>>
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
get() = context.gather(Task.TYPE)
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
private val service = LibService(serviceId, address, port) {
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
execute of { name -> println("service = $name"); produce(name, Meta.EMPTY) } // TODO
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
}
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
/**
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
* Address this workspace is available on.
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
*/
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
public val address: Address = Address(address)
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
/**
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
* Port this workspace is available on.
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
*/
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
public val port: Port
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
get() = service.port
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
/**
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
* Start [ServiceWorkspace] as a service.
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
*/
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
public fun start(): Unit = service.start()
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
/**
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
* Await termination of the service.
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
*/
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
public fun awaitTermination(): Unit = service.awaitTermination()
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
/**
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
* Shutdown service.
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
*/
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
public fun shutdown(): Unit = service.shutdown()
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
override fun close(): Unit = service.shutdown()
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
public companion object {
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
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()
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
internal val execute by serviceId.def(NameCoder, DataSetCoder)
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
}
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
}
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
private object NameCoder : Coder<Name> {
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
override fun decode(entity: Entity, context: CodingContext): Name {
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
require(entity.hasData()) { "Entity should contain data" }
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
val string = entity.data.toString(Charset.defaultCharset())
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
return Name.parse(string)
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
}
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
override fun encode(value: Name, context: CodingContext): Entity =
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
Entity(RawData.copyFrom(value.toString(), Charset.defaultCharset()))
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
}
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
/**
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
* Data class that represents serializable [DataSet].
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
*/
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
@Serializable
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
private data class DataSetPrototype(
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
val data: Map<String, String>,
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
)
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
/**
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
* [DataSetPrototype] builder.
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
*/
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
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 {
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
val serializer = serializer(dataType)
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
val map = mutableListOf<Pair<String, String>>()
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
flowData().map { (name, data) ->
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
name.toString() to Json.encodeToString(serializer, data.await())
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
}.toList(map)
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
DataSetPrototype(map.associate { it })
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
}
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
/**
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
* Trivial [Data] implementation.
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
*/
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
private class SimpleData(override val type: KType, val data: Any) : Data<Any> {
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
override val meta: Meta
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
get() = Meta.EMPTY
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
override val dependencies: Collection<Goal<*>>
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
get() = emptyList()
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
override val deferred: Deferred<Any>
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
get() = CompletableDeferred(data)
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
override fun async(coroutineScope: CoroutineScope): Deferred<Any> = deferred
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
override fun reset() = Unit
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
}
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
/**
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
* Trivial named data implementation.
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
*/
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
private class SimpleNamedData(
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
override val name: Name,
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
override val data: Data<Any>,
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
) : NamedData<Any>, Data<Any> by data
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
/**
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
* Represents [DataSet] that should be initialized before usage.
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
*/
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
internal interface LazyDecodableDataSet<T : Any> : DataSet<T> {
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
fun finishDecoding(type: KType)
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
}
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
/**
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
* Trivial [LazyDecodableDataSet] implementation.
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
*/
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
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> {
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
lateinit var type: KType
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
lateinit var data: Map<Name, Any>
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
override fun finishDecoding(type: KType) {
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
this.type = type
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
this.data = prototype.data.map { (name, data) ->
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
Name.parse(name) to Json.decodeFromString(serializer(type), data)
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
}.associate { (name, data) -> name to data!! }
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
}
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
override val dataType: KType
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
get() = type
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
override fun flowData(): Flow<NamedData<Any>> =
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
data.map { (name, data) ->
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
val wrapped = SimpleData(dataType, data)
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
SimpleNamedData(name, wrapped)
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
}.asFlow()
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
override suspend fun getData(name: Name): Data<Any>? = data[name]?.let { data ->
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
SimpleData(dataType, data)
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
}
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
}
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
private object DataSetCoder : Coder<DataSet<Any>> {
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
override fun decode(entity: Entity, context: CodingContext): DataSet<Any> {
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
val string = entity.data.toString(Charset.defaultCharset())
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
val prototype = Json.decodeFromString(serializer<DataSetPrototype>(), string)
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
return SimpleDataSet(prototype)
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
}
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
override fun encode(value: DataSet<*>, context: CodingContext): Entity {
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
val prototype = value.toPrototype()
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
val string = Json.encodeToString(serializer(), prototype)
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
return Entity(RawData.copyFrom(string, Charset.defaultCharset()))
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
}
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
||||
}
|
||||
Remove debug print Remove debug print
Better to pass Adress from outside instead of constructor initialization. Better to pass Adress from outside instead of constructor initialization.
Why? Why?
There is existing one There is existing one
I think that may be not a good idea to expose lambdarpc dependency I think that may be not a good idea to expose lambdarpc dependency
Just temporary hole Just temporary hole
Yes, but it is private for some reason Yes, but it is private for some reason
|
@ -0,0 +1,106 @@
|
||||
package space.kscience.dataforge.workspace
|
||||
|
||||
import io.lambdarpc.utils.Endpoint
|
||||
import kotlinx.coroutines.runBlocking
|
||||
import org.junit.jupiter.api.AfterAll
|
||||
import org.junit.jupiter.api.BeforeAll
|
||||
import org.junit.jupiter.api.Test
|
||||
import org.junit.jupiter.api.TestInstance
|
||||
import space.kscience.dataforge.context.Context
|
||||
import space.kscience.dataforge.context.Global
|
||||
import space.kscience.dataforge.context.PluginFactory
|
||||
import space.kscience.dataforge.context.PluginTag
|
||||
import space.kscience.dataforge.data.DataTree
|
||||
import space.kscience.dataforge.data.await
|
||||
import space.kscience.dataforge.data.getData
|
||||
import space.kscience.dataforge.data.map
|
||||
import space.kscience.dataforge.data.select
|
||||
import space.kscience.dataforge.data.static
|
||||
import space.kscience.dataforge.meta.Meta
|
||||
import space.kscience.dataforge.names.Name
|
||||
import space.kscience.dataforge.names.asName
|
||||
import space.kscience.dataforge.workspace.distributed.ClientWorkspacePlugin
|
||||
import space.kscience.dataforge.workspace.distributed.ServiceWorkspace
|
||||
import kotlin.reflect.KClass
|
||||
import kotlin.reflect.typeOf
|
||||
import kotlin.test.assertEquals
|
||||
|
||||
private class MyPlugin : WorkspacePlugin() {
|
||||
override val tag: PluginTag
|
||||
get() = Factory.tag
|
||||
|
||||
val task by task<Int> {
|
||||
val myInt = workspace.data.select<Int>()
|
||||
val res = myInt.getData("int".asName())!!
|
||||
emit("result".asName(), res.map { it + 1 })
|
||||
}
|
||||
|
||||
companion object Factory : PluginFactory<MyPlugin> {
|
||||
override fun invoke(meta: Meta, context: Context): MyPlugin = MyPlugin()
|
||||
|
||||
override val tag: PluginTag
|
||||
get() = PluginTag("Plg")
|
||||
|
||||
override val type: KClass<out MyPlugin>
|
||||
get() = MyPlugin::class
|
||||
}
|
||||
}
|
||||
|
||||
private class RemoteMyPlugin(endpoint: Endpoint) : ClientWorkspacePlugin(
|
||||
MyPlugin.tag,
|
||||
endpoint,
|
||||
"task".asName() to typeOf<Int>()
|
||||
)
|
||||
|
||||
@TestInstance(TestInstance.Lifecycle.PER_CLASS)
|
||||
class ServiceWorkspaceTest {
|
||||
|
||||
private lateinit var worker1: ServiceWorkspace
|
||||
private lateinit var workspace: Workspace
|
||||
|
||||
@BeforeAll
|
||||
fun before() {
|
||||
worker1 = ServiceWorkspace(
|
||||
context = Global.buildContext("worker1".asName()) {
|
||||
plugin(MyPlugin)
|
||||
},
|
||||
data = runBlocking {
|
||||
DataTree<Any> {
|
||||
static("int", 0)
|
||||
}
|
||||
},
|
||||
)
|
||||
worker1.start()
|
||||
|
||||
workspace = Workspace {
|
||||
context {
|
||||
val endpoint = Endpoint(worker1.address, worker1.port)
|
||||
plugin(RemoteMyPlugin(endpoint))
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
@AfterAll
|
||||
fun after() {
|
||||
worker1.shutdown()
|
||||
}
|
||||
|
||||
@Test
|
||||
fun localExecution() = runBlocking {
|
||||
assertEquals(0, worker1.data.getData("int")!!.await())
|
||||
val res = worker1
|
||||
.produce(Name.of("Plg", "task"), Meta.EMPTY)
|
||||
.getData("result".asName())!!
|
||||
.await()
|
||||
assertEquals(1, res)
|
||||
}
|
||||
|
||||
@Test
|
||||
fun remoteExecution() = runBlocking {
|
||||
val remoteRes = workspace
|
||||
.produce(Name.of("Plg", "task"), Meta.EMPTY)
|
||||
.getData("result".asName())!!
|
||||
.await()
|
||||
assertEquals(1, remoteRes)
|
||||
}
|
||||
}
|
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.
There is already WorkspacePlugin that does similar thing.
There is already WorkspacePlugin that does similar thing.
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:
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:
WorkspacePlugin
is also aTaskContainer
, which I did not want to.ClientPlugin
is just a port to existing remote plugin and has no tasks locally.WorkspacePlugin
is also aTaskContainer
, which I did not want to.ClientPlugin
is just a port to existing remote plugin and has no tasks locally.