A Programmer’s Love Song

Неприємна помилка в Doxygen 1.8.11

Зазвичай я не поспішаю переповзати на нову версію Ubuntu і досі сиджу в Ubuntu Mate 16.04. І я не один такий, на роботі також 16.04 (тільки не Mate, а «звичайна», зі стільницею Unity).
І от на роботі ж і виловив помилку в Doxygen, який в убунті 16.04 стоїть версії 1.8.11. Заманулося отримати для перегляду дерева викликів, CALL_GRAPH і CALLER_GRAPH, щоб швидше ознайомитися зі структурою чужого коду. А отримав страшну кашу з довгими циклічними петлями викликів. Виявилося, що всі функції, прототипи яких описано в .h-файлі безпосередньо під inline-функцією, вважаються такими, що викликані з цієї inline-функції.
Мінімальний приклад, doxy-bug.{h,c}:

static inline foo(void) { }

void moo(void);
#include <doxy-bug.h>

void moo(void)
{
    foo();
}

Doxygen 1.8.11 генерує для inline-функції foo() такий граф викликів

Wrong call graph (doxygen 1.8.11)

а для moo() взагалі отакий:
Wrong call graph (doxygen 1.8.11)

Уявляєте, що я отримав на дереві з кількох каталогів і сотень функцій, а в h-файлах під inline-функцією може бути описано декілька прототипів, всі з яких стають «викликаними» з неї? Оскільки всі ці функції викликали ще у глибину на декілька рівнів статичні функції всередині своїх файлів, а вже ті викликали ці inline-операції, утворювалося багато довгих петель.

На щастя, у свіжій версії Doxygen 1.8.15 цю помилку виправлено. Все красиво:
Correct call graph (doxygen 1.8.15)

Переставлю тепер doxygen і на роботі, буде легше.

Linux Kernel під Creedence Clearwater Revival

Сьогодні над CLRS сиділося під Creedence Clearwater Revival.
Але ж у голові паралельно й інше крутиться, то вийшло:

Oh Working Queue, oh Waiting Queue
And IRQ, how I love you, all IRQ
I like the way you walk
I like the way you talk
I like all your spinlocks
 but hate if you deadlock, All Linux *Q*

Well, say that you’ll be hard
Well, say that you’ll be soft
Well, say that you’ll work fine
 and never give me pain, oh IRQ

Well, say that you’ll be mine
Well, say that you’ll be mine,
Well, say that you’ll works fine,
 works all the time, my Working Queue

Oh Working Queue, oh Waiting Queue
And IRQ, how I love you, all IRQ

I like the fast top half
I like the bottom half
I like the user space
I like the user space, oh Working Queue

Oh Working Queue, oh Waiting Queue
And IRQ, how I love you, all IRQ

© моє

arm-eabi-ld buffer overflow

або помилка повертається.

Лінкер від gcc-linaro-7.2.1-2017.11-x86_64_arm-eabi (binutils 2.28), має ту ж саму біду, що й avr-ld.
А саме *** buffer overflow detected ***, переповнення буфера sprintf (і знову лаюся — чому використано не snprintf ?!)

p.s. «родич» gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf — the same, тобто те саме.
p.p.s. Arduino навіть для лінукса тягне всі компілятори з собою. Там не увімкнуто локалізацію, тому цієї проблеми нема. У старенького «рідного» в убунті-16.04 arm-none-eabi- теж. Все залежить від того, як збирався лінкер.

Теорема, протилежна оберненій

Оскільки я вже згадав у попередньому дописові про третє видання книжки Кормена і компанії «Вступ до алгоритмів» (так звану CLRS), то напишу і тут про ненароком помічену помилку в російському перекладі книжки.

Працюючи з текстом задачі 8-7 («Лема сортування 0-1 і сортування стовпцями», сторінка 208 оригіналу) вирішив зазирнути в російський переклад, як там цю лему назвали, і тут же око вихопило дуже некоректний текст.

У перекладі російською (сторінка 238) є такі слова: «докажем 0-1-лемму сортировки путём доказательства обратной к ней». Але так не буває. Ніколи-ніколи-ніколи доведення оберненого твердження не доводить пряме. Якщо істинне як пряме твердження, так і обернене, то частини тверджень еквівалентні, тобто (А⇒Б ∧ Б⇒А) ⇒ (А⇔Б). Але шляхом доведення Б⇒А неможливо довести А⇒Б.

І в оригіналі було: «prove the 0-1 sorting lemma by proving its contrapositive»

Контрапозитивне твердження (протиставлення) це протилежне оберненому (або обернене протилежному, що те ж саме), тобто (А⇒Б) ⇔ (¬Б⇒¬А) і саме ¬Б⇒¬А можна довести для доведення А⇒Б (що і зроблено далі по тексту).

Цікаво, скільки ще таких неточностей у цьому перекладі з англійської на російську? І зрозуміло, чому я проти таких подвійних перекладів навіть у «технічних» текстах.

Scratch і двійкове дерево пошуку

З різних міркувань вирішив прослухати курс CS50 на «Прометеусі» (саме українською).
Перший тиждень там Scratch. Завдання без оцінки, просто щоб погралися, хоча деякі формальні вимоги є (не менше двох спрайтів і трьох скриптів чи щось таке — насправді дуже легкі обмеження).
Ну я й вирішив таки побавитися. Озброївся CLRS і зробив побудову та центрований обхід двійкового дерева пошуку з випадкової перестановки чисел 1–10:

Враження від Scratch » » »

Пінгвінятко Лінукс

Пінгвінятко Лінукс, яке вишивалося донькою, губилося, вишивалося наново, потім десь лежало, потім знайшлося — нарешті отримало рамку і постійне місце на стіні.

Таки економимо резистори?

Різке подорожчання пасивних компонентів — то, я так розумію, мова про великий опт, бо у роздріб ціни виросли набагато більше. В умовах законтрактованості партій практично на рік вперед «трошки» і «прямо зараз» коштує грошей кожне окремо.

Допис про економію резисторів отримав нове звучання?

Універсальний gcc-avr.mak

У зв’язку з описаною раніше помилкою avr-ld та методом боротьби з нею мене спитали про той «універсальний» файл gcc-avr.mak, яким я користуюся у всіх проектах. «Нічого воєнного», це просто файл, у який зібрано команди, які без змін переходили б з проекту в проект шляхом копіювання (і наступного редагування) Makefile від попереднього проекту 😉

Тепер файл gcc-avr.mak підключається до Makefile проекту командою include. Так само, як і подібний мейк-файл для роботи з програматором avreal — avreal.mak. Файл для проекту тепер короткий, містить лише головні налаштування. Легше знайти потрібне, важче поламати те, що вже перевірене.

Повернімося тепер до цього універсального мейк-файлу для avr-gcc і до згаданої помилки в avr-ld.

Окрім іншого, на початку gcc-avr.mak здійснюється налаштування шляхів до програм, використовуваних при компіляції. Виглядає це так (нумерація рядків відповідає файлу, доданому у прикріплений архів).

40
41
42
43
44
45
46
47
48
49
# Set default toolchain prefix if it does not defind in environment or project makefile
TOOL ?= avr-

# Set tool names
CC  := $(TOOL)gcc
AS  := $(TOOL)gcc -x assembler-with-cpp
BIN := $(TOOL)objcopy
OBJCOPY := $(TOOL)objcopy
OBJDUMP := $(TOOL)objdump
SIZE    := $(TOOL)size

Читати далі » » »

Attached Files:

Випалювач з ЧПК

Ось дивіться, яку цікавезну штуку я надибав — випалювач з числовим програмним керуванням.

Arduino Nano, трохи іншої електроніки плюс механіка; «великий» комп’ютер або OrangePi Zero. Прошивка ардуінки як ардуінівський скетч і зроблена. А ще Qt-шні програми — для OrangePi і для Linux/Windows десктопів.

Опис у блозі автора (там і посилання на GitHub):

І все це там, де найближча «Нова пошта» за 25 кілометрів. Але у автора «Випалювача» девіз — «Зробити можна все, головне мати терпіння й бажання». І у нього є і перше, і друге.

[flagcounter image]