Size: a a a

Scala User Group

2020 November 30

AS

Artem Sokolov in Scala User Group
линеаризация это же про реплики, а не про последовательное выполнение рид-райт
источник

AS

Artem Sokolov in Scala User Group
если у него одно мастер приложение которое решает перед клиентом за данные монопольно - оно по определению линеаризовано (точнее все операции облают свойством линеаризованности), просто потому что оно одно и не представляет из себя распределенную вещь с точки зрения клиента
источник

AS

Artem Sokolov in Scala User Group
источник

Oℕ

Oleg ℕizhnik in Scala User Group
Artem Sokolov
линеаризуют? разве не "сериализуют"?
Да, сериализация
источник

Oℕ

Oleg ℕizhnik in Scala User Group
Artem Sokolov
линеаризация это же про реплики, а не про последовательное выполнение рид-райт
Нет, это тоже про последовательное выполнение, но более строгая версия
источник

AS

Artem Sokolov in Scala User Group
это ортогональные версии
источник

Oℕ

Oleg ℕizhnik in Scala User Group
неп
источник

AS

Artem Sokolov in Scala User Group
ты можешь сериализовать транзакции, но иметь не линеаризированную систему реплик
источник

Oℕ

Oleg ℕizhnik in Scala User Group
Да, но не обратно
источник

Oℕ

Oleg ℕizhnik in Scala User Group
Поэтому это более строгая версия
источник

AS

Artem Sokolov in Scala User Group
линеаризация ничего не говорит про канкаренси
источник

AS

Artem Sokolov in Scala User Group
применится может и так и так это рандом
источник

Oℕ

Oleg ℕizhnik in Scala User Group
Artem Sokolov
линеаризация ничего не говорит про канкаренси
https://en.wikipedia.org/wiki/Linearizability
In concurrent programming, an operation (or set of operations) is linearizable if it consists of an ordered list of invocation and response events (callbacks), that may be extended by adding response events such that:

   The extended list can be re-expressed as a sequential history (is serializable), and
   That sequential history is a subset of the original unextended list.

Informally, this means that the unmodified list of events is linearizable if and only if its invocations were serializable, but some of the responses of the serial schedule have yet to return
источник

AS

Artem Sokolov in Scala User Group
а, я понял. мы про разные значения говорили
я про линеаризацию в контексте реплик
не знал что в канкаренси есть линеаризация
источник

Oℕ

Oleg ℕizhnik in Scala User Group
ну вот тут о той же самой линеаризуемости говорится
источник

AS

Artem Sokolov in Scala User Group
Oleg ℕizhnik
ну вот тут о той же самой линеаризуемости говорится
нет же
источник

AS

Artem Sokolov in Scala User Group
я глубоко не копал в оба определения, но на первый взгляд они про разное. одно про канкаренси (детерменированость и гарантии при параллельном выполнении групп операций), другое про реплики (консистентность данных по репликам)
источник

VS

Vladimir Sapronov in Scala User Group
Приветствую уважаемые!

Имею вопрос-предположение и нескем обмозговать...

Делаю чтто-то вроде "попарсим значения всяких разных типы типобезопасно". Т.е. хочется, чтобы была ф-ция read[T](s: String): T которая парсит из строки значение типа T. Т.к. нужна типобезопасность, то добавляю имплиситный декодер: read[T](s: String)(implicit decoder: String => T): T ну и понятно, если декодер определен для T то все хорошо.

Теперь проблема кооторую я имею касается enumreatum енамов. Вот такой декодер я соорудить смог:
def decodeStringEnum[T <: StringEnumEntry: StringEnum](s: String): T =
   implicitly[StringEnum[T]].withValue(s)


Но не смог его (1) имплиситно прокинуть (2) использовать его не специфицируя T. Смог только вот так:
va
l theChoice = TheReader.read[Choice]("SECOND")(StringCodecs.decodeStringEnum[Choice])
// Choice - это enumeratum енам

Вот здесь сделал пример, для наглядности с Int и с енамом, Int - это то как хочется для енамов....
https://scastie.scala-lang.org/5lDY5EmNQ1OuJ43iJ1UiwA
источник

M

Mikhail in Scala User Group
Vladimir Sapronov
Приветствую уважаемые!

Имею вопрос-предположение и нескем обмозговать...

Делаю чтто-то вроде "попарсим значения всяких разных типы типобезопасно". Т.е. хочется, чтобы была ф-ция read[T](s: String): T которая парсит из строки значение типа T. Т.к. нужна типобезопасность, то добавляю имплиситный декодер: read[T](s: String)(implicit decoder: String => T): T ну и понятно, если декодер определен для T то все хорошо.

Теперь проблема кооторую я имею касается enumreatum енамов. Вот такой декодер я соорудить смог:
def decodeStringEnum[T <: StringEnumEntry: StringEnum](s: String): T =
   implicitly[StringEnum[T]].withValue(s)


Но не смог его (1) имплиситно прокинуть (2) использовать его не специфицируя T. Смог только вот так:
va
l theChoice = TheReader.read[Choice]("SECOND")(StringCodecs.decodeStringEnum[Choice])
// Choice - это enumeratum енам

Вот здесь сделал пример, для наглядности с Int и с енамом, Int - это то как хочется для енамов....
https://scastie.scala-lang.org/5lDY5EmNQ1OuJ43iJ1UiwA
Тебе стоит пройти примерно в этом направлении и скорее всего вопрос отпадет сам собой https://scastie.scala-lang.org/rudogma/DqdoIKdaSs6Mb5gtCyeUwQ/2
источник

VS

Vladimir Sapronov in Scala User Group
Не понял? Это же ровно то, что у меня в скасте и написано, или я не вижу в упор чего-то?
источник