Зачем оно нужно, если есть юниттестирование?

Аве!

Не, ну с такими набросами долго не протянешь.

Поддержка debuginfod, HTTP-сервера для распространения ELF/DWARF отладочной информации

Даже до GDB проклятый Пёттеринг дотянулся!

Различные исправления и улучшения режима TUI

Надо потестировать, но…

Различные улучшения API Python

… может и не надо TUI, ведь GDB Dashboard (кто не знает — .gdbinit на Python) и так уже предоставляет крутой текстовый интерфейс, а с улучшением API можно развивать и далее.

https://github.com/cyrus-and/gdb-dashboard

GDBserver теперь поддерживает следующие платформы:

RISC-V GNU/Linux

Хорошо, близится «х86-капец». Вот только живых образцов этой платформы я ещё не видел.

Вот если бы этот дэшборд можно было в отдельном пэйне в тмуксе поднять было бы топчик.

Такое ощущение, что если бы ты мог, ты бы Поттерингу бы детей рожал. По крайней мере лижешь ты его активней некуда.

GDB поддерживает отладку на более десятка более чем десятке различных архитектур

У меня тоже на этом моменте мозг сломался. Думаю читабельней будет:

на более чем десяти архитектурах

на более чем десяти архитектурах

Это тоже ломает мозг. Гораздо лучше будет вместо «оригинального»

поддерживает отладку на более десятка различных архитектур

Написать вот так:

поддерживает отладку более чем на десятке различных архитектур.

или же так:

поддерживает отладку более чем на десяти различных архитектурах.

«х86-капец»

(оффтоп) пока что у x86 побольше FLOPS/W/$ чем у армов и риск-файвов. Сам мечтаю приобрести армовый нетбук, чтоб держал несколько часов (а то и неделю, в состоянии сна), но увы - стоят они (хромбуки например) дороже, чем аналогичный говноноут на Pentium N5000 - который, между прочем, мощнее чем i5 в моем предыдущем ноуте, и с нормальной поддержкой линуха.
Да и огороженность «экосистемы» зашкаливает, нет бы стандартный UEFI запилить.
А что уж говорить про RISC-V, на котором пока что одни одноплатники и эмбеддед.

зачем юниттестирование? ты что не можешь сразу норм написать? :)

Вот если бы этот дэшборд можно было в отдельном пэйне в тмуксе поднять

https://github.com/cyrus-and/gdb-dashboard/wiki/Use-multiple-terminals

Научите пользоваться.

Чё-т вы какую-то ерунду обсуждаете.

У меня важный вопрос:

Почему на логотипе сдувшийся OpenBSD?

Ага, спасибо, я помню то-ли gef то-ли ещё одна из этих историй так умела.

Кто-то один из них, скорее всего gef как-то глючат с rr, поэтому я как-то всё равно подзабил на эти дэшборды. Это в основном конечно для любителей реверса истории имхо.

Похоже, что этому проекту только помогли в этом релизе:

gdb.register_window_type can be used to implement new TUI windows in Python.

Их текущая реализация мне не особо нравится.

Зачем нужно дыхание, если есть еда?

Почему на логотипе сдувшийся OpenBSD

Не сдувшийся, а выпотрошенный.

забористая у тебя, какой сорт?

Логотип зачётный. Ещё бы белую подложку подальше под чёрный загнали, чтобы не было видно этой мразотной белой полоски вокруг — и вообще было бы замечательно.

Есть кто на их мейллист подписанный? Отправьте им пожалуйста поправленную версию логотипа: Archer Fish.svg. Было. Стало. Исходник.

Спасибо.

Ada не надо отлаживать, Ada отладит тебя сам.

Как раз наоборот, благодаря юнит тестированию я смогу сразу все нормально написать.

Без использования какого то консольного отладчика.

Зачем оно нужно, если есть юниттестирование?

Зачем оно нужно, когда есть printf?

Кстати да, отладочную печать никто не отменял

В последний раз я пользовался отладчиком в турбопаскале в 99м году.

В других более современных IDE он оказался не нужен.

Давай поговорим об этом.

Ах если бы, ах если бы Не жизнь была, а песня бы!!

"Я коронован, рядом Забава,

Новые земли, новая слава,

Новые деньги, новые связи -

Вот оно счастье! В князи из грязи!"

В Студии вестимо не нужен. А в ви очень даже)

я смогу сразу все нормально написать

И часто ты можешь всё сразу нормально?

Поддержка отладки 32-битных Windows программ с использованием 64-битной Windows GDB

Вот эту фичу надо потестить.

Э.. Вообще то, юнит тесты созданы для того, чтобы все было «нормально».

Если при этом возникает необходимость отладки, то это уже ненормально.

Почитай основы теории тестирования.

Про тесты всё верно. Вот только когда тест не проходит - тут как раз нужен отладчик.

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

А я вот понять не могу, причем тут рыба?

ты не понимаешь смысла юнит тестирования.

Использование отладчика при юнит тестах это антипаттерн.

https://upload.wikimedia.org/wikipedia/commons/5/5f/Archerfish_%28PSF%29.png

С юнит-тетсированием и отладчиком я перегнул, соглашусь.

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

stdout тоже полезен. Как раз сейчас изучаю разницу между поведениеем приложения на разных платформах по огромному логу отладочного вывода высокоуровнегого теста чтоб увидеть где первое различие.

https://www.youtube.com/watch?v=S4G_MeUUZlI

серебряной пули не было, нет и не будет. И это твое юнит-тестировпние ею не является :) если ты этого еще не понял — скорее всего жил недолго.(в этих твоих тестах скорее всего есть ошибки :))

уже разжевали, что risc-v фундаментально не заточен под производительные процессоры

В моей реальности Java на беке и JS на фронте используются юнит тесты и отладочный вывод в консоль.

Последнее используется там, где отладчиком пользоваться невозможно.

Кстати при написании хранимок на PL SQL тоже нельзя пользоваться отладчиком. В реальных банках он тупо отключен. И его не включат и через 3 года после того, как попросишь.

Кроме того, ты тесты лучше и дороже продашь, чем отладку.

В моей реальности Java на беке и JS на фронте используются юнит тесты и отладочный вывод в консоль.

JS на фронте внезапно прекрасно отлаживается в браузерном отладчике – для многих «облачных программистов» SaaS/PaaS это почему-то новость – на собеседованиях рассказывают про «отладку алертами» и «принтами в сосноль» – хотя код в модулях рантайма написан не ими, и далеко не везде можно «отлаживаться принтами» и «алертами», зато зачем-то им платформодержатель дал возможность включить отладочный рантайм и разминифицированные сорцы. Но они предпочитают превозмогать.

Последнее используется там, где отладчиком пользоваться невозможно.

Ну вот и выяснилась причина басен про «антипаттерн» и прочих разговоров в пользу бедных – выдали нужду за добродетель, при этом «вывод в сосноль» чот антипаттерном не считается :) А отладчик «невозможно» – значит не нужно :) (Или «я не смог – значит антипаттерн») Как всегда с поборниками «идеальной методологии» чаще всего это пустое надувание щок и пуки в лужу, но ой не бабочками.

Юнитесты по факту мало отличаются от программ, которые пишут люди, поэтому подвержены всем тем же сортам ошибок (особенно ран-тайм ошибок). Да и от глюков среды исполнения никто не застрахован – особенно с выхлопом ошибок не по теме (со ссылками на ошибки оракловой базы облачной платформы, которая например программисту не доступна бай дизайн, т.к. сама находится в облаке) или обрезаным стеком колов JS-фреймворка (которые случается бывают недоварены производителем или «активно развиваются», и тоже содержат ошибки). Так что объявлять использование отладчика антипаттерном можно скока угодно – полезность его от этого никуда не денется. А фанатики да, должны страдать.

Еще раз - на реальных конфигурациях ты просто напросто никак не сможешь запустить отладчик.

Совсем никак. Ты даже к DOM дереву не сможешь обратиться.

Тесты - твой ЕДИНСТВЕННЫЙ выход «отладки» приложений.

Именно поэтому был разработан cypress, чтобы упростить «отладку» в реальном тырпрайзе с большим количеством ограничений.

Еще раз - на реальных конфигурациях ты просто напросто никак не сможешь запустить отладчик.

Еще раз. Прекрасно могу и запускаю. У нас платформа позволяет (в серверном коде можно ставить бряки для сбора дампов памяти в веб-консоли…). Отладке JS на морде даже shadow Dom не помеха – только что id левые и прокси-объекты между JS и разметкой, но по своему коду отлично можно дебажиться – если в профиле аккаунта включить Debug даже сорцы разминифицируются (и, если охота, по фреймворку тоже можно гулять, например выяснить, что баг там, про него уже доложили вендорам и фикс ожидается в квартальном релизе – можно даже гелять по коду софтового телефона написанного третьей стороной, например Five9). В основе платформы кстати Java сервер приложений и оракловая база, сверху обмазанная «более другим SQL-подобием», которое можно дергать без наворачивания слоя обращения к базе (джависты кстати, приходя на эту платформу этим грешат :)). Технической невозможности никакой нет – кому надо, те добавили в свою платформу. Ну а другим проще было рассказывать студеные былины про «ЕДИНСТВЕННЫЙ выход».

s/гелять/гулять/

Это у вас.

А в реальном банковском секторе все построено по принципу - дай пользователю минимальные возможные права.

Я конечно понимаю, есть оффшоринг и nearshoring туда, где прогеры себе могут в браузере назначать полные админские права.

Но если ты внутренний программист в банке, то ты столкнешься с кучей ограничений, спущенных сверху.

И должен уметь их обходить. Тебе не зря платят 100 евро в час.