KT
у меня просто программы наверное не такие сложные )
Size: a a a
2020 May 28
A
а дебаггер ручками?
Он может удобнее, чем пользование джуно
KT
я дебаггером не пользуюсь почти
АО
На самом деле использование дебаггера это всего лишь стиль программирования.
Если разбивать программу на маленькие функции, то получается, что дебажить и не надо практически. Тестами покрываешь логику, отдельные маленькие функции можно проверять с помощью логов.
Если разбивать программу на маленькие функции, то получается, что дебажить и не надо практически. Тестами покрываешь логику, отдельные маленькие функции можно проверять с помощью логов.
m
ну для простых юзкейсов можно хоть notepad.exe юзать
A
На самом деле использование дебаггера это всего лишь стиль программирования.
Если разбивать программу на маленькие функции, то получается, что дебажить и не надо практически. Тестами покрываешь логику, отдельные маленькие функции можно проверять с помощью логов.
Если разбивать программу на маленькие функции, то получается, что дебажить и не надо практически. Тестами покрываешь логику, отдельные маленькие функции можно проверять с помощью логов.
Очень хороший стиль разработки) но иметь возможность продебажить иногда необходимо, если, например, баг из-за изменений в 1е-15, порождаемый разным результатом суммирования массивов (один сортированный, другой нет)
A
Не представляю как такое эффективно находить, если система на проде упала, без дебаггера
АО
Хм.
Я не буду спорить, потому что сам с таким не сталкивался.
Поэтому рассуждения мимопроходящего 😊
1. На проде всё должно быть обложено логами, и разборы полётов по ним происходят в любом случае. Не думаю, что возможно дебажить прод (или я не так понял фразу).
2. Если изменения в 1e-15 из-за изменения порядка суммирования валят программу, то это очень опасно и стоит размышлений, потому что (опять же со стороны, может быть специфика задачи) выглядит, что алгоритм численно нестабилен, а значит мест где он будет валиться намного больше. Ну и конечно, такая штука не паралелится ни разу, потому что в паралелях с порядком совсем тяжело и это ещё один повод задуматься над алгоритмом.
Я не буду спорить, потому что сам с таким не сталкивался.
Поэтому рассуждения мимопроходящего 😊
1. На проде всё должно быть обложено логами, и разборы полётов по ним происходят в любом случае. Не думаю, что возможно дебажить прод (или я не так понял фразу).
2. Если изменения в 1e-15 из-за изменения порядка суммирования валят программу, то это очень опасно и стоит размышлений, потому что (опять же со стороны, может быть специфика задачи) выглядит, что алгоритм численно нестабилен, а значит мест где он будет валиться намного больше. Ну и конечно, такая штука не паралелится ни разу, потому что в паралелях с порядком совсем тяжело и это ещё один повод задуматься над алгоритмом.
PY
Arthur
А неймспейсы?)
токо о своем наболевшем. мнеб еще асинхронные процедуры туда и сопроцедуру (корутины)
A
Хм.
Я не буду спорить, потому что сам с таким не сталкивался.
Поэтому рассуждения мимопроходящего 😊
1. На проде всё должно быть обложено логами, и разборы полётов по ним происходят в любом случае. Не думаю, что возможно дебажить прод (или я не так понял фразу).
2. Если изменения в 1e-15 из-за изменения порядка суммирования валят программу, то это очень опасно и стоит размышлений, потому что (опять же со стороны, может быть специфика задачи) выглядит, что алгоритм численно нестабилен, а значит мест где он будет валиться намного больше. Ну и конечно, такая штука не паралелится ни разу, потому что в паралелях с порядком совсем тяжело и это ещё один повод задуматься над алгоритмом.
Я не буду спорить, потому что сам с таким не сталкивался.
Поэтому рассуждения мимопроходящего 😊
1. На проде всё должно быть обложено логами, и разборы полётов по ним происходят в любом случае. Не думаю, что возможно дебажить прод (или я не так понял фразу).
2. Если изменения в 1e-15 из-за изменения порядка суммирования валят программу, то это очень опасно и стоит размышлений, потому что (опять же со стороны, может быть специфика задачи) выглядит, что алгоритм численно нестабилен, а значит мест где он будет валиться намного больше. Ну и конечно, такая штука не паралелится ни разу, потому что в паралелях с порядком совсем тяжело и это ещё один повод задуматься над алгоритмом.
Привнесу контекст. Время на нахождение ошибки ~1-2 часа. Ошибка происходит из-за накопленного эффекта поведения многих функций. Сама ошибка внутри hot loop, если логгировать все, то логов будет несколько ГБ. Дебаг кода с входными данными с прода самый быстрый вариант из тех, что я знаю (
A
Алгоритм в некоторых случаях нестабилен, да. Но стабильные алгоритмы не дают результат, к сожалению, специфика задачи противная
VG
несколько ГБ логов - норм, особенно если писать их в бинарные таблицы со сжатием, а не тупо текстом, и уметь читать их кусочками из нужного места :)
A
А как потом искать место, где упало?)
A
И из-за чего
A
Конкретно в моем случае пришлось бы дампить сами массивы данных
VG
я так и делаю :) но у меня timeseries молотятся сложными цепочками алгоритмов
A
А примерный порядок размеров массивов?
VG
ну скажем 10 массивов по 20e6 точек, которые по ходу анализа могут сжиматься в прореженные массивы
VG
но без отладчика действительно не посмотреть, почему в конкретном месте -1 вместо 1
PY
timeseries это круто особенно с тактовой мгц 250