Отладка *

Перевод поста Стивена Вольфрама (Stephen Wolfram) «Scientific Bug Hunting in the Cloud: An Unexpected CEO Adventure».
Выражаю огромную благодарность Кириллу Гузенко за помощь в переводе.

Wolfram Cloud должен быть совершенным

Wolfram Cloud в самом скором времени выйдет из стадии бета-тестирования, в данный момент я трачу очень много времени на то, чтобы сделать эту систему как можно лучше (и, стоит заметить, получается действительно здорово!). В основном я занимаюсь высокоуровневыми функциями и стратегией. Но мне нравится контролировать процесс на всех уровнях, ведь, как CEO, я полностью отвечаю за все, что происходит в моей компании. И вот в начале марта я оказался погруженным в то, о чём никак не мог догадываться ранее.

Собственно, вот о чем речь. Как серьезная производственная система, которую многие люди будут использовать в том числе и для бизнеса, Wolfram Cloud должен работать как можно быстрее. Показатели говорили о том, что скорость достаточно хороша, но чисто субъективно чувствовалось, что что-то не так. Иногда всё было действительно быстро, но иногда казалось, что все работает слишком медленно.

В нашей команде есть отличные программисты, однако шли месяцы, и какие-бы то ни было изменений не ощущалось. А тем временем мы успели выпустить Wolfram Data Drop (см. статью на Хабрахабре «Wolfram Data Drop — новый сервис Wolfram Research»). Так что я подумал, почему бы мне самому не провести несколько тестов, возможно, и собрать немного информации в наш новый Wolfram Data Drop?

Существенное преимущество Wolfram Language заключается в том, насколько он хорош для занятых людей: даже если у Вас есть время только чтобы напечатать всего несколько строк кода (см. статью на Хабрахабре "Компания Wolfram Research открыла сервис Tweet-a-Program: интересных программ на языке Wolfram Language, длина которых не превышает 140 символов"), Вы сможете получить что-то действительно полезное. И, в данном случае, мне достаточно было просмотреть три строчки кода, чтобы найти проблему.

Сперва я развернул web API для простой программы на Wolfram Language в Wolfram Cloud:

Ребята из компании Mailgun презентовали новый кроссплатформенный дебаггер для Go, который использует оригинальную технологию, в корне отличающуюся от стандартных подходов. Забегая наперед — с помощью Gopherjs этот дебаггер работает даже в браузере.

В прошлой статье нам удалось получить звук, но это очень дорого нам далось. Во первых, мы разогнали контроллер до максимальной скорости. А во вторых, кроме генерирования звука контроллер ничего не может, так как большая часть процессорного времени занята постоянным обновлением значения ЦАП-а. Не хорошо это. Именно сейчас остро стоит вопрос об использовании ДМА.

DMA, или Direct Memory Access – технология прямого доступа к памяти, минуя центральный процессор.

— (с) отсюда.

Вступление

В предыдущей статье мы поговорили о настройке тактовой частоты микроконтроллера. Сейчас мне хотелось бы рассмотреть варианты работы со звуком: его генерирование и воспроизведение. По началу мне хотелось написать одну большую статью, в которой было бы рассмотрено все. От генерации прямоугольных импульсов до воспроизведения FLAC с microSD карты. Но статья получилось просто гигантской. Так что я решил разбить ее на несколько статьей поменьше. В каждой из которых я разбираю по одному периферийному модулю.

Общее представление о системе тактирования

В прошлой статье мы научились создавать стабильные задержки с помощью простого таймера SysTick, а так же немного окунулись в механизм работы прерываний. Тогда мы принимали как постулат то, что тактируя таймер от источника HCLK – мы получаем 8 Мгц. Теперь настало время разобраться, откуда эти цифры.

Вступление

В предыдущей статье мы помигали светодиодом, но сделали это не совсем правильно. Дело в том, что в качестве задержки мы использовали пустой цикл, который под каждый временной интервал приходится подбирать. Такой способ так же не подходит, когда нам нужны точные временные интервалы. Для решения данной проблемы в нашем микроконтроллере имеются сразу три полноценных таймера и один системный. Для начала поставим небольшую подзадачу. Нам нужно получить мигание светодиодом с интервалом в одну секунду. Задача очень простая и для этого нам вполне хватит системного таймера. Из-за своей легкости он идеально подходит для такого рода задач. Рассмотрим его по подробнее.

Данная статья является продолжением предыдущей, вводной статьи, в которой речь шла о мотивации и истории создания терминала/сниффера IO Ninja, и было немного рассказано про встроенные возможности нашего продукта. Продолжим рассказ о том, что доступно «из коробки», но с более практическим уклоном.

IO Ninja изначально задумывалась как утилита типа «всё-в-одном», и в комплект поставки входит большое количество встроеных плагинов для работы со всеразличными транспортами в разных режимах. Однако вместо сухого перечисления списка плагинов и их возможностей я решил продемонстрировать маленькую выборку задач из жизни, с которыми в нашей компании сталкивались на практике, и с которыми общеизвестные терминалы и мониторы справляются хуже, чем IO Ninja (а чаще не справляются вообще).

Вступление

В прошлой статье я поделился личными впечатлениями о полученном мною наборе и запрограммировал контроллер демонстрацонным проектом с помощью MT-LINK (так же был предоставлен). Теперь, когда мы детально рассмотрели весь комплект, настало время начать его осваивать.
Для нетерпеливых — итог.

Введение

В преддверии нового года я, как и многие россияне, активно следил за состоянием зарубежной валюты. Но не просто из-за собственного интереса, а из-за того, что на тот момент заканчивал свое устройство, которое требовалось показать на школьной и районной конференции. Так как в названии работы было такое слово как «бюджетное», то приходилось в презентации указывать стоимость каждого компонента, вплоть до резисторов и перемычек. Изначально, когда доллар стоил порядка 30 рублей, устройство и вправду было бюджетным. Как при домашней сборке, так и при конвейерной. Но когда цена доллара перевалила за 100 рублей, я решил, нужно искать альтернативу зарубежным компонентам.

К этому моменту уже как несколько месяцев изучал работу микроконтроллеров STM32F100 и STM32F103, применяя их на практике в презентационном устройстве. От таких гигантов, как STM32F429, мне пришлось отказаться. Так как стоимость в 1800 рублей за корпус является заоблачной для «бюджетного» устройства, функционал которого только начал превосходить возможности AVR Atmega32.

Добрый день, хаброжители,

Статьи посвящены тому, как я справляюсь с поддержкой приложений, которые прошли не через одну версии, писались в разное время и разными людьми. Надеюсь, они помогут и другим iOS разработчикам.

1. Облегчаем поддержку iOS приложения. Часть 1 — не отрываясь от Xcode
2. Облегчаем поддержку iOS приложения. Часть 2 — локация и сеть
3. Облегчаем поддержку iOS приложения. Часть 3 — падение и логи

В первой статье я поделился своим опытом работы с трудно воспроизводимыми багами. В этой статье я расскажу, как можно поступить с багами, которые связаны с сетью или локацией. Тех, кого интересует эта тема, прошу под кат.

Добрый день. Я хотел бы рассказать о том, как можно облегчить поддержку iOS приложений.

1. Облегчаем поддержку iOS приложения. Часть 1 — не отрываясь от Xcode
2. Облегчаем поддержку iOS приложения. Часть 2 — локация и сеть
3. Облегчаем поддержку iOS приложения. Часть 3 — падение и логи

Всем, кто создавал iOS приложение, и оно доходило хотя бы до открытого β-тестирования, скорее всего, знакома фраза: “Я тут поигрался с приложением и вот что получилось...”. И вот после этой фразы вы могли провести несколько часов, пытаясь понять, как же «это» получилось.

Если вам знакома эта ситуация, или хочется узнать о том, как спасти себя от такого в будущем — прошу под кат.

Приветствую вас, уважаемые хабровчане!

Сегодня я хотел начать рассказ об одном интересном продукте представляемой мной на хабре компании Tibbo. Продукт этот может оказаться полезен широкому кругу IT-профессионалов, включая системных администраторов, специалистов по информационной безопасности, и, наконец, простых разработчиков, которым нет-нет, да и приходится программировать общение с устройствами и другой низкоуровневый ввод/вывод.

Разговор пойдёт про программируемый терминал/сниффер IO Ninja (здесь и далее я буду опускать слово «эмулятор» и говорить просто «терминал»). Подозреваю, что само определение «терминал/сниффер» может выглядеть достаточно непривычно, если не сказать странно. Поэтому начнём с истории возникновения IO Ninja.

12345

На Хабре уже неоднократно рассказывали о таком мощном и удобном средстве мониторинга HTTP-трафика, как Fiddler. Все имеющиеся статьи, однако, рассказывают о встроенных фичах программы, не акцентируя внимания на возможностях её расширения, которых существует целых две: с помощью встроенного языка FiddlerScript и с помощью написания .NET-плагинов. В этой статье мы рассмотрим и то, и другое, а чтобы было интереснее — используем их для решения вполне практической задачи, о которой я писал в своей прошлой статье (подмене битых ссылок на картинки в статьях на Хабре на рабочие).

Итак, давайте вспомним для начала, чем закончилась прошлая статья: мы получили список нерабочих ссылок на картинки и соответствующих им рабочих ссылок на веб-архиве. Теперь нужно отдать их браузеру и для этого мы напишем расширения к Fiddler (одно на FiddlerScript и одно на .NET). Обратите внимание на удобства полученного решения: да, нам нужно будет запустить Fiddler, но зато битые ссылки будут подменяться на рабочие независимо от домена статьи (хабр, гиктаймс или мегамозг), независимо от используемого браузера (лишь бы имел поддержку прокси) и даже мобильные устройства можно будет настроить на использование установленного на компьютере Fiddler в качестве прокси.

Как всем нам известно, процесс отладки это такая вещь, важность которой трудно переоценить. Причем, понимая важность таких методов как дебажное моргание светодиодами и вывод дебажных сообщений в порт, я остаюсь при мнении, что эффективнее пошаговой отладки пока ничего не придумано. Однако, задача пошаговой отладки становится не такой тривиальной в случае программирования под Linux на встраиваемых системах (таких как rasbery pi, virt2real или промышленные процессорные модули).

Данную задачу в Linux призвана решать стандартная связка программ GDB и gdbserver. Идея в том, что пишешь на компе программу (host в терминологии GDB), компилируешь её и заливаешь на целевое устройство (target). Далее запускаешь на целевом устройстве (target) отлаживаемый файл и gdbserver, а на хосте GDB и вперед.

Данная заметка может оказаться полезной для людей, который пишут bare-metal код и используют ThreadX в своих задачах (по собственному выбору или по навязыванию SDK). Проблема в том, что что бы эффективно отлаживать код под ThreadX или другую многопоточную операционную систему нужно иметь возможность видеть эти самые потоки, иметь возможность посмотреть стек-трейс, состояние регистров для каждого потока.

OpenOCD (Open On Chip Debugger) заявляет поддержку ThreadX, но не сильно явно оговаривает её широту. А штатно, на момент написания статьи, в версии 0.8.0, это всего два ядра: Cortex M3 и Cortex R4. Мне же, волею судеб, пришлось работать с чипом Cypress FX3 который построен на базе ядра ARM926E-JS.

Под катом рассмотрим что нужно сделать, что бы добавить поддержку вашей версии ThreadX для вашего CPU. Акцент делается на ARM, но, чисто теоретически, вполне может подойти и для других процессоров. Кроме того, рассматривается случай, когда доступа к исходникам ThreadX нет и не предвидится.

Уважаемый читатель,
в своем проекте ты наверняка написал инструмент логирования и с успехом применяешь его для анализа трудно-диагностируемых багов. Но ты всегда сталкивался с ситуацией:

• когда запись в файл — консоль драматически сказывалось на воспроизодимости бага;
• когда мульти(процессорное/поточное) приложение часто обращается к драйверу и ты не можешь сопоставить временные метки и потоки;
• когда баг воспроизводится на стороне кастомера, сеанс teamviewer бесполезен, да к тому же версия с отладочными символами private;
• когда системное приложение падает до того, как система успеет скинуть логирование на диск;
• или когда макрос для логирования выглядит в лучшем случае как

  #define TraceDbg(format, ...) \
      printf( "(p %d, t %d) - (%s,%d) %s(): " format, GetCurrentProcessId(), GetCurrentThreadId(), __FILE__, __LINE__,__FUNCTION__, __VA_ARGS__ );
  

• когда придумываешь очередной способ вывести на экран ipaddr или UUID

В статье я представлю быстрый, надежный и универсальный для отладки с минимальным оверхедом инструмент диагностики, предлагаемой MS для системных приложений — WPP, рассмотренный частично в публикации «EventTrace for Windows. Высокоскоростная передача отладочных сообщений драйвера по сети».

Не все знают, что в InterSystems Caché есть встроенный инструмент для профилирования кода, который называется Caché Monitor.

Основное его назначение (очевидно) – сбор статистики по исполняющимся в Caché программам. Он может предоставлять как общую статистику по всем программам, так и детализированную Line-by-Line статистику по каждой отдельной программе.

Доброго времени суток,

В этой статье я хочу рассказать о создании расширения для Visual Studio, которое помогает визуализировать сложные пользовательские классы в процессе отладки приложения.

Предыстория

В своем проекте мы активно используем отечественное геометрическое ядро C3D Kernel. Эта библиотека предоставляет большое количество классов для работы с кривыми, телами, поверхностями и т.п. Эти классы имеют сложную структуру и в процессе отладки приложения, используя стандартные средства визуализации Visual Studio, трудно понять, какая, например, поверхность хранится в конкретной переменной. А при отладке сложных алгоритмов очень важно понимать, что происходит с объектом на каждом шаге алгоритма.

Вчера мне пришло уведомление о том, что открыто beta-тестирование профайлера от SensioLabs - blackfire.io