Дней десять.

ох, мать моя родная. у меня только 2 дня пока что высокая температура.

Кажется, что ковид, но тесты не делал.

Береги силы!

Возьми Falco

А я уже завтра собрался аспнет учить!

Это норм, правда иногда говорят по мозгам даёт ковидла, так что не пугайся если что

А теперь я понял. Несколько дней назад готовил запеканку, но ошибся в два раза с количеством творога.

@AnutaU Спасибо за предупреждение!

Я не понял, гсомикс из чата выходил, чтобы никого не заразить?

https://www.youtube.com/watch?v=vQFvX7I6Ihw

Чисто сюжет?

Часов 60 , не больше

Касты на каждом шаге обработки стрима замучился писать. @omgszer - что я делаю не так? :)

Ну ничего, страдай с жавой. На котлине все было бы ок

у меня получилось примерно 110 с зачисткой около 85%

Ну ничего, страдай с жавой. На котлине все было бы ок

https://youtu.be/RaI3gEHF5Hg

Два дня ломал голову над проблемой после перехода на .NET 5, вместе с которым мы обновили несколько нугетов, включая клиент Раббита. Время от времени входящие сообщения из очередей RabbitMQ оказывались запорченными. Прямо мусор какой-то в теле сообщения. Подобных проблем не видел лет десять как минимум, мы ж в дотнете с managed memory работаем. После долгих поисков выяснилось, что .NET 5 здесь, разумеется, не при чем (я его и не подозревал), а причем изменение апи раббита, который вместо byte array теперь работает с ReadOnlyMemory. И строго предупреждает, что получив эту память нужно ее вначале записать в свои данные, а потом уже возвращаться из callback'а. А у нас, поскольку акторы везде, в одном месте это поле ReadOnlyMemory напрямую послали в другой актор. Со всеми вытекающими последствиями.

Два дня ломал голову над проблемой после перехода на .NET 5, вместе с которым мы обновили несколько нугетов, включая клиент Раббита. Время от времени входящие сообщения из очередей RabbitMQ оказывались запорченными. Прямо мусор какой-то в теле сообщения. Подобных проблем не видел лет десять как минимум, мы ж в дотнете с managed memory работаем. После долгих поисков выяснилось, что .NET 5 здесь, разумеется, не при чем (я его и не подозревал), а причем изменение апи раббита, который вместо byte array теперь работает с ReadOnlyMemory. И строго предупреждает, что получив эту память нужно ее вначале записать в свои данные, а потом уже возвращаться из callback'а. А у нас, поскольку акторы везде, в одном месте это поле ReadOnlyMemory напрямую послали в другой актор. Со всеми вытекающими последствиями.

А почему там не пайпы, а просто спан?🤔

так тут же наверное проблема не в ReadOnlyMemory, а то что рэбит скорее всего пулинг стал юзать

а вот были бы линейные типы...

от этого не должно ничего сломаться) проблема что ты передаешь без копирования, а на коллбэке они чистят или переиспользуют эту память.

требую тлдр)

в линейных типах можно на уровне типа задать число его использований например у меня сигнатура вида T 2 -> T 1 это значит что мне надо принять некий тип у которого есть 2 заряда передачи по ссылке а мне надо вернуть такой же тип с одним зарядом Это значит что я обязан написать функцию которая использует один заряд

вот это жесть)

И даже если тебе приходит референс-тип, постольку поскольку ты его не трогаешь, обращайся к нему хоть откуда. Здесь же нужно быть начеку - в данные могут в любой момент (после возврата коллбэка) что-то еще написать.

или вот A 1 -> B 1 мне дают ридонли спан с ОДНОЙ возможностью его использовать (записать или прочитать) мне надо вернуть другой тип с ОДНОЙ возможностью его использовать

это же беда для разработчиков апи, они должны предугадать сколько зарядов нужно пользователю)

это же беда для разработчиков апи, они должны предугадать сколько зарядов нужно пользователю)

вот это жесть)

так а так получается неьлзя писать let x = xSOdnimZariadom() a(x) b(x) откуда мы знаем попытались ли в a и b прочитать x?