Смотря какой процент бытовой физической активности был заложен в хождение по магазинам.
Если человек 24/7 сидит за компом на удалёнке и на улицу выбирался только в магазин, то это усугубит проблемы со здоровьем, которые теоретически тоже можно подбить к экономике и экономической выгоде)
Можно попробовать с точки зрения рендеринга diff в vscode взять за основу это расширение от microsoft, которое работает с pull request-ами в github. В вашем случае например diff от claude можно попробовать оформлять как коммит в ветке, либо просто перелопатить расширение и достать оттуда способ рендеринга, чтобы он мог кушать артефакты диффа от клауд.
Наверное в этом контексте был бы интересен инструмент, который позволяет работать с картинками, как с первоисточником (может и с некоторым подобием переменных, как показывает автор), при этом имел бы достаточно минималистичный текстовый дамп, чтобы можно было, например, анализировать диффы кода, при просмотре изменений в коммите
Вы прекрасно показали, как 11 санитайзеров дают 10 разных результатов. Это — идеальная иллюстрация принципа "не доверяй, а проверяй" при выборе инструментов безопасности.
Да, но откуда он его скачает? Где мы разместим и будем хранить эти бинарные зависимости. У пакетных менеджеров есть свои registry, которые можно поднять. Если менеджить бинарные зависимости просто в гит репозитории, у этого есть свои существенные недостатки
Наверняка можно организовать это через условые releases из условного github, но эту логику со скачиванием определенной версии релиза и тд, ее нужно реализовывать руками. Если вам известно о другом существующем способе через cmake заниматься менеджментом бинарных зависимостей, поделитесь пожалуйста
Как цмэйком управлять бинарными зависимостями, их кэшированием, версиями и тд? Скачивать это хорошо, но ведь множество библиотек мы подключаем уже собранными, в т.ч. локальные внутри проекта, как этим всем управлять?
Я не понял для чего мне dev контейнеры в этой задаче. Делая свой Dockerfile я имею полный контроль над этим образом, его содержимым, конфиг файлах и тд. Местами иногда приходилось "хакать" - например ставить сурс-листы для пакетов из более высоких версий дистрибутива linux и докачивать только определенные пакеты определенных версий. dev контейнер описывается декларативно через жисон и как будто в этом всем меньше контроля над происходящим.
Не говоря уже о том, что это снижение производительности (каждый вызов метода - создание, а потом свертывание еще одного уровня стека). Если все это вас не волнует - вам повезло.
Чем это лучше, чем clang libtool (примерно так)? В общем инструментарий фронтенда компилятора кланг. Там на входе может быть не какой-то специальный dsl который нужно изучить/понимать, а вполне себе c++ код. Там вполне себе документированные и понятные инструменты для работы с AST C++.
И этот инструмент гарантированно работает, т.к. является неотъемлемой частью полного цикла работы компилятора, ну т.е. серьезные требования к работоспособности и корректности
Как следствие, clang будет поддерживать код из нужного стандарта c++. Например, пришла бы вам в голову идея поддержать ключевое слово trivially_relocatable_if_eligible, которое скоро https://habr.com/ru/companies/yandex/articles/882518/ станет частью разбора структуры/класса и между вашими name и parents встроится? Пример только для иллюстрации того что всегда поддерживать актуальный разбор AST c++ это быть в роли догоняющего за компиляторами
Однобуквенность. Вопрос привычки, такая практика. Их всего 2 таких алиаса, как самые часто-используемые, понятно что если бы их было 10, это уже совсем другой разговор, но эти даже интуитивно понятные
В примере с ShapeUptr угловых скобок было бы на одну пару меньше, они не то чтобы куда-то испарятся все. Но вместе с тем появился и дополнительный символ, его нужно написать. Не сделать forward decl с оригинальным классом, чтобы использовать этот юзинг (т.к. он как правило рядом с определением класса), а в моем примере можно в U<MyClass> пихать такую декларацию при определённых условиях. Ну и то что говорил про поиск по символу
Про замену типа указателя. Для меня выглядит как исключительное событие и думаю писал полный тип хитрого указателя по месту, чтобы не вводить в заблуждение пользователя этого символа на предмет что под капотом. Вообще пример странный, не могу представить себе такое.
Приведу шутошную аналогию, это не аргумент и не всерьез:
Давайте в проекте определим и будем использовать
using Int = int;
Мало ли нам понадобится массово подменить целые числа, а имя Int все равно останется на месте
Сделали в проекте такие глобальные юзинги (в условном common/core.h) :
template <class T>
using U = std::unique_ptr<T>;
И также SH с шаредптр
Читаемость не теряется и не нужно руками делать на каждый такой класс отдельный юзинг.
Плюс такого подхода, что мы всегда видим оригинальный класс и например поиск по символу нужно делать не для каждого такого юзинга, а только для оригинального класса
Девайс очень модный и молодежный, выглядит вкусно. Сам бы точно не купил, по причинам описанным выше @engine9
Рекламные материалы тоже выглядят отлично, дам им немного критики:
https://busy.bar/ при скроллинге на десктопе очень заметно фризит (на заметку)
Самый первый блок с демонстрационным примером, подписанный как Show you’re BUSY - ИМХО видео совсем не отражает кейс использования. Текущий порядок:
Коробка неактивна
подходят с вопросом
коробка демонстративно активируется
раздраженный коллега уходит
На мой взгляд ценность коробки в том, чтобы заранее ее активировать, если знаешь что будешь занят ближайшее время, тогда коллега на подходе к тебе увидит это и будет иметь ввиду, когда ему подойти, так что я сделал бы такую сценку:
Коробка активируется
Таймлапсом проходит 5 минут
подходят с вопросом, но видят коробку, разворачиваются
Таймлапсом проходит все время занятости -> занятость снимается
снова подходят с вопросом, на этот раз коллега получит ответ
ИМХО стек это не структура данных, а некий намеренно ограниченный по операциям интерфейс взаимодействия со структурой данных
С какой структурой данных? Это вопрос, т.к. стек можно реализовать и на базе массива, и на связном списке, на каких-то промежуточных типа deque, ...
Это конечно дискуссионный вопрос, тут смотря как трактовать термины. Но если бы мне предложили выбрать из предложенных элементов, то что меньше всего относится к структурам данных:
Привет! как же так. вот ссылка https://github.com/simplepersonru/SimpleOntoDoc, точно такая же как в статье. Репозиторий публичный
Смотря какой процент бытовой физической активности был заложен в хождение по магазинам.
Если человек 24/7 сидит за компом на удалёнке и на улицу выбирался только в магазин, то это усугубит проблемы со здоровьем, которые теоретически тоже можно подбить к экономике и экономической выгоде)
Можно попробовать с точки зрения рендеринга diff в vscode взять за основу это расширение от microsoft, которое работает с pull request-ами в github. В вашем случае например diff от claude можно попробовать оформлять как коммит в ветке, либо просто перелопатить расширение и достать оттуда способ рендеринга, чтобы он мог кушать артефакты диффа от клауд.
Наверное в этом контексте был бы интересен инструмент, который позволяет работать с картинками, как с первоисточником (может и с некоторым подобием переменных, как показывает автор), при этом имел бы достаточно минималистичный текстовый дамп, чтобы можно было, например, анализировать диффы кода, при просмотре изменений в коммите
Ждем новостей "Представлен релиз коммита ..." :)
засквозило нейрослопом
Представим такой код:
Есть ли смысл в частичном преобразовании в ANY? т.е. примерно вот так: (все что можно, суем в ANY, остальное оставляем как было)
p.s. я не силен в особенностях внутреннего устройства postgresql
> сколько хауса
p.s. хаоса, но мой комент только ради спойлера
Да, но откуда он его скачает? Где мы разместим и будем хранить эти бинарные зависимости. У пакетных менеджеров есть свои registry, которые можно поднять. Если менеджить бинарные зависимости просто в гит репозитории, у этого есть свои существенные недостатки
Наверняка можно организовать это через условые releases из условного github, но эту логику со скачиванием определенной версии релиза и тд, ее нужно реализовывать руками. Если вам известно о другом существующем способе через cmake заниматься менеджментом бинарных зависимостей, поделитесь пожалуйста
Как цмэйком управлять бинарными зависимостями, их кэшированием, версиями и тд? Скачивать это хорошо, но ведь множество библиотек мы подключаем уже собранными, в т.ч. локальные внутри проекта, как этим всем управлять?
Я не понял для чего мне dev контейнеры в этой задаче. Делая свой Dockerfile я имею полный контроль над этим образом, его содержимым, конфиг файлах и тд. Местами иногда приходилось "хакать" - например ставить сурс-листы для пакетов из более высоких версий дистрибутива linux и докачивать только определенные пакеты определенных версий. dev контейнер описывается декларативно через жисон и как будто в этом всем меньше контроля над происходящим.
А какие преимущества?
зацепила фраза
Безальтернативное утверждение, которое в общем случае подвергается сомнению. Если бы формулировка была что-то вроде:
то и докопаться было бы не до чего =)
Инлайнинг, оптимизация хвостовой рекурсии?
Чем это лучше, чем clang libtool (примерно так)? В общем инструментарий фронтенда компилятора кланг. Там на входе может быть не какой-то специальный dsl который нужно изучить/понимать, а вполне себе c++ код. Там вполне себе документированные и понятные инструменты для работы с AST C++.
И этот инструмент гарантированно работает, т.к. является неотъемлемой частью полного цикла работы компилятора, ну т.е. серьезные требования к работоспособности и корректности
Как следствие, clang будет поддерживать код из нужного стандарта c++. Например, пришла бы вам в голову идея поддержать ключевое слово trivially_relocatable_if_eligible, которое скоро https://habr.com/ru/companies/yandex/articles/882518/ станет частью разбора структуры/класса и между вашими name и parents встроится? Пример только для иллюстрации того что всегда поддерживать актуальный разбор AST c++ это быть в роли догоняющего за компиляторами
Однобуквенность. Вопрос привычки, такая практика. Их всего 2 таких алиаса, как самые часто-используемые, понятно что если бы их было 10, это уже совсем другой разговор, но эти даже интуитивно понятные
В примере с ShapeUptr угловых скобок было бы на одну пару меньше, они не то чтобы куда-то испарятся все. Но вместе с тем появился и дополнительный символ, его нужно написать. Не сделать forward decl с оригинальным классом, чтобы использовать этот юзинг (т.к. он как правило рядом с определением класса), а в моем примере можно в U<MyClass> пихать такую декларацию при определённых условиях. Ну и то что говорил про поиск по символу
Про замену типа указателя. Для меня выглядит как исключительное событие и думаю писал полный тип хитрого указателя по месту, чтобы не вводить в заблуждение пользователя этого символа на предмет что под капотом. Вообще пример странный, не могу представить себе такое.
Приведу шутошную аналогию, это не аргумент и не всерьез:
Давайте в проекте определим и будем использовать
Мало ли нам понадобится массово подменить целые числа, а имя Int все равно останется на месте
Сделали в проекте такие глобальные юзинги (в условном common/core.h) :
И также SH с шаредптр
Читаемость не теряется и не нужно руками делать на каждый такой класс отдельный юзинг.
Плюс такого подхода, что мы всегда видим оригинальный класс и например поиск по символу нужно делать не для каждого такого юзинга, а только для оригинального класса
Девайс очень модный и молодежный, выглядит вкусно. Сам бы точно не купил, по причинам описанным выше @engine9
Рекламные материалы тоже выглядят отлично, дам им немного критики:
https://busy.bar/ при скроллинге на десктопе очень заметно фризит (на заметку)
Самый первый блок с демонстрационным примером, подписанный как Show you’re BUSY - ИМХО видео совсем не отражает кейс использования. Текущий порядок:
Коробка неактивна
подходят с вопросом
коробка демонстративно активируется
раздраженный коллега уходит
На мой взгляд ценность коробки в том, чтобы заранее ее активировать, если знаешь что будешь занят ближайшее время, тогда коллега на подходе к тебе увидит это и будет иметь ввиду, когда ему подойти, так что я сделал бы такую сценку:
Коробка активируется
Таймлапсом проходит 5 минут
подходят с вопросом, но видят коробку, разворачиваются
Таймлапсом проходит все время занятости -> занятость снимается
снова подходят с вопросом, на этот раз коллега получит ответ
ИМХО стек это не структура данных, а некий намеренно ограниченный по операциям интерфейс взаимодействия со структурой данных
С какой структурой данных? Это вопрос, т.к. стек можно реализовать и на базе массива, и на связном списке, на каких-то промежуточных типа deque, ...
Это конечно дискуссионный вопрос, тут смотря как трактовать термины. Но если бы мне предложили выбрать из предложенных элементов, то что меньше всего относится к структурам данных:
массив,
связный список,
хэш-таблица,
стек,
ассоциативный массив на красно-черном дереве
То это был бы стек
Эх, магии не случилось, и тут нужно заклинание с трех букв