Настройка визуального представления сигналов при моделировании в среде ModelSim (часть 1)
Добрый день читателям Хабра! Меня зовут Алексей, я занимаюсь работой с ПЛИС (FPGA) уже более 15 лет. Хабр читаю давно, но статьи здесь никогда не писал. В общем решил попробовать. Не знаю, насколько на Хабре интересны темы, связанные с ПЛИС? Но всё же, вдруг кому-то эта небольшая статья будет полезна.
Недавно столкнулся с интересным багом в Next.js. Если на странице not-found делать навигацию через router.push(pathname), теряются все переменные окружения, которые мы инициализируем через библиотеку next-runtime-env (значение window.__ENV становится undefined).
В проекте мы используем next-runtime-env, так как придерживаемся подхода Build once, deploy many — это позволяет держать один Docker-образ, в который при запуске прокидываются нужные переменные окружения. Next.js из коробки не поддерживает такое поведение, ведь он хочет собирать env-переменные на этапе сборки приложения.
Баг проявился на not-found странице, где у нас есть кнопка, позволяющая создать элемент в один клик, если что-то не найдено. Этот же компонент кнопки используется и на других страницах, и вот что интересно: на остальных страницах router.push(pathname) работает корректно, а на not-found — нет.
Сначала я подумал, что проблема кроется в next-runtime-env. Наверное, библиотека переопределяется при обновлении страницы, потому что скрипт, устанавливающий переменные в window.__ENV, размещён в root layout. Я также пробовал версионировать Next.js, предполагая, что баг связан с определёнными версиями фреймворка, но это не дало результатов. В итоге, временным решением стало использование window.location.href, что предотвращало рефреш страницы и помогало сохранить переменные.
Однако на этом история не закончилась.
Привет, Хабр! Меня зовут Роман Вернин, я разработчик систем на кристалле в компании Аквариус. Вместе с коллегами мы разрабатываем микросхемы ASIC. В этой статье я хотел бы поделиться опытом, как можно использовать отладочное средство ПЛИС от фирмы Intel для тестирования, настройки или исследования устройств и стендовых систем.
int safeDiv(int a, int b) {
if (b == 0)
throw Div0(); // Исключения передаются особым образом
return a / b; // Теперь-то всё абсолютно безопасно, ведь так?
}(res, err), а Rust возвращает Result<T, E> — тип-сумму результата и ошибки.
Pinterest поддерживает формирование отчётов по метрикам рекламных объявлений внешних рекламодателей и расчёт рекламных бюджетов в реальном времени. Всё это основано на потоковых конвейерах обработки данных, созданных с помощью на Apache Flink. Доступность заданий (job) Flink для пользователей находится на уровне 99-го перцентиля. Но время от времени некоторые задачи (task) «валятся» под ударами неприятных ошибок, вызванных утечками прямой памяти (Out-Of-Memory, OOM), возникающими сразу в нескольких операторах. Выглядит это примерно так:
Разбирался я в низкоуровневой работе камер iPhone, и дошёл до FaceID — системы распознавания лиц, используемой Apple для разблокировки смартфона. И наткнулся внутри на интересную вещь: чип, единственное предназначение которого в том, чтобы вывести из строя FaceID. Навсегда.
О том, как в iPhone вообще работает FaceID, где там этот чип стоит, что именно он делает, зачем его сделали таким злым, и как в ремонте справляются с этой напастью — под катом!
Мой провайдер помимо замедления (читай полная блокировка) YouTube так-же стали блокировать соединения с моими рабочими VPN. Работодатель не очень любит, когда на встречах на вопрос о прогрессе, я неделю отвечаю, что у меня не работает VPN! Своими действиями, мой провайдер сам меня подтолкнул к поиску обходных путей.
Сразу скажу, обходной путь придумал не сам, мне его подсказал автор проекта zapret, а точнее его комментарий, более того, я использую его проект, чтоб смотреть нормально YouTube. Спасибо огромное!
Добавлю, я использую nftables и nfqws, если этот вариант работает у меня — это не значит, что оно заработает и у вас! Возможно, вам придётся изменить некоторые параметры.
DispatchQueue.main.async, когда видели отчёт о сбое.
Недавно я получил по почте от Сэма Джонсона этот вопрос. Вот слегка отредактированное письмо Сэма:
«Возьмём для примера этот код в локальной области видимости функции:
int a;
a = 5;
Многие люди считают, что инициализация происходит в строке 1, потому что веб-сайты наподобие cppreference дают такое определение: "Инициализация переменной предоставляет его начальное значение на момент создания".
Однако я убеждён, что инициализация происходит в строке 2, потому что [в разных хороших книгах по C++] инициализация определяется как первое существенное значение, попадающее в переменную.
Можете ли вы сказать, какая строка считается инициализацией?»
Отличный вопрос. На Cppreference написано правильно, и для всех классовых типов ответ прост: объект инициализируется в строке 1 вызовом его стандартного конструктора.
Но (а вы ведь знали, что будет «но») для локального объекта фундаментального встроенного типа наподобие int ответ будет... чуть более сложным. И именно поэтому Сэм задал этот вопрос, ведь он знает, что язык достаточно свободно обращается с инициализацией таких локальных объектов по историческим причинам, имевшим в то время смысл.
Короткий ответ: вполне допустимо говорить, что переменная получает своё исходное значение в строке 2. Но заметьте, что я намеренно не сказал «Объект инициализируется в строке 2», к тому же и код, и этот ответ обходят молчанием более важный вопрос: «Ну ладно, а что, если код между строками 1 и 2 попробует считать значение объекта?»
В этом тексте вы узнаете, что общего между I2S трансивером и оладьями.
Да... Именно так. А также зачем программисту микроконтроллеров конвейеры и цифровые фильтры.
В тексте изложено про то, как источать звук при помощи I2S + DMA.
"Как будто у Unreal и Unity родился ребёнок" — такое трогательное описание дали этому движку в GameDev-сообществе. Эта фраза не только мило звучит, но и точно передаёт его суть, ведь движок действительно задумывался как нечто среднее между Unity Engine и Unreal Engine.
Одним из ключевых аспектов успешной разработки является эффективная отладка кода.
Статья посвящена настройке и использованию PhpStorm, Xdebug и Docker для отладки PHP-скриптов в Docker-контейнере. Статья предлагает актуальную информацию (на момент написания) и оформлена в виде подробнейшего пошагового туториала. Информация действительна для ОС Windows. В других ОС возможны варианты.
Цель статьи — не просто создать пошаговой конспект настроек, а объяснить, как всё это взаимодействует. Это поможет избежать затруднений при изменении интерфейса IDE в будущем. Возможно, статья выглядит слишком педантичной. Но гуру всегда смогут прочесть её по диагонали, зато новички в этой теме найдут для себя много полезного.
502 Bad Gateway — загадки, которую предстояло разрешить.
В современном мире, где обучение становится все более сложным, а тесты — настоящим испытанием для студентов и учеников, а также для начинающих специалистов, которые работают в компаниях, где сильно развито грейдирование, мы постоянно ищем эффективные способы облегчить процесс получения знаний. Специально для вас я разбираю мощный плагин для браузера, который использует возможности GPT для решения тестов на любые темы. Этот не инновационный инструмент, но таких примеров разбора я в интернете не нашёл. В этой статье мы расскажем, как работает этот плагин, какие преимущества он предлагает и как вы можете использовать его, чтобы достигать результатов на 100%. Давайте разберемся, как сделать вашу учебу проще и эффективнее с помощью этой уникальной технологии!
Ни один процесс разработки программы не проходит без отладки. Современные IDE обеспечивают программиста встроенным отладчиком. Однако бывают ситуации, когда использование IDE для отладки избыточно или невозможно, и тогда на помощь приходят автономные отладчики, один из которых — x64dbg.
Любые программные системы включают в себя нужные и не очень нужные пакеты. Получается огромный объём кода (для одного несложного сайта npm list -a выдаёт список из 4256 зависимостей). А так как «весь код — это ваш код», то такие зависимости надо тестировать. И регулятор требует, да и просто собственные продукты хочется защитить от вторжений, утечек и других неприятностей.
Critique и Gerrit
У Google есть два собственных инструмента для ревью кода: Critique, используемый большинством инженеров, и Gerrit, — опенсорсный, который продолжают применять в публичных проектах.
(Вы можете сами поэкспериментировать с Gerrit в опенсорсных репозиториях Chromium и Android.)
Дэшборды
Когда инженеры логинятся с утра или когда устраивают перерыв для ревью пул-реквестов, внутри Google называемых change list, или CL, и в Critique, и в Gerrit они работают с дэшбордами, в которых можно легко вкратце просмотреть все актуальные изменения (это похоже на окно пул-реквестов репозитория GitHub, только более сложное и информационно насыщенное).
В дэшборде Gerrit есть единичный поиск, извлекающий такую информацию, как размер изменения и более подробные сведения о статусе CL (три столбца справа).