А что особенного при этом в esp32? С помощью него можно что-то, чего нельзя сделать с обычного интерфейса в десктопе? Или это из ряда «даже на esp это получилось»?
Если под строками с экранированными символами вы подразумеваете json-строки, то и ничего страшного: буферизируете токены, пока не соберётся полный литерал; либо наткнётесь на ошибку.
Что касается формализации, так эта проблема никак не решается наивным разбиением на некоторые допустимые блоки исходных данных. Более того, вы вводите тем самым допущение, что очередная порция данных не будет превышать какой-то порог.
сначала разметил блок, валидация и ток потом парсинг
Вы не можете нормально валидировать блок, пока не распарсите его. В общем, если вы захотите сделать валидатор жсона, у вас получится парсер. Впрочем, вы и границы блока не сможете нормально определить по этой же причине.
Поэтому определение границы блока, валидация и парсинг — по сути один процесс, который можно и нужно делать в один проход. Ну а коли так, то почему бы и не из пайпа, к примеру? Если переживаете насчёт памяти, то можно и добавить проверку превышения некоторого порога.
Видимо, вопрос с подвохом, потому что есть возможность читать не просто построчно или поблочно, а по-токенно. Читать его хоть из потока, и на лету декодировать содержимое
Насколько мне известно, в го применяются разные подходы в случае с функциями и в случае с типами. Для функций предусмотрен механизм «шаблонных функций», типа как в плюсах: компилятор находит все варианты использования и генерирует несколько вариантов для всех задействованных — потому они не дают оверхеда. А вот для типов на этапе компиляции проводятся лишь поверхностные проверки совместимости, а в рантайме начинается цирк с приведениями, что бьёт по производительности.
Ну и нет нужды явно указывать тип в момент вызова. Если компилятор может догадаться, то он это сделает. Да, ограничения накладывать нужно при определении типа или функции — для выявления допустимых операций над типом. По сути это упрощение поиска ошибок типа «нет подходящего operator*», но только заложенное в сам дженерик, а не в место вызова.
...Пока экспериментировали с вероятностями, все сапоги они сбрасывали в кучу — 841 пару. Это довольно большая куча сапог на городской площади. Перед расходом по домам уставшая толпа заставила зачинщиков беспорядка прибраться за собой: всё нужно сложить обратно в коробки, чтобы поутру коробки эти унести на какой-нибудь склад униразмерных сапог. Разумеется, после такой изматывающей ночи сортировать сапоги никто не хотел. И стали складывать как попало: то два левых и правый, то два правых и левый, изредка получалось по три одинаковых к ряду.
Недостает только истории о том, как на рассвете рядом с пирамидой из коробок возник загадочный портал, в который эти коробки горожане и отправили — пускай ещё какая-нибудь цивилизация погреет себе голову из-за этой проклятой обуви.
По-моему вот с ними я связывался — спрашивал разрешения на публикацию перевода на Хабр. Очень понравилась статья, и описанную практику я повторил успешно (частично). Но они отказали
Аннотация такая, что я ожидал увидеть какой-то генератор, ну или хотя бы лёгкий универсальный шаблон. А тут просто список советов, причем порой вредных.
Я не буду вдаваться в синтаксис md
И очень зря, потому что выбранный для обозначения секций `**жирный шрифт**` — моветон. Примерно такой же, как и центровка текста пробелами в «богатом» документе.
Заголовки не только должны быть, они должны ещё и отражать иерархию секций, потому что по ним строится древовидное оглавление. Нельзя просто взять и решить, что у h3 шрифт великоват, потому что вопрос не в размере, а в семантике. Ну и ссылки на якоря, конечно, в том числе внутренние.
Для частного использования не подходит вообще. Когда деду нужно помочь в винде с чем-то, то эта вся чехарда с отправкой файла приглашения и дополнительно пин-кода (зачем?!) сама по себе выливается в ещё одну проблему, с которой ему нужна помощь. К тому же, и помочь можно только с винды
Мне тоже тяжело заходит, хотя тема очень интересная. Кажется, что если бы было больше оформленных в псевдокод императивных примеров, то дело бы пошло веселее
Современные коды довольно сильно украшают, потому, мне кажется, правильнее искать не вершины, а грани квадратов. Чтобы находить эти опорные квадраты даже если их углы скруглены
Фигня, совершенно непонятно, кого в наши дни может устроить 144 МГц. Да и Doom на таком малюсеньком экране гонять будет неудобно. Вот когда хотя бы до фуллхд дойдут — тогда и глянем
Длина волны — это то, что видно. Глаз, по сути, является инструментом, который позволяет определять длины волн. А вот цвет — это как раз то, чего не видно; это лишь субъективная интерпретация этих длин. Так что, если и говорить об ощущениях, то как раз про цвет можно сказать, что мы его не ощущаем. Цветам дали названия, выделили N основных цветов, и дальше остаётся только конформизм.
Условно, даже если предположить, что за цвет отвечает не длина волны, а какая-то скрытая переменная, то это не меняет сути: глаз создан именно для фиксации показателя этого свойства. По крайней мере, в моей колокольне это и называется «видим»: анализируем частоту и совокупную интенсивность, и только потом получаем полную картину.
Длина otp великовата. Придётся как-то обрезать. Можно брать остаток от деления на небольшое секретное число. И зачем вообще изобретатели пароли, ключи и fail2ban :)
На самом деле, про Sec-WebSocket-Accept мог бы и догадаться. Но вот с маскировкой — все ещё неясно: почему на стороне сервера этот механизм выглядит опциональным (mask bit), и почему mask не проверяется на пустоту? Разве сервер не должен тут увидеть непорядок и закрыть соединение с ошибкой?
А что особенного при этом в esp32? С помощью него можно что-то, чего нельзя сделать с обычного интерфейса в десктопе? Или это из ряда «даже на esp это получилось»?
Расширение к хрому — это прокси, а не впн
Ну дела... Я уже который год работаю на i3 4000m и 8 ddr3. А этот ваш космолёт уже старичком считается. Ещё дум на нём запустите.
Если под строками с экранированными символами вы подразумеваете json-строки, то и ничего страшного: буферизируете токены, пока не соберётся полный литерал; либо наткнётесь на ошибку.
Что касается формализации, так эта проблема никак не решается наивным разбиением на некоторые допустимые блоки исходных данных. Более того, вы вводите тем самым допущение, что очередная порция данных не будет превышать какой-то порог.
Вы не можете нормально валидировать блок, пока не распарсите его. В общем, если вы захотите сделать валидатор жсона, у вас получится парсер. Впрочем, вы и границы блока не сможете нормально определить по этой же причине.
Поэтому определение границы блока, валидация и парсинг — по сути один процесс, который можно и нужно делать в один проход. Ну а коли так, то почему бы и не из пайпа, к примеру? Если переживаете насчёт памяти, то можно и добавить проверку превышения некоторого порога.
Видимо, вопрос с подвохом, потому что есть возможность читать не просто построчно или поблочно, а по-токенно. Читать его хоть из потока, и на лету декодировать содержимое
del
Насколько мне известно, в го применяются разные подходы в случае с функциями и в случае с типами. Для функций предусмотрен механизм «шаблонных функций», типа как в плюсах: компилятор находит все варианты использования и генерирует несколько вариантов для всех задействованных — потому они не дают оверхеда. А вот для типов на этапе компиляции проводятся лишь поверхностные проверки совместимости, а в рантайме начинается цирк с приведениями, что бьёт по производительности.
Ну и нет нужды явно указывать тип в момент вызова. Если компилятор может догадаться, то он это сделает. Да, ограничения накладывать нужно при определении типа или функции — для выявления допустимых операций над типом. По сути это упрощение поиска ошибок типа «нет подходящего operator*», но только заложенное в сам дженерик, а не в место вызова.
...Пока экспериментировали с вероятностями, все сапоги они сбрасывали в кучу — 841 пару. Это довольно большая куча сапог на городской площади. Перед расходом по домам уставшая толпа заставила зачинщиков беспорядка прибраться за собой: всё нужно сложить обратно в коробки, чтобы поутру коробки эти унести на какой-нибудь склад униразмерных сапог. Разумеется, после такой изматывающей ночи сортировать сапоги никто не хотел. И стали складывать как попало: то два левых и правый, то два правых и левый, изредка получалось по три одинаковых к ряду.
Недостает только истории о том, как на рассвете рядом с пирамидой из коробок возник загадочный портал, в который эти коробки горожане и отправили — пускай ещё какая-нибудь цивилизация погреет себе голову из-за этой проклятой обуви.
По-моему вот с ними я связывался — спрашивал разрешения на публикацию перевода на Хабр. Очень понравилась статья, и описанную практику я повторил успешно (частично). Но они отказали
Я изучал код кандидатов на гитхабе. Откуда у вас сведения, что это было лишь однажды?
Аннотация такая, что я ожидал увидеть какой-то генератор, ну или хотя бы лёгкий универсальный шаблон. А тут просто список советов, причем порой вредных.
И очень зря, потому что выбранный для обозначения секций `**жирный шрифт**` — моветон. Примерно такой же, как и центровка текста пробелами в «богатом» документе.
Заголовки не только должны быть, они должны ещё и отражать иерархию секций, потому что по ним строится древовидное оглавление. Нельзя просто взять и решить, что у h3 шрифт великоват, потому что вопрос не в размере, а в семантике. Ну и ссылки на якоря, конечно, в том числе внутренние.
Ещё я б указал на важность tldr, но не б
Для частного использования не подходит вообще. Когда деду нужно помочь в винде с чем-то, то эта вся чехарда с отправкой файла приглашения и дополнительно пин-кода (зачем?!) сама по себе выливается в ещё одну проблему, с которой ему нужна помощь. К тому же, и помочь можно только с винды
Мне тоже тяжело заходит, хотя тема очень интересная. Кажется, что если бы было больше оформленных в псевдокод императивных примеров, то дело бы пошло веселее
Современные коды довольно сильно украшают, потому, мне кажется, правильнее искать не вершины, а грани квадратов. Чтобы находить эти опорные квадраты даже если их углы скруглены
Фигня, совершенно непонятно, кого в наши дни может устроить 144 МГц. Да и Doom на таком малюсеньком экране гонять будет неудобно. Вот когда хотя бы до фуллхд дойдут — тогда и глянем
Длина волны — это то, что видно. Глаз, по сути, является инструментом, который позволяет определять длины волн. А вот цвет — это как раз то, чего не видно; это лишь субъективная интерпретация этих длин. Так что, если и говорить об ощущениях, то как раз про цвет можно сказать, что мы его не ощущаем. Цветам дали названия, выделили N основных цветов, и дальше остаётся только конформизм.
Условно, даже если предположить, что за цвет отвечает не длина волны, а какая-то скрытая переменная, то это не меняет сути: глаз создан именно для фиксации показателя этого свойства. По крайней мере, в моей колокольне это и называется «видим»: анализируем частоту и совокупную интенсивность, и только потом получаем полную картину.
Длина otp великовата. Придётся как-то обрезать. Можно брать остаток от деления на небольшое секретное число. И зачем вообще изобретатели пароли, ключи и fail2ban :)
Оно же к WS отношения не имеет. Там просто стримится текст в определенном формате
Понял: вы для простоты примера опустили проверку. Спасибо за разъяснения
На самом деле, про Sec-WebSocket-Accept мог бы и догадаться. Но вот с маскировкой — все ещё неясно: почему на стороне сервера этот механизм выглядит опциональным (mask bit), и почему mask не проверяется на пустоту? Разве сервер не должен тут увидеть непорядок и закрыть соединение с ошибкой?