Call remote tasks of service workspace #75
@ -29,7 +29,7 @@ internal class RemoteTask<T : Any>(
|
||||
|
||||
taskName: Name,
|
||||
taskMeta: Meta,
|
||||
): TaskResult<T> = withContext(dispatcher) {
|
||||
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?
|
||||
val dataset = ServiceWorkspace.execute(taskName)
|
||||
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)
|
||||
workspace.wrapResult(dataset as DataSet<T>, taskName, taskMeta)
|
||||
}
|
||||
|
||||
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?
|
@ -19,6 +19,7 @@ import kotlinx.coroutines.flow.asFlow
|
||||
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
|
||||
import kotlinx.coroutines.flow.map
|
||||
import kotlinx.coroutines.flow.toList
|
||||
import kotlinx.coroutines.runBlocking
|
||||
import kotlinx.serialization.KSerializer
|
||||
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
|
||||
import kotlinx.serialization.json.Json
|
||||
import kotlinx.serialization.serializer
|
||||
@ -34,6 +35,7 @@ import space.kscience.dataforge.data.await
|
||||
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
|
||||
import space.kscience.dataforge.data.component1
|
||||
import space.kscience.dataforge.data.component2
|
||||
import space.kscience.dataforge.meta.Meta
|
||||
import space.kscience.dataforge.meta.MetaSerializer
|
||||
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
|
||||
import space.kscience.dataforge.names.asName
|
||||
import space.kscience.dataforge.workspace.Task
|
||||
@ -60,7 +62,10 @@ public class ServiceWorkspace(
|
||||
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
|
||||
get() = context.gather(Task.TYPE)
|
||||
|
||||
private val service = LibService(serviceId, address, port) {
|
||||
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
|
||||
execute of { 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
|
||||
val res = produce(name, 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
|
||||
LazyDecodableDataSetAdapter(res)
|
||||
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
|
||||
}
|
||||
|
||||
/**
|
||||
@ -108,12 +113,26 @@ private object NameCoder : Coder<Name> {
|
||||
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
|
||||
Entity(RawData.copyFrom(value.toString(), Charset.defaultCharset()))
|
||||
}
|
||||
|
||||
@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 DataPrototype(
|
||||
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 meta: 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
|
||||
val data: 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
|
||||
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
|
||||
suspend fun <T : Any> of(data: Data<T>, serializer: KSerializer<in T>): DataPrototype {
|
||||
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 meta = Json.encodeToString(MetaSerializer, data.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
|
||||
val string = 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
|
||||
return DataPrototype(meta, 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
|
||||
|
||||
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].
|
||||
*/
|
||||
@Serializable
|
||||
private data class DataSetPrototype(
|
||||
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
|
||||
val data: Map<String, DataPrototype>,
|
||||
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
|
||||
)
|
||||
|
||||
/**
|
||||
@ -121,9 +140,9 @@ private data class DataSetPrototype(
|
||||
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
|
||||
*/
|
||||
private fun <T : Any> DataSet<T>.toPrototype(): DataSetPrototype = runBlocking {
|
||||
val serializer = serializer(dataType)
|
||||
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
|
||||
val map = mutableListOf<Pair<String, DataPrototype>>()
|
||||
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) ->
|
||||
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
|
||||
name.toString() to DataPrototype.of(data, 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
|
||||
}.toList(map)
|
||||
DataSetPrototype(map.associate { it })
|
||||
}
|
||||
@ -131,11 +150,14 @@ private fun <T : Any> DataSet<T>.toPrototype(): DataSetPrototype = runBlocking {
|
||||
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
|
||||
/**
|
||||
* Trivial [Data] implementation.
|
||||
*/
|
||||
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
|
||||
private class SimpleData(
|
||||
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 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
|
||||
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
|
||||
val 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
|
||||
) : 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 dependencies: Collection<Goal<*>>
|
||||
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>
|
||||
get() = CompletableDeferred(data)
|
||||
|
||||
@ -158,43 +180,56 @@ internal interface LazyDecodableDataSet<T : Any> : DataSet<T> {
|
||||
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
|
||||
fun finishDecoding(type: KType)
|
||||
}
|
||||
|
||||
private class LazyDecodableDataSetAdapter<T : Any>(val dataSet: 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
|
||||
LazyDecodableDataSet<T>, DataSet<T> by 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
|
||||
override fun finishDecoding(type: KType) = 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
|
||||
/**
|
||||
* Trivial [LazyDecodableDataSet] implementation.
|
||||
*/
|
||||
private class SimpleDataSet(private val prototype: DataSetPrototype) : LazyDecodableDataSet<Any> {
|
||||
|
||||
lateinit var type: KType
|
||||
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
|
||||
lateinit var data: Map<Name, Pair<Meta, 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 finishDecoding(type: KType) {
|
||||
this.type = type
|
||||
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
|
||||
val serializer = serializer(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
|
||||
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
|
||||
.mapKeys { (name, _) -> Name.of(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
|
||||
.mapValues { (_, pair) ->
|
||||
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 (meta, data) = pair
|
||||
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
|
||||
Pair(
|
||||
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
|
||||
Json.decodeFromString(MetaSerializer, 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
|
||||
Json.decodeFromString(serializer, 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
|
||||
get() = type
|
||||
|
||||
override fun flowData(): Flow<NamedData<Any>> =
|
||||
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
|
||||
data.map { (name, pair) ->
|
||||
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 (meta, data) = pair
|
||||
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, meta, 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)
|
||||
}.asFlow()
|
||||
|
||||
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
|
||||
override suspend fun getData(name: Name): Data<Any>? = data[name]?.let { (meta, 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, meta, 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
|
||||
}
|
||||
}
|
||||
|
||||
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
|
||||
private object DataSetCoder : Coder<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
|
||||
override fun decode(entity: Entity, context: CodingContext): 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
|
||||
val string = entity.data.toString(Charset.defaultCharset())
|
||||
val prototype = Json.decodeFromString(serializer<DataSetPrototype>(), string)
|
||||
return SimpleDataSet(prototype)
|
||||
}
|
||||
|
||||
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
|
||||
override fun encode(value: LazyDecodableDataSet<Any>, 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()
|
||||
val string = Json.encodeToString(serializer(), prototype)
|
||||
return Entity(RawData.copyFrom(string, Charset.defaultCharset()))
|
||||
|
||||
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
|
Use
ConnectionPool
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?