Правда, есть совсем немногочисленные исключения (я нашёл только два следующих; если знаете ещё – смело сообщите их в комментариях)
Гарантированный в c++17 Unnamed return value optimization я думаю в этом списке должен быть. Компилируем старый код с -std=c++17 и вдруг начинаем звать меньше конструкторов копирования. Вообще там думаю примеров не 2 и не 3 а гораздо больше, тк даже переход между мажорными версиями компилятора, не то что переход на др. стандарт при компиляции, вносит кучу мелких изменений в поведение.
если определяется пользовательский копирующий конструктор, то допустимо ли класть его в регистр
не разрешено передавать через регистры определённые пользователем копирующие конструкторы
Наверное через регистры передаётся не ctor, а его параметры? Перефразируйте
По вашему мои слова про нелинейность масштабирования при выходе за кэш процессора - про доступ к данным?
Ничего не понял. Вы продолжаете смешивать парсинг и доступ к данных внутри распарсенной структуры. Это 2 разных действия. Когда мне говорят “доступ к данным” я считаю что имелось в виду 2е действие.
pulldown-cmark ведёт итератор как event-stream. Это чисто физически не может вам обеспечить быстрый доступ к типу, потому что придётся бегать по всему итератору.
Ничего не понял. 1 раз проходимся по тексту любым парсером, хоть nom хоть pulldown-cmark, пусть он заполняет этот ваш struct MarkdownContent. Далее все гарантии по скорости доступа даёт MarkdownContent а не парсер.
Живая иллюстрация анекдота про блондинку, печатающую 600 символов в минуту.:) Markdown не плоский, например цитаты могут быть вложены друг в друга, как вы это представите плоским массивом слайсов? Если при парсинге не собирать AST, естественно инпут можно жрать гигабайтами в секунду, но то, что спарсено, это будет не markdown, а какое-то его упрощённое подмножество/диалект. Сделать производительный парсинг легко; трудно (невероятно трудно) организовать структуру данных для AST, которая показывает приемлемую производительность при редактировании.
был необходим мгновенный доступ к конкретным типам данных. По этой причине pulldown-cmark я сразу отсёк
При чём здесь тогда производительность парсинга, если речь про производительность доступа? Вы можете спарсить md неэффективным алгоритмом за O(N!) но выдать структуру данных с доступом за O(1). Ну и в любом pull down парсере при наступлении события входа в элемент можно просто взять и заполнять свою структуру индексов какую хочешь. В т.ч. индексировать куски текста с данным типом форматирования, как в вашем случае.
ps: откуда у вас возьмётся инкрементальный репарсинг если на вход поступает весь текст? Инкрементальный репарсинг возможен только если парсер общается с редактором, который говорит ему, в какой позиции произошло изменение и какое оно.
Яннп. Вы навалили себе кучу лишних кастомных настроек, какой-то курс биткоина, какая-то смена обоев раз в полчаса. Потом ожидаемо выяснилось, что это всё ненужно и часто ломается. Из этого вы делаете вывод, что кастомизация вообще не нужна. ???
В dev окружении основная часть кастомизации происходит в области IDE и шелла (тк в них действительно проходят многие часы), но впечатление что вы почему-то занимались не тем что важно, а unix GUI/TUI окружением, которое 1 раз обычно настроил и оно годами не меняется.
Правым пальцем и надо. Обоснование: на ортолинейных клавиатурах придётся печатать правым пальцем (тк 6 там, как и следует ожидать, находится в ряду для правого пальца) –
– а на скошенных клавиатурах придётся делать то же для единообразия рефлекса.
Скучно… Ai ai ai ai, какие-то помощники которые лезут под руку и что-то предлагают, какой-то курсор который на лету генерит кучу контекста от малейшего движения (кошмар ux/ui имхо), странная логика одновременного открывания документа на многих устройствах, NIH экосистема вместо проверенных десктопных программ. А могли бы просто сделать сверхдешёвый ноут, не прибивая к нему гвоздями свою ос, чтобы на нём работал Windows и пара основных дистрибутивов Linux, - и получить всенародную любовь и заодно съесть в стиле Android сегмент дешёвых офисных лэптопов. Но видимо сейчас не навернув AI и неведомой хрени, образующей ✨экосистему✨, никакую линейку продуктов не запустить. Хромбуки после удаления ChromeOS это отличные устройства, у меня до сих пор Toshiba chromebook 2 с Debian основная печатная для работы вне дома, 2015 год, 200$ стоил на тот момент.
За два года было разработано примерно сто внутренних расширений. Это позволило реализовать множество сценариев, раньше казавшихся невозможными.
Ну конечно, легко и приятно писать с нуля. Как “техлиду внутренней расширяемости” IDE (не вполне понимаю что этот титул означает), ему бы стоило знать, что чтобы догнать экосистему плагинов некоторых редакторов, нужны годы и рабочее время разрабов, и при этом надо ещё заниматься строгим контролем и стандартизацией всех эти 100+ расширений, иначе они превратятся в гору велосипедов с сильным разбросом по качеству.
Эти 100 расширений образуют строгую и расширяемую систему, которая хотя бы в теории или в обозримом будущем может соревноваться с большими экосистемами плагинов вроде Emacs? Я в этой экосистеме 100 расширений могу сделать стандартным способом что-либо? Например, подключить подсветку синтаксиса нового ЯП, новый дебаггер (DAP), новый движок нечёткого выбора в менюшках (fzf frizbee итд)? Или всё же накоммитили каких-то 100 расширений для конечных задач и думают, что решить проблему фрагментации IDE и накопленного в других IDE функционала так просто?
Или я вот пользуюсь модальным редактированием на постоянной основе, у них в этом супер-редакторе есть плагин, имитирующий поведение Vim с той же точностью, с которой это делает например Emacs Evil mode? И таких требований, которые реализовать в редакторе с нуля затратно, у каждого разработчика по несколько штук, они все разные, и про каждое он заявит что это must have.
Стандартизовать IDE на работе - бессмысленно, в этом я 100% согласен с Jeff Dean.
Это довольно узкое понимание… Для начала, копилотов два. Есть Microsoft Copilot, ранее Copilot, изначально был чатботом над GPT, мог использоваться в тч для автодополнения в IDE, но сейчас разросся до агента для экосистемы MS 365, умеющего дёргать функции офисных приложений. И есть Github Copilot, это отдельный продукт, полноценный агент, не чатбот делающий автодополнение.
PS: Всратость заглавной картинки просто поражает воображение!
Превратить буквенную клавишу в модификатор не так просто, как вы думаете. При быстром наборе очень часто возникает ситуация, когда 1ю клавишу ещё не отпустили, а 2я уже нажата. Как вы отличите включение модификатора от быстрого набора?
это назначить Shift на клавиши, которые уже под мизинцами
Плохое решение. Мизинцы вам не скажут спасибо, что вы их назначаете на удерживаемую клавишу (модификатор). Эргоклавиатуры и эргораскладки как раз стремятся разгрузить мизинцы. На эргоклавиатурах это делается например созданием 2 островов доп. клавиш под большой палец (thumb pad), на обычных клавиатурах это обычно или ремап Alt на Shift или путешествие в зыбкий мир Mod-tap (назначение какой-л. буквенной клавиши, только всё же не той что под мизинцем, модификатором при зажатии), с необходимостью бороться с неоднозначностью описанной выше.
Не принимается. Косвенный доступ по указателю не существенный, учитывая, что потом всё равно будет куча обращений к памяти для чтения строк и их конкатенации. Перерасход памяти выглядит куда более существенной проблемой.
Экономия на спичках. В реальности скорее всего потеряете в производительности в несколько раз. Массив смартпоинтеров - это куча лишних аллокаций и структура данных с непредсказуемым и нелокальным расположением элементов, крайне враждебная к оптимизациям.
Так и вышло: для большого города наш деревенский сервер выглядел как подозрительный тип с рынка — вроде живой, а верить ему никто не спешит. Письмо лежало в папке «Спам»
Боже какая чушь. Гугл просто не примет письмо с SMTP нонейма.
Одной из самых раздражающих проблем стали фризы интерфейса при загрузке 4K-изображений. Сейчас я работаю над внедрением std::jthread из стандарта C++20.
Каким образом jthread может решить вашу проблему, явно происходящую от того, что UI и загрузка не распараллелены?
так как проект использует современные фичи вроде std::format (в планах) и асинхронные потоки
ни того ни другого в коде нет
я реализовал обертку CurlWrapper с использованием принципов RAII.
не изобретайте велосипед, используйте библиотеку
стандарт C++20. Это критично, так как проект использует современные фичи вроде std::format
Вы удивитесь насколько слабая поддержка std::format в STL C++20. Используйте libfmt лучше сразу
Системное программирование — это не страшно
У вас не системная а прикладная утилита, несмотря на то что C++
Гарантированный в c++17 Unnamed return value optimization я думаю в этом списке должен быть. Компилируем старый код с -std=c++17 и вдруг начинаем звать меньше конструкторов копирования. Вообще там думаю примеров не 2 и не 3 а гораздо больше, тк даже переход между мажорными версиями компилятора, не то что переход на др. стандарт при компиляции, вносит кучу мелких изменений в поведение.
Наверное через регистры передаётся не ctor, а его параметры? Перефразируйте
напишите пожалуйста псевдокодом, как вы понимаете работу инкрементального парсера, если входом является весь текст
Ничего не понял. Вы продолжаете смешивать парсинг и доступ к данных внутри распарсенной структуры. Это 2 разных действия. Когда мне говорят “доступ к данным” я считаю что имелось в виду 2е действие.
Ничего не понял. 1 раз проходимся по тексту любым парсером, хоть nom хоть pulldown-cmark, пусть он заполняет этот ваш struct MarkdownContent. Далее все гарантии по скорости доступа даёт MarkdownContent а не парсер.
Живая иллюстрация анекдота про блондинку, печатающую 600 символов в минуту.:) Markdown не плоский, например цитаты могут быть вложены друг в друга, как вы это представите плоским массивом слайсов? Если при парсинге не собирать AST, естественно инпут можно жрать гигабайтами в секунду, но то, что спарсено, это будет не markdown, а какое-то его упрощённое подмножество/диалект. Сделать производительный парсинг легко; трудно (невероятно трудно) организовать структуру данных для AST, которая показывает приемлемую производительность при редактировании.
При чём здесь тогда производительность парсинга, если речь про производительность доступа? Вы можете спарсить md неэффективным алгоритмом за O(N!) но выдать структуру данных с доступом за O(1). Ну и в любом pull down парсере при наступлении события входа в элемент можно просто взять и заполнять свою структуру индексов какую хочешь. В т.ч. индексировать куски текста с данным типом форматирования, как в вашем случае.
ps: откуда у вас возьмётся инкрементальный репарсинг если на вход поступает весь текст? Инкрементальный репарсинг возможен только если парсер общается с редактором, который говорит ему, в какой позиции произошло изменение и какое оно.
Странная проблема. Обычно по первому багфиксу нового разработчика ведут за ручку от и до.
Яннп. Вы навалили себе кучу лишних кастомных настроек, какой-то курс биткоина, какая-то смена обоев раз в полчаса. Потом ожидаемо выяснилось, что это всё ненужно и часто ломается. Из этого вы делаете вывод, что кастомизация вообще не нужна. ???
В dev окружении основная часть кастомизации происходит в области IDE и шелла (тк в них действительно проходят многие часы), но впечатление что вы почему-то занимались не тем что важно, а unix GUI/TUI окружением, которое 1 раз обычно настроил и оно годами не меняется.
Вроде всё по делу, но кривой машинный язык в паре мест режет глаз.
Што
При чём здесь ассемблер, “владение” это сущность на уровне .rs кода, в LLVM IR его нету уже
это signature что ли? Странный способ выражаться. “При приведении типов”
Опечатки
Клёвое усреднение между поллить и рофлить
Правым пальцем и надо. Обоснование: на ортолинейных клавиатурах придётся печатать правым пальцем (тк 6 там, как и следует ожидать, находится в ряду для правого пальца) –
– а на скошенных клавиатурах придётся делать то же для единообразия рефлекса.
Скучно… Ai ai ai ai, какие-то помощники которые лезут под руку и что-то предлагают, какой-то курсор который на лету генерит кучу контекста от малейшего движения (кошмар ux/ui имхо), странная логика одновременного открывания документа на многих устройствах, NIH экосистема вместо проверенных десктопных программ. А могли бы просто сделать сверхдешёвый ноут, не прибивая к нему гвоздями свою ос, чтобы на нём работал Windows и пара основных дистрибутивов Linux, - и получить всенародную любовь и заодно съесть в стиле Android сегмент дешёвых офисных лэптопов. Но видимо сейчас не навернув AI и неведомой хрени, образующей ✨экосистему✨, никакую линейку продуктов не запустить. Хромбуки после удаления ChromeOS это отличные устройства, у меня до сих пор Toshiba chromebook 2 с Debian основная печатная для работы вне дома, 2015 год, 200$ стоил на тот момент.
Ну конечно, легко и приятно писать с нуля. Как “техлиду внутренней расширяемости” IDE (не вполне понимаю что этот титул означает), ему бы стоило знать, что чтобы догнать экосистему плагинов некоторых редакторов, нужны годы и рабочее время разрабов, и при этом надо ещё заниматься строгим контролем и стандартизацией всех эти 100+ расширений, иначе они превратятся в гору велосипедов с сильным разбросом по качеству.
Эти 100 расширений образуют строгую и расширяемую систему, которая хотя бы в теории или в обозримом будущем может соревноваться с большими экосистемами плагинов вроде Emacs? Я в этой экосистеме 100 расширений могу сделать стандартным способом что-либо? Например, подключить подсветку синтаксиса нового ЯП, новый дебаггер (DAP), новый движок нечёткого выбора в менюшках (fzf frizbee итд)? Или всё же накоммитили каких-то 100 расширений для конечных задач и думают, что решить проблему фрагментации IDE и накопленного в других IDE функционала так просто?
Или я вот пользуюсь модальным редактированием на постоянной основе, у них в этом супер-редакторе есть плагин, имитирующий поведение Vim с той же точностью, с которой это делает например Emacs Evil mode? И таких требований, которые реализовать в редакторе с нуля затратно, у каждого разработчика по несколько штук, они все разные, и про каждое он заявит что это must have.
Стандартизовать IDE на работе - бессмысленно, в этом я 100% согласен с Jeff Dean.
У e-ink же частота обновления экрана низкая? Как скроллить текст, документы, веб-страницы? Есть подозрение, что глазки это будет убивать посильнее ЭЛТ
В источнике примеров у меня сомнений нет :) https://doc.rust-lang.org/unstable-book/language-features/coroutines.html
“Когда лень нормально добавить в систему бана сущность ‘вечный бан’ и ты пишешь говнокод с магической датой 9999”
Это довольно узкое понимание… Для начала, копилотов два. Есть Microsoft Copilot, ранее Copilot, изначально был чатботом над GPT, мог использоваться в тч для автодополнения в IDE, но сейчас разросся до агента для экосистемы MS 365, умеющего дёргать функции офисных приложений. И есть Github Copilot, это отдельный продукт, полноценный агент, не чатбот делающий автодополнение.
PS: Всратость заглавной картинки просто поражает воображение!
Первый раз слышу модный термин “дринкап”, но мне кажется он означает, что в бутылках на столах будет отнюдь не минералка!
Превратить буквенную клавишу в модификатор не так просто, как вы думаете. При быстром наборе очень часто возникает ситуация, когда 1ю клавишу ещё не отпустили, а 2я уже нажата. Как вы отличите включение модификатора от быстрого набора?
Плохое решение. Мизинцы вам не скажут спасибо, что вы их назначаете на удерживаемую клавишу (модификатор). Эргоклавиатуры и эргораскладки как раз стремятся разгрузить мизинцы. На эргоклавиатурах это делается например созданием 2 островов доп. клавиш под большой палец (thumb pad), на обычных клавиатурах это обычно или ремап Alt на Shift или путешествие в зыбкий мир Mod-tap (назначение какой-л. буквенной клавиши, только всё же не той что под мизинцем, модификатором при зажатии), с необходимостью бороться с неоднозначностью описанной выше.
Экономия на спичках. В реальности скорее всего потеряете в производительности в несколько раз. Массив смартпоинтеров - это куча лишних аллокаций и структура данных с непредсказуемым и нелокальным расположением элементов, крайне враждебная к оптимизациям.
Судя по тексту, настройка SPF DKIM итд произошла уже после того, как gmail якобы принял письмо
Боже какая чушь. Гугл просто не примет письмо с SMTP нонейма.
Каким образом jthread может решить вашу проблему, явно происходящую от того, что UI и загрузка не распараллелены?
ни того ни другого в коде нет
не изобретайте велосипед, используйте библиотеку
Вы удивитесь насколько слабая поддержка std::format в STL C++20. Используйте libfmt лучше сразу
У вас не системная а прикладная утилита, несмотря на то что C++