Можно на атрибутах говнякать, но это такое себе

В общем, основная тема- это написать преобразование 'a->'metadata и 'metadata->;a

Второе преобразование требует пустого рекорда, например

Т.е. у меня функция вида 'a->'metadata_part->'a

Еще в нелегком деле десериализации помогает ArraySegment

ДЛя того, чтобы не плодить алокации сверх необходимого

стоп не то же самое, 25к за всю учебу максимум выплата, даже если больше потратил, сама учеба бесплатно. И еда не ооочень вкусно, в пол раза лучше чем как в советской столовке. Интересно в других странах как, в UK например.

Конечно нет 120+к (за 4 года) под 7% (кажется)

А либ под это дело не завезли? Пытался осознать как работает FsPickler, но он не так прост, чтобы ворваться в него со своим сериализатором. К тому же он зачем-то крутится вокруг System.IO.Stream, соответсвенно пропадает необходимый мне этап с иммутабельными результатами сериализации.

Сейчас схема такая - отдельный async под чтение байт из потока, которые прокидываются в мейлбокс, собирающий сообщения, откуда файрится сообщение постпроцессинга , ну и в конце набор эвентнов

Либ лично я не видел

FsPickler работает по тому же принципу, но это скорее будет из пушки по воробьям

Ну и главное - максимально абстрагировать сериализацию/десериализацию от способа чтения/записи

Сейчас схема такая - отдельный async под чтение байт из потока, которые прокидываются в мейлбокс, собирающий сообщения, откуда файрится сообщение постпроцессинга , ну и в конце набор эвентнов

Под "отдельным async"-ом что подразумевается?

Чтобы было пофиг, в какой канал писать/откуда читать

Под "отдельным async"-ом что подразумевается?

рекурсивный асинк

Он будет крутиться в отдельной андроидовской активити

Пока что у мя сериализация на выход дает список слов, а десериализация на входе ожидает функцию чтения n слов (ясное дело оборачивается в прорву хелперов). Хз, что будет, когда я дойду собственно до чтения гигов.

Хотелось бы как-то на комбинаторах построить десериализацию списка, чтобы еще в статике сразу получать длину и т.п.

И вроде как знаю даже, как сие сделать, но есть неиллюзорная вероятность, что будет лажа.

Канал передачи tcp?

Нет. Вообще не инет.

Описание протокола есть?

Там по идее длина сообщения должна быть

Да. Есть.

Только это к чему?

Ну длина есть, значит есть массив байт целиковый

С ним уже можно делать что угодно

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

Что ты имеешь в виду под словом?

word.

Ну uin16.

А, еще напрягают составные слова. Когда столько-то бит для этого идентификатора, еще битик для флага, потом еще какая-то хрень и т.д.

Вот как это в типах нормально представлять, хрен пойми.

А, еще напрягают составные слова. Когда столько-то бит для этого идентификатора, еще битик для флага, потом еще какая-то хрень и т.д.

Это отдельные части парсинга схемы данных

Безусловно они у меня пишутся не в основном потоке.

Там уже только функции приводящае к ворду или обратно.

Итак, у тебя есть поток, который читает/пишет байты

Плюс есть некая надстройка над потоком, которая эти байты должна преобразовывать в правильные структуры данных

Стоять.

Стою

Под потоком я не подразумевал stream/thread. Я имел ввиду, что это просто другой ряд абстракций и т.п.

Тогда я тебя не совсем понимаю

Например, того, к чему хочешь прийти

И откуда

Учитывая объем задач, скорее всего я смогу нормально сформулировать что я хочу, лишь после окончания контракта. Но натрахаться успею.

Пока есть лишь ощущение, что все какое-то небезопасное, ну или как минимум неправильное.

1. Я не понял, при чем тут int16. Подозреваю, что это поток байт с какой-то железки

С моей точки зрения int16 уже более высокоуровневая абстракция, хотя, например, в некоторых протоколах передачи данных типа Манчестер, если мне память не изменяет, как раз все и меряется машинным словом

uint16 если быть точным.

uint16 если быть точным.

Это вообще неважно обычно

Важна размерность

На низовом уровне, у мя байты, но вверх я передаю uin16.

На низовом уровне, у мя байты, но вверх я передаю uin16.

Вопрос, зачем

Или верхним уровнем не ты управляешь?

Вопрос, зачем

Все доки работают со словами.

Зачем там байты?

Значит, у тебя появляется еще один уровень преобразования byte[]->unit16[]

А потом ты хочешь uint16[] в part list, как я понимаю, некоторый

Такс, судя по part, у тебя сценарий предполагает непрерываное получение условно однотипных блоков.

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

Т.е. ситуация значительно проще, что приводит к тому, что я начинаю вы*бываться.

Т.е. ты даешь запрос и получаешь ответ, так?

Лан, в моем часовом поясе надо спать. Попробую обмозговать происходящее, чтобы выдать все это в ряде мелких задач.

Т.е. ты даешь запрос и получаешь ответ, так?

Так. Если все идет по плану.

Давай , спокойной

Вчера бабушку навестил перед переездом

А у неё клубника цветёт уже

Ток я не сфоткал чёт(

vuejs.org

Билайн душит

А у неё клубника цветёт уже

@AnutaU

@Dolfik жги

Спрасибо.

откуда их столько лезет

Опередила

Это не я

Палюбому Форнёвер!

Есть тут владельцы Surface Go?