Что делать
Интересно, а анализатор вот такую штуку в прологе функции поймёт и элиминирует баундчеки?
Да, элиминирует. Круто
УПД: элиминирует не то, что на предыдущем скрине. Оно поняло только проверку на 16й строке, про аппенды оно ничего не говорит. Скорее всего, не раздуплило
УПД: элиминирует не то, что на предыдущем скрине. Оно поняло только проверку на 16й строке, про аппенды оно ничего не говорит. Скорее всего, не раздуплило
Что делать
Да, элиминирует. Круто УПД: элиминирует не то, что на предыдущем скрине. Оно поняло только проверку на 16й строке, про аппенды оно ничего не говорит. Скорее всего, не раздуплило
УПД2: очень даже поняло:)
Без условия в начале функции, я получаю 1000нс в бенчмарке на тестовых данных. С условием - 800нс.
Без условия в начале функции, я получаю 1000нс в бенчмарке на тестовых данных. С условием - 800нс.
Внезапный факт. Костный мозг - не умный нихуя, но мозгом называется от того, что раньше всё, что внутри костей - называли мозгом. Собственно, головной мозг-то ведь тоже в кости находится.
Не переживайте, щчас вот допишу и будет целая статья про рандом. Без костных мозгов.
Не переживайте, щчас вот допишу и будет целая статья про рандом. Без костных мозгов.
👍3
О рандоме, энтропии и статистических текстах
Изначально планировалось запостить на телеграфе, там шрифт покрасивше, чем на телетайпе. Но оказалось, картинки туда больше загружать нельзя - только ссылками оставлять. Позор. Буду делать свое. Какие на жс есть wysiwyg редакторы с драг-н-дропом картинок? А еще лучше - с TeX
https://teletype.in/@floordiv/aopzfO0yNPW
Изначально планировалось запостить на телеграфе, там шрифт покрасивше, чем на телетайпе. Но оказалось, картинки туда больше загружать нельзя - только ссылками оставлять. Позор. Буду делать свое. Какие на жс есть wysiwyg редакторы с драг-н-дропом картинок? А еще лучше - с TeX
https://teletype.in/@floordiv/aopzfO0yNPW
Teletype
О рандоме, энтропии и статистических тестах
Рандом вездесущ. Рандом необходим. На рандоме строится криптография - верная служанка информационной эры и коммуникации как таковой...
🔥4❤🔥2❤1
i18n называется так, потому что internationalization, между i и n - 18 букв
И k8s
И a11y(вот только в душе не ебу, кто это такой)
И l10n - localization
И k8s
И a11y
И l10n - localization
Что делать
Мне понадобилось полтора года, чтобы понять, что вместо OR на каждый отдельный байт, я могу просто ко всему числу 0x2020202020202020 хуйнуть. Пиздец. Меня разрывает.
Тут теперь этому говну место
Мне подарили, если что.
Мне подарили, если что.
В какой-то момент вот этот цикл и условие (пикрил 1) я вынес в отдельную функцию (пикрил 2). Подумал: круто! Абстрагирую! Меньше самоповторений!
А потом присмотрелся. Мой го стал с привкусом плюсов. Что ещё хуже - с привкусом плюсовых итераторов.
Откатил.
А потом присмотрелся. Мой го стал с привкусом плюсов. Что ещё хуже - с привкусом плюсовых итераторов.
Откатил.
Забавный эффект. Чем дальше, тем сложнее писать хороший код.
Какая-то NP задача получается, блядь.
Какая-то NP задача получается, блядь.
😁1
В HTTP/1.1 есть два вида передачи тела:- Целый
- Раздробленный*
* перевёл как мог, я ебу как их локализировать. В оригинале - chunked. Да и целым я тоже хуй его, корректно ли кликать.
С целой передачей, у нас есть Content-Length, и там конкретное количество октетов*, содержащихся в теле запроса**.
* в сетевой разработке предпочитают применять понятие "октет битов" вместо "байт", поскольку, в отличии от "байт", слово "октет" чётко говорит о том, что битов там 8. А байт - он и из 6, и из 9, и из 16 битов состоять может (CDC6600, PDP-10, PDP-11).
** В rfc2616 просят игнорировать CRLF перед методом запроса, поскольку некоторые старые и хуёвые клиенты после тела добавляли неучтённые в длине CRLF. Сия помарка осталась там и до сих пор.
С chunked всё интереснее. Он сделан для ситуаций, когда длина тела заранее неизвестна, посему мы его льём "потоком". А именно - кусками - откуда и происходит его название. Каждый кусок - это
<hex len>\r\n<data>\r\n. Шестнадцатиричная длина, перенос строки*, данные, перенос строки. Тело считается завершённым тогда, когда мы получаем чанк с нулевой длиной.* CRLF остался стандартным разделителем и до сих пор в HTTP/1.1, и пошло это ещё со времён HTTP/0.9. Unix (точнее, все unix-like уже на тот момент - линукс, бсд, OSX) издревна понимал просто LF (
\n), а вот винда, как обычно, отличилась, и хотела именно CRLF (\r\n). Поскольку упор был на гипертекстовую природу протокола, дабы быть человекочитаемым, так оно и закрепилось вплоть до самых последних rfc. Пускай некоторые имплементации и поддерживают LF-only (как, например, моя - минутка саморекламы), но такое поведение конформным не считается. В ABNF-нотации в стандарте синтаксис определяет конкретно и только CRLF.Им удобно отдавать, например, потоковый JSON ответ с сервера. Ещё очень удобно таким образом файлы лить, но их лучше совать целиком. Потому что тогда за цену 1.5 сисколлов* мы можем задействовать
sendfile(2), находясь под линуксом. А я нахожусь под линуксом, мне поебать. Zero-copy передача файла - это вот очень хорошо, на самом деле. Линусу это, кстати, не нравится.* 1 - чтобы размер файла получить, 0.5 - заголовки придётся записать отдельно от тела, но для файлов больше пары килобайт таких записей всё равно будет несколько - в результате всё равно остаёмся в выигрыше.
А ещё, благодаря такому стримингу тела, можно удобно воротить нотификации и лонгполлинг без прибегания к вебсокетам, да. Единственное - IDLE подключения всё ещё мрут по таймауту.
В более новых стандартах, у чанков ещё и появились экстеншены. Пары ключ-значение, идущие сразу после длины блока, разделённые через
;. С ними можно получить практически HTTP внутри HTTP. Жаль только мало кто их поддерживает - с точки зрения дизайна вебфреймворка/клиента ебливо. Правда, AWS S3 их использует как раз - и это проблема. Не для меня, конечно, а для тех, кто попытается распопробовать мою индигу с AWS.—
Вообще, я это всё писал, чтобы погрузить в детали перед тем, как свою проблему вывалить. Но сработал прекраснейший метод утёнка, а столь распрекраснейший текст грешен же, коли в небытие канет. Нахуй я его тогда писал, иными словами. Посему наслаждайтесь вбросом без контекста, господа.
GitHub
GitHub - indigo-web/indigo: Indigo is a blazingly fast web-framework
Indigo is a blazingly fast web-framework. Contribute to indigo-web/indigo development by creating an account on GitHub.
🔥3🥰2