LINUX.ORG.RU

Программа, которая ответит на вопрос «почему»

 


4

5

Результат нескольких лет труда одного паренька: https://github.com/andyjko/whyline

В действии: https://www.youtube.com/watch?v=t6gVZ-qZ4sI

Для Ъ - программа анализирует байткод и записывает трассу Java-приложения таким образом, что потом можно его выполнение крутить взад-вперед и инспектировать состояние переменных - в т.ч. понимать, каким образом мы в данном месте получили именно это значение.

Переворот в отладке? Какому технологическому стеку (помимо java/jvm в данном случае) ещё подвластно подобное? Теоретически, на Smalltalk вполне себе можно замутить. Или на JavaScript. Ещё?

★★★★★

Ответ на: комментарий от anonymous

после такого промаха в порядках, допустимо ли считать что теперь уже ты пытался «выдавать свой мозговой сок за истину»?

Разрешаю, считай.

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

Когда они грузятся с разной скоростью

С одинаковой.

декодируются с разной скоростью

С одинаковой.

(в зависимости от наличия префиксов, например)

Такие куллстори. Наверное ещё r9 юзать не надо? Понимаешь - есть реальный мир, а есть твой ламерской. Там, где ты начитался убогой макулатуры для даунов и что-то там мне кукарекаешь.

исполняются и подавно с разной скоростью (хотя бы в зависимости от того, какие инструкции вокруг них).

Не зависит. Никак.

В целом жертва убогих верований и убогой макулатуры.

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

С остальными потугами можно попытаться съехать на всякие «сложные» инструкции, но потуга так же не проканает, ибо их почти нет, а их влияние равно нулю.

registrant27492
()
Ответ на: комментарий от tailgunner

Пепрестань уже выдавать свойц мозговой сок за истину.

Опять твои потуги. Ты уже столько раз пытался, но всегда неудачно - ты на что надеешься? Что когда-нибудь тебе фортанёт?

Твой выхлоп - это просто трейсер сисколов для гуйни, который никакого отношения к отладке не имеет. А то, что там написано 1.2 - это враньё - это работает для гуйни и то это ещё с учётом вычета того, что replay работает без учёта летенси сети, ио и прочее. Т.е. если на этом тесте(который в видосике) запустить лису на сайт, который на локалхосте и не тормазит как дерьмо - она покажет х10, а не х2.

На реальных же примерах - это х10.

К тому же - трейс сисколов абсолютно бесполезен для отладки даже в том виде, в котором она на видосике у пацана. Там разрешая способность совершенно иная.

registrant27492
()
Ответ на: комментарий от registrant27492

На реальных же примерах - это х10.

Но совсем недавно ты говорил про x100. Ну и вообще - реальный пример в студию.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Но совсем недавно ты говорил про x100.

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

Ну и вообще - реальный пример в студию.

Да какой-нибудь вебсервер, либо любая другая херня завязанная на сисколах - т.е. где значительная часть времени проходит в сисколах, а не гуйня - где это доля процента.

registrant27492
()
Ответ на: комментарий от registrant27492

Капец ты чванливый бездарь :) Тебя лечить принудительно надо, лоботомией желательно.

anonymous
()
Ответ на: комментарий от registrant27492

Но совсем недавно ты говорил про x100.

О боже - я говорил об отладке, а не твоей херне

А, так ты еще и за контекстом не следишь %)

Твоя херня к отладке отношения не имеет. Это бесполезное дерьмо. Это просто replay на котором можно сделать разрешающую способность(т.е. шаг назад) «вызов сискола», что бесполезно абсолютно

Мде. Присоединяюсь к мнению анонимуса.

tailgunner ★★★★★
()
Ответ на: комментарий от vzzo

О боже - эти потуги. Хотя сравнение xor и cmpxchg с потугами в район префикса - уже говорит о тотальной лсности, но это такое. Какое отношение lock имеет к инструкциям? Ладно - мне лень объяснять лсным балаболом почему из этого ничего не следует.

Процитирую.

С остальными потугами можно попытаться съехать на всякие «сложные» инструкции, но потуга так же не проканает, ибо их почти нет, а их влияние равно нулю.

Когда ты мне покажешь пример реального кода, где lock cmpxchg [rbx] оказывает влияние(ну хотя-бы +-х1 - хотя это ничего не поменяет, но ладно) на ipc, а потом ещё покажешь, что этот случая не является вырожденным, а является реальной(заметной) частью множество программ - тогда твой высер будет иметь смысл, а так - убогие потуги.

registrant27492
()
Ответ на: комментарий от tailgunner

А, так ты еще и за контекстом не следишь %)

Ну давай - где и как я не слежу.

Мде. Присоединяюсь к мнению анонимуса.

Пробалабоил - слился. А так да - у анонимуса нет мнения - это ламер которого я обоссал с его потугами по части инструкций.

registrant27492
()
Ответ на: комментарий от anonymous

может царь и перегнул с цифрами, но в целом чудес не бывает, лол

Царь не загнул с цифрами - просто балабол выкатил то, что не является тем, о чём говорил царь. Для этого достаточно поглядеть когда он выкатил свой rr-днище, что оно такое и почему это не то, о чём говорил я, когда балабол отвечал мне.

registrant27492
()
Ответ на: комментарий от anonymous

Ах да, ну ладно. Раз днищапротектор блюдёт твои потуги - помножим на ноль тебя иначе.

Ты можешь взять такую тулу как perf, там stat по умолчанию показывает ipc - ты можешь натравить его на что угодно - он посчитает тебе ipc. Когда натравишь и осознаешь весь уровень никчёмности своих потуг - приходи. Я объясню тебе почему так происходит.

registrant27492
()
Ответ на: комментарий от registrant27492

Очевидно, что в программах-числодробилках и программах, оперирующих lock-free-структурами данных будет отличие в среднем времени выполнении одной инструкции большее, чем статистическая погрешность. Если у царя однобокие тест-кейсы, то ему нужно научиться не судить по ним о всех программах на всех процессорах.

Ещё рекомендую царю почитать о том, как устроены современные процессоры, что такое cisc с risc ядром и почему при такой архитектуре по определению не может выполняться то, о чём пишет царь.

vzzo ★★★
()
Ответ на: комментарий от vzzo

Очевидно, что в программах-числодробилках и программах, оперирующих lock-free-структурами данных будет отличие в среднем времени выполнении одной инструкции большее, чем статистическая погрешность.

Опять же враньё. Обделался - ври. Ври, когда обделался - типичная тактика любого балабола.

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

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

Враньё - выкатывай. Я тебе уже назвал критерии. Сможешь - вперёд. А коли не можешь - не кукарекай.

Ещё рекомендую царю почитать о том, как устроены современные процессоры

В отличии от тебя, балабола, я знаю как устроены процессоры - поэтому ты врёшь, ты обделался, а я нет.

что такое cisc с risc ядром и почему при такой архитектуре по определению не может выполняться то, о чём пишет царь.

Причём тут какие-то cisc/risc, хотя от ламерка ожидать чего-то больше - глупо.

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

Хотя о чём это я - когда балаболка выкатывает как пример инструкцию, которая никакого отношения к архитектуре не имеет вообще, но после предпринимает потуги в адрес архитектуры.

Как я уже сказал - я победил - у меня есть чёткие критерии измерения, есть чёткие критерии общего случая и прочее. Хочешь поспорить - пошли измерим. Критерии я описал - не согласен - спорь.

Я даю тебе шанс заслужить ликбез от меня - для этого ты опишешь мне своё видение - т.е. докажешь, что ты хотя-бы представляешь то(имеешь реальное представление) о чём говоришь, а не являешься пыстышкой-ретранслятором левого звона. Покажешь - правильности твоего представления я не требую. Хорошо.

Не покажешь - выпилишься с позором из темы сам.

registrant27492
()
Ответ на: комментарий от registrant27492

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

Еще раз, если есть код и логи «стоков», то из любого состояния можно отматать в любое состояние. Т.к. все операции становятся обратимыми.

Давай я тебе объясню почему нельзя - ты собрал инпут какой-то - далее ты не знаешь по какому пути пойдёт программа - ты знаешь только куда она придёт.

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

Ну и по поводу кода - дебаген не имеет никакого кода, ибо от имения кода нужно не просто его наличие - его наличие есть всегда, а собственно понимание этого кода.

Никакого понимания кода не нужно. Нужна только последовательность опкодов и умение их обращать.

anonymous
()
Ответ на: комментарий от registrant27492

Не обратимые операции все - любые.

Нет, далеко не все.

Ну не сохранишь ты a * b + c - будет только рид - один хрен гигабайты в секунду.

Не будет никаких гигабайтов в секунду.

anonymous
()
Ответ на: комментарий от registrant27492

Когда ты мне покажешь пример реального кода, где lock cmpxchg [rbx] оказывает влияние(ну хотя-бы +-х1 - хотя это ничего не поменяет, но ладно) на ipc, а потом ещё покажешь, что этот случая не является вырожденным, а является реальной(заметной) частью множество программ - тогда твой высер будет иметь смысл, а так - убогие потуги.

Ты же сам выше говорил про работу с памятью. А при плотной работе с памятью IPS падает в десятки-сотни раз. Да даже банальный мисс бренчпредиктора внутри тайтлупа изи просаживает производительность в два-три раза.

anonymous
()
Ответ на: комментарий от registrant27492

Как я уже сказал - я победил - у меня есть чёткие критерии измерения, есть чёткие критерии общего случая и прочее. Хочешь поспорить - пошли измерим. Критерии я описал - не согласен - спорь.

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

  • Критерии общего случая;
  • Обоснование того, что этот общий случай покрывает как минимум два частных случая:
    • Перемножение матриц алгоритмом кубической сложности, при чём вторая матрица хранится в транспонированном виде;
    • Программа с четырьмя потоками, два из которых постоянно запихивают в lock-free очередь выхлоп rand(), а другие два — достают этот выхлоп и считают среднее арифметическое элементов, которые вылезли из очереди;
  • Реализацию двух моих частных случаев на си;
  • Метод подсчёта количества выполненных инструкций в секунду с обоснованием его погрешности;
  • Запуск этого метода на указанных мной программах;
  • Таблица с результатами, которая заставит меня сказать, что царь — это царь, а я был не прав и ничего не понимаю в компьютерах. Но почему-то я уверен, что ничего этого не будет, а будет очередное кукареканье о том, что царь знает всё, но ничего никому не будет доказывать, так как доказывать должны ему.

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

vzzo ★★★
()
Ответ на: комментарий от vzzo

Метод подсчёта количества выполненных инструкций в секунду с обоснованием его погрешности;

Hardware performance couners, а как же ещё) про погрешность — это к производителю железа

Кстати, а что царь добьётся, написав эти программы, я что-то упустил нить диалога) Просто ни матрицы, ни потоки к инструкциям особого отношения не должны иметь. В случае с матрицами может быть проблема с памятью, если матрицы большие, а с потоками — дело в правильной реализации этой очереди

anonymous
()
Ответ на: комментарий от tailgunner

Ох, ё. Ты уже и модератор! Чтоб тогда тебе этого царя не забанить? Понимаю, мера не действенная, но регистрироваться тут задолбаешься.

А так ничего там годного, всё общеизвесная информация

anonymous
()
Ответ на: комментарий от anonymous

В случае с матрицами может быть проблема с памятью, если матрицы большие

и с точностью, если матрица float

yoghurt ★★★★★
() автор топика
Ответ на: комментарий от tailgunner

Как же это миро. 3калеки скооперировались против царя - удачи. Посмотрел я мусор в удалённых - ты реально в это веришь? Это либо болезнь, либо троллинг меня. Ладно амёбка - она может не знать про мои прошлые темы, но кидать мне пример, который я полностью разбирал в иллитном запиле - ну это просто смешно.

Ладно - мне разрешили посидеть в интернетах после курса терапии - я с вами.

registrant27492
()
Ответ на: комментарий от anonymous

Еще раз, если есть код и логи «стоков», то из любого состояния можно отматать в любое состояние.

Уважаемая балаболка - имея логи - ты можешь переместиться только в следующие состояние - в предыдущие ты не можешь перейти. Давай попроще. Трейс - это состояние в местах переходов(с каким-то разрешением) - знания состояния в переходах ты не можешь обратить состояние назад никак. Тебе нужно либо иметь операцию «обратить» для каждого перехода(коей у тебя нет), либо сохранять полностью контекст, либо обделаться.

Давай попроще - имея твой жизненный путь «лор-сортир-жратва-лор» - мы не можем никак откатить жратву - мы можем только переиграть твой путь до жратвы. Далее - переиграть то, что ты делал в сортире мы не можем, либо откатить. Мы не может откатить «поссат/посрат», ибо в нашем пути их нет. Это и есть разрешающая способность трейса. И тогда - нам надо либо запоминать все твои действия, а не только путь, либо уже онлайн следить за тем - что ты там делаешь, после переигровки.

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

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

Ты можешь только переиграть заново до метки, из которой ты пришел(и то - только к её началу(т.е. только к сортиру, а не к тем действиям, что ты там производил).

Никакого понимания кода не нужно. Нужна только последовательность опкодов и умение их обращать.

Умение «Обращать» и есть понимание кода. Ты не можешь обратить мемсет - ты не знаешь значений того, что он затёр и влияния этого на программу.

Опять же - всё упирается в запоминание всего контекста памяти.

registrant27492
()
Ответ на: комментарий от anonymous

Нет, далеко не все.

Все. Любая запись в память без понимания контекста(которым отладчик не обладает) - является необратимой.

Не будет никаких гигабайтов в секунду.

Твоя проблема в том, что ты ламерок. У perf есть евент mem-stores - вперёд. Почему вы все такие тупые - это просто ужос. Ладно не понимаешь - что тебе мешает измерить? Либо даже на это не способен.

За тебя пошел и сделал:

# perf stat -e instructions,mem-stores,cycles -p `pidof firefox`
^C
 Performance counter stats for process id '25054':

    59,108,568,077      instructions              #    0.86  insns per cycle        
     9,070,436,100      mem-stores                                                  
    68,472,175,220      cycles                                                      

      20.407468628 seconds time elapsed

Как так.

9/20лярдаps на обычном серфинге? Отличная история. Ну и ipc прям как царь считал. И даже если предположить, что все эти риды были однобайтными - надо хранить адрес+до+после и того 10байт и того - 5гигайбайт.

registrant27492
()
Ответ на: комментарий от vzzo

Никаких критериев ты не описал

Описал:

Когда ты мне покажешь пример реального кода, где lock cmpxchg [rbx] оказывает влияние(ну хотя-бы +-х1 - хотя это ничего не поменяет, но ладно) на ipc, а потом ещё покажешь, что этот случая не является вырожденным, а является реальной(заметной) частью множество программ - тогда твой высер будет иметь смысл, а так - убогие потуги.

Перемножение матриц алгоритмом кубической сложности, при чём вторая матрица хранится в транспонированном виде;
Программа с четырьмя потоками, два из которых постоянно запихивают в lock-free очередь выхлоп rand(), а другие два — достают этот выхлоп и считают среднее арифметическое элементов, которые вылезли из очереди;

Выкатывай код - померим. Всё просто. Осталось только доказать, что эти случая не являются вырожденными(т.е. являются заметной частью заметной части множества программ).

Реализацию двух моих частных случаев на си;

АХахах. Ой не могу. Случаи твоя, а должен что-то я. В целом слив засчитан.

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

Вера ламерка она такая милая. Когда 2амёбки кооперируются и пытаются что-то тявкать поддакивая друг другу - безличностные балаболки. Ничего - тапка царя на каждого хватит.

Уже давно понять - где ваше место, а где моё.

registrant27492
()

Вот царю пример. Может быть царь слышал про так называемый out-of-order execution. Хотя вряд ли.

Это так мило. Правда потуги ламерюжки не имеют никакого отношения к ООО, но ладно - поверим в это.

Так вот, если правильно использовать эту фичу, одни и те же инструкции внезапно начинают исполняться быстро-быстро

Нет - они исполняются так же. Я выше уже писал про ipc и про фронтед.

, увеличиваются царёвы характеристики скорости, такие как гогибайт/секунда и байт/тракт.

Нет, не увеличивают. Они как были - так и остались. Ну и да, кстати, балаболка. Я всё понимаю - мозгом ты не наделён и пытаешься мне тут свои потужки пихать, но всё же.

Ты мне кукарекал «разные инструкции бывают», как и твоя балаболка-сосед:

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

Вот теперь тебе осталось объяснить - каким образом «с разной скоростью» относится к твоему примеру.

http://pastebin.com/mtgJ6R8d

А по поводу этой убогой потуги. Я уже когда-то разбирал именно этот случай и объяснял почему. В целом убогая пародия сделанная кривыми культяпками - очень мило.

Производительность; илитный запил оптимальных реализаций и основы матчасти. - ой, что это. Ну бывает, бывает.

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

registrant27492
()
Ответ на: комментарий от registrant27492

Уважаемая балаболка - имея логи - ты можешь переместиться только в следующие состояние - в предыдущие ты не можешь перейти.

Конечно же, можешь.

Тебе нужно либо иметь операцию «обратить» для каждого перехода(коей у тебя нет)

Так вот, при логгировании стоков, у тебя есть такая операция.

Нет - ты не знаешь.

Как не знаю, если это в логах написано?

Умение «Обращать» и есть понимание кода.

Нет, это не имеет ничего общего с «пониманием».

Ты не можешь обратить мемсет - ты не знаешь значений того, что он затёр

Конечно знаю, я же их залогировал

Опять же - всё упирается в запоминание всего контекста памяти.

Не всего, а только деструктивных операций.

anonymous
()
Ответ на: комментарий от registrant27492

Все. Любая запись в память без понимания контекста(которым отладчик не обладает) - является необратимой.

Конечно же, не любая.

За тебя пошел и сделал:

0.8 инструкций на цикл. А ты там сколько обещал?

надо хранить адрес+до+после и того 10байт и того - 5гигайбайт.

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

anonymous
()
Ответ на: комментарий от anonymous

Конечно же, можешь.

Как. Выкатывай.

Так вот, при логгировании стоков, у тебя есть такая операция.

Нету. Выкатывай.

Как не знаю, если это в логах написано?

Мне тебя в дерьмо мокнуть опять? Давай мокнём:

# perf stat -e instructions,mem-stores,cycles,branches -p `pidof firefox`
^C
 Performance counter stats for process id '5182':

    89,477,993,372      instructions              #    0.98  insns per cycle        
    13,928,194,166      mem-stores                                                    (100.00%)
    91,602,238,025      cycles                                                        (100.00%)
    19,365,518,088      branches                                                      (100.00%)

      35.569060189 seconds time elapsed

Бранчей ещё больше, чем мемсторов.Что дальше? Никакая «юзабельная» реализация не имеет разрешающую способность до бранчей. Т.е. сисколы, инпуты, просто вызовы - это максимум что есть.

Хотя зачем - ламерок уже обделался и пытается юлить.

Нет, это не имеет ничего общего с «пониманием».

Ога. А ниже:

Не всего, а только деструктивных операций.

В целом тут можно только в рожу нассать - балаболка сломалась. Нельзя определить тип операции не понимания её семантики - тебе пример с мемсетом написали.

Поэтому ты либо сохраняешь каждый джамп(вместе с контекстом, ибо а никак обратить контекст без «понимания» ты не можешь - поэтому тебе надо сохранять все инструкции и обращать их - ибо семанику их ты понимаешь(хотя ты, ламерок, конечно же нет, но предположим)). Т.е. любые обращения составных операций без «понимания» кода невозможно - возможно их обращение только через обращение инструкций - т.е. операций, семантика которых описана в мануале по архитектуре.

registrant27492
()
Ответ на: комментарий от anonymous

Конечно же, не любая.

Какая - выкатывай примеры.

0.8 инструкций на цикл. А ты там сколько обещал?

В среднем одну. Так и вышло.

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

Пример этого алгоритма.

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

Я жду какого-нибудь конкретного высера на котором естественно ты обделаешься. Высрешь мне «алгоритм» я тебя смешаю с дерьмом, как и твой «алгоритм». Валяй.

Обосрёшься так же, как обосрался с матчастью.

registrant27492
()
Ответ на: комментарий от Legioner

Отладка в этой концепции просто не нужна.

Да ну. Вот когда у тебя чушь получается и тесты говорят, что чушь, а найти где она надо быстро, то тогда и нужна отладка.

peregrine ★★★★★
()
Ответ на: комментарий от Legioner

Тест не сделает очевидной проблему. У тебя тест тестирует какой-то черный ящик - т.е. его ответ «работает/не работает» - он не отвечает на вопрос «где конкретно не работает».

Либо ты предлагаешь тестировать результат каждой операции? Ну дак это нереально.

registrant27492
()
Ответ на: комментарий от registrant27492

Тест не сделает очевидной проблему. У тебя тест тестирует какой-то черный ящик - т.е. его ответ «работает/не работает» - он не отвечает на вопрос «где конкретно не работает».

Хороший тест тестирует белый ящик, т.к. пишется исходя из полного знания реализации. Чёрный ящик это что угодно, но не юнит-тестирование.

Либо ты предлагаешь тестировать результат каждой операции? Ну дак это нереально.

Тестируй подозрительные фрагменты. Используй поиск пополам и другие техники. Только не руками, с дебаггером и всматриванием в переменные, а правильным тестом.

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

Хороший тест тестирует белый ящик

Белый ящик не нужно тестировать.

Чёрный ящик это что угодно, но не юнит-тестирование.

Это именно оно. Оно на то и юнит, что оно тестирует отдельные части, а не каждую операцию.

Тестируй подозрительные фрагменты.

Какие фрагменты - откуда ты их возмёшь.

Тебе дано - 100500 функций по 1000строк. Максимум что ты напишешь - тесты для каждой функции. Вывалился у тебя тест на 1001 функции - в какой из 1000строк что-то пошло по херне?

Будешь писать тест на каждую строку/операцию? Я уже задал тебе этот вопрос.

Отладка и даёт ответ на этот вопрос - почему и где конкретно появилось то, что появиться не должно. Собственно вменяемые пацаны это делают трассировкой, но это такое.

registrant27492
()
Ответ на: комментарий от Legioner

Я тебе даже строчку могу сказать, где проблема. Только не поможет это, если код и алгоритм достаточно сложны и не очевидны.

peregrine ★★★★★
()
21 октября 2016 г.
Ответ на: комментарий от basp

В общем вот. Фанфар пока не будет, ибо за фатальным неимением времени допилить до ума не удаётся.

yoghurt ★★★★★
() автор топика
Ответ на: комментарий от tailgunner

rr штоле?
http://rr-project.org

А он уже работает? Последний раз, когда я тыкал ео палочкой он быстро-решительно падал на старте с руганью на какой-то неподдерживаемый сискол.

Stil ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.