Обновить
238
force@force

Например: Программист

35
Подписчики
Отправить сообщение
Ага, программисты Гугла идеальны, и не допускают ни одного бага. Все их приложения открываются мгновенно и на световые годы опережают функционал других компаний.
А вот в Xiaomi работают студенты за 2 чашки риса, и пытаются графиком потребления памяти выложить надпись спасите нас! Но, т.к. она на китайском, никто их не понимает и они продолжают делать гадости.
/sarcasm off
Это в теории. Например, тот же шаринг вайфая. На моём телефоне всю жизнь эта фича была, но большинство, кому я хотел так пошарить не справились с квестом, потому… что у них нет читалки QR-кодов! Можно поставить? Да запросто, кто это сделал заранее: никто.
Также и с другими приложениями, поставить можно, но у большинства людей в телефоне есть только какой-нибудь Instagram, VK, WhatsApp, и ставить они ничего не планируют, пока не приспичит (или кто-то не поставит).
Главное, чтобы нижележащий слой был реализован специально под неё. Потому что сейчас NetworkStream в большом .NET реализован отвратительно в плане асинхронного чтения. Надеюсь, что тут абстракции не протекут.
На мой взгляд, получилась очень хардкорная библиотека, которую весьма тяжело использовать (да и не имеет смысла в обычной жизни). А для внутренних целей гораздо проще написать свой маленький сабсет для конкретной задачи.
Всё-таки в погоне за производительностью в Microsoft написали весьма много опасных вещей, которые в неумелых руках могут их же и оторвать.
В итоге, я в очередной раз прочитал про эту библиотеку и решил, что всё-таки она мне не нужна :)
Firefox. Очень забавный результат. Каждый раз разный :)
function dd(deep = 0) { try { return dd(deep + 1) } catch (e) { return deep; } }
dd();
21393
dd();
21089
dd()
21269
dd()
23559
dd()
23559
dd()
23559
dd()
23408
dd()
23573
dd()
> Все правильно сделали. Это напрашивающаяся сама собой оптимизация для языка, нацеленного на широкое использование функционального подхода.
Тут разница в том, что это не свойство языка, ни синтаксис, ничего. Это некое абстрактное свойство рантайма, при этом оно живёт не в статусе работает/не работает. А в статусе работает хорошо/работает плохо и иногда падает по OOM.
При этом в реальности — хром вначале добавил эту оптимизацию, потом выпилил. Т.е. если кто-то заточился на эту фичу, поимел грабли. Код развалился просто так.

> то ставите себе линтер на запрет рекурсивных вызовов и нет проблем.
Рекурсия вполне может использоваться и в обычном виде, запрещать рекурсию саму по себе — это очень странно. А линтёр, определяющий хвостовую рекурсию… ну такое…

> Я даже не представляю, что значить полифиллить хвостовую рекурсию. А для class или для геттеров/сеттеров таких вопросов не возникало?
Я тоже. Но для классов — вполне себе всё полифилится. Хотя, я может неправильно термин подобрал. Наверное транспайлинг тут лучше звучит.
Ну, глубина стека не определена, да и попытка её переполнить может привести к временному эпическому потреблению памяти или браузер от ужаса прибьёт все скрипты на странице. Опасненький такой способ. :) И опять же, писать две ветки кода, одна на случай оптимизации, другая циклом — достаточно бестолковое времяпрепровождение. Раз уж написали универсальный код, зачем поддерживать код с хвостами.
Всегда хотел спросить, а что курили авторы ES6, когда включали оптимизиацию хвостовой рекурсии в стандарт? Т.е. это не возможности языка, а свойство рантайма. При этом его ещё особо и не проверить. Да и заполифиллить его нормальным образом нельзя. В результате получается фича, которую использовать нельзя, потому что на неподдерживаемом браузере всё развалится.
Сам спросил, сам ответил
<meta name="theme-color" content="red">
Буду пользоваться :)
Вопрос не про баги :) У вас изначально была фича с подсветкой панели под цвет сайта. Вроде она достаточно фиксированная была, как придумала, так и осталась. А тут захожу на сайт Тёмы Лебедева и вижу что цвет панели меняется вместе с шапкой. Это родная фича браузера по динамической перерисовке панели в зависимости от контента, или у вас есть API для подобного и можно на своих сайтиках дёргать?
Можно утвержать, что вы патентный тролль, можно реализовать патент чуть по-другому и доказывать, что это не ваш патент, а совершенно другое решение, можно найти страну, где другое патентное законодательство и там всё делать.
А потом долго и упорно судиться, кидаясь какашками друг в друга.
Вопрос в стоимости лицензирования патента и возможной прибыли от него.
Патент как раз означает, что кто угодно может использовать данную технологию, если договорится с владельцем патента. А если владелец заломит нереальные условия, то можно судиться. Чтобы никто не заиспользовал данную технологию — надо держать её в секрете, а не патентовать.
Ну, мне поколения часто пригождались, правда больше встрявал в LOH, но и другие ситуации, связанные с «утечками» памяти тоже приходилось расследовать. Но большинству программистов нафиг не надо, да. Вопросы про это бестолковые.
Если вызвали Dispose, то финалайзер не должен вызываться. А если его забыли — то явный крэш приложения лучше, чем тихая утечкая ресурсов, которую потом отлавливать по обрывочным сведениям.
Я как-то из-за забытого диспоза при установке приложения клиенту, поехал не на поезд, а в гостиницу. И да, конечно же приложение не говорило, что кто-то забыл диспоз на 78-ой строчке в конкретном файле, и то, что забыт именно диспоз выяснилось потом.
Однако такая имплементация пула объектов — однозначно плохая идея. Как и пытаться логировать, кидать исключения, обращаться к базе и тысячи подобных действий.

Вообще, в финализаторе логировать часто хорошая идея. Потому что вызов финализатора свидетельствует о том, что разработчик забыл Dispose (Естественно, там не забыть GC.SuppressFinalize или вляпать флажок).
Смысла нет, но могу предположить что в какой-то версии вызывались разные методы или с разными аргументами. После рефакторинга остался один метод с такой странной логикой.
Ну, это как идея, чтобы оправдать автора библиотеки :)
Да, о том, что локальный резолвер всегда висит подключённый — не подумал. Правда, если оно порвётся, то будет плохо. При этом нагрузка на удалённые сервера должна быть жёсткая, держать огромное количество соединений. Но Гуглу и Клаудфлеру не жалко :)
До keep alive нужно ещё дойти. Условно говоря, если DoH через Google, а открываете какой-то другой сайт, то keep alive вообще ни при чём. Вместо двух UDP пакетов нужно 4 (лень щас считать) + небольшие томоза на сам факт SSL
Ну стоит добавить, что DoH ещё и гораздо медленнее чем классический DNS, тоже одна из проблем.
Покажите пример обфусцированного кода, можно скриншотом, так будет более понятно (шутка, если что :) ).

Информация

В рейтинге
Не участвует
Откуда
Россия
Зарегистрирован
Активность