λ
import semigroupal syntax
Size: a a a
2020 December 24
Oℕ
или fa product fb
DR
или fa product fb
где этот синтаксис лежит?
Oℕ
там же
Oℕ
семигрупал должен быть
DR
в семигрупале?
Oℕ
или апплай
Oℕ
апплай вроде экспортит весь синтаксис семигрупала
DR
хм
семигрупал для МонадЕррора надо вручную выводить?
семигрупал для МонадЕррора надо вручную выводить?
λ
хм
семигрупал для МонадЕррора надо вручную выводить?
семигрупал для МонадЕррора надо вручную выводить?
Нет
λ
Monaderror extends Semigroupal транзитивно
AS
как по английски "читаемый код"?
дословно readable или как в названии книжки - "clean code"?
дословно readable или как в названии книжки - "clean code"?
AD
readable это же более в сторону тот который вообще можно прочитать?
AS
readable вполне нормально здесь использовать
Oℕ
cleanable
Oℕ
он сам удалил
AS
namek ponal
2020 December 25
R
что означает вот этот буфер?
где будут храниться по 10 элементов (максимум) в любой момент времени?где будут находиться те, которые ещё не попали в буфер, а ждут своей очереди?
в конце концов, все элементы рано или поздно попадут в Sink?
где будут храниться по 10 элементов (максимум) в любой момент времени?где будут находиться те, которые ещё не попали в буфер, а ждут своей очереди?
в конце концов, все элементы рано или поздно попадут в Sink?
VR
RAFIZ
что означает вот этот буфер?
где будут храниться по 10 элементов (максимум) в любой момент времени?где будут находиться те, которые ещё не попали в буфер, а ждут своей очереди?
в конце концов, все элементы рано или поздно попадут в Sink?
где будут храниться по 10 элементов (максимум) в любой момент времени?где будут находиться те, которые ещё не попали в буфер, а ждут своей очереди?
в конце концов, все элементы рано или поздно попадут в Sink?
https://doc.akka.io/docs/akka/current/stream/operators/Source-or-Flow/buffer.html
Буфер — это отдельный стейдж в стриме. Стейдж может делать с входящими элементами всё, что ему вздумается, в том числе хранить внутри себя. Таким образом, элементы будут храниться в самом буфере.
Если даунстрим быстрее апстрима, буфер будет всегда пустым. Если апстрим быстрее даунстрима, буфер будет всегда наполнен, а судьба элементов сверх лимита определяется стратегией переполнения (в примере dropHead, т. е. новые элементы вытесняют старые элементы из буфера, то есть всё, что не успело уйти в даунстрим, будет просто выброшено). Соответственно, если скорости апстрима и/или даунстрима меняются, поведение будет сложнее, но суть та же: не более 10 элементов в буфере, лишнее отбрасывается.
В sink попадёт всё, что не было отброшено из-за overflow strategy. Если нужно гарантировать попадание всех элементов в даунстрим, нужно заменить стратегию на backpressure.
Буфер — это отдельный стейдж в стриме. Стейдж может делать с входящими элементами всё, что ему вздумается, в том числе хранить внутри себя. Таким образом, элементы будут храниться в самом буфере.
Если даунстрим быстрее апстрима, буфер будет всегда пустым. Если апстрим быстрее даунстрима, буфер будет всегда наполнен, а судьба элементов сверх лимита определяется стратегией переполнения (в примере dropHead, т. е. новые элементы вытесняют старые элементы из буфера, то есть всё, что не успело уйти в даунстрим, будет просто выброшено). Соответственно, если скорости апстрима и/или даунстрима меняются, поведение будет сложнее, но суть та же: не более 10 элементов в буфере, лишнее отбрасывается.
В sink попадёт всё, что не было отброшено из-за overflow strategy. Если нужно гарантировать попадание всех элементов в даунстрим, нужно заменить стратегию на backpressure.
R
https://doc.akka.io/docs/akka/current/stream/operators/Source-or-Flow/buffer.html
Буфер — это отдельный стейдж в стриме. Стейдж может делать с входящими элементами всё, что ему вздумается, в том числе хранить внутри себя. Таким образом, элементы будут храниться в самом буфере.
Если даунстрим быстрее апстрима, буфер будет всегда пустым. Если апстрим быстрее даунстрима, буфер будет всегда наполнен, а судьба элементов сверх лимита определяется стратегией переполнения (в примере dropHead, т. е. новые элементы вытесняют старые элементы из буфера, то есть всё, что не успело уйти в даунстрим, будет просто выброшено). Соответственно, если скорости апстрима и/или даунстрима меняются, поведение будет сложнее, но суть та же: не более 10 элементов в буфере, лишнее отбрасывается.
В sink попадёт всё, что не было отброшено из-за overflow strategy. Если нужно гарантировать попадание всех элементов в даунстрим, нужно заменить стратегию на backpressure.
Буфер — это отдельный стейдж в стриме. Стейдж может делать с входящими элементами всё, что ему вздумается, в том числе хранить внутри себя. Таким образом, элементы будут храниться в самом буфере.
Если даунстрим быстрее апстрима, буфер будет всегда пустым. Если апстрим быстрее даунстрима, буфер будет всегда наполнен, а судьба элементов сверх лимита определяется стратегией переполнения (в примере dropHead, т. е. новые элементы вытесняют старые элементы из буфера, то есть всё, что не успело уйти в даунстрим, будет просто выброшено). Соответственно, если скорости апстрима и/или даунстрима меняются, поведение будет сложнее, но суть та же: не более 10 элементов в буфере, лишнее отбрасывается.
В sink попадёт всё, что не было отброшено из-за overflow strategy. Если нужно гарантировать попадание всех элементов в даунстрим, нужно заменить стратегию на backpressure.
спасибо большое. все понятно!
как раз было интересно, что будет с элементами, которые были вытеснены, но не успели попасть в даунстрим. выбросятся, получается
как раз было интересно, что будет с элементами, которые были вытеснены, но не успели попасть в даунстрим. выбросятся, получается