Нет, не шутка :)
Действительно не могу определить use case для этой библиотеки. Вам же все равно приходится через stack trace (только текстовый) искать проблемное место. Потом нужно дописывать вызов библиотеки. Лог писать специально для того, чтобы найти проблему. А если вы нашли не то место, где нужно исправлять? Тогда нужно продолжать подниматься по стек трейсу и уже в другом месте писать вызов библиотеки, ну и лог при необходимости. А лог нужно будет писать часто, т.к. библиотека только аргументы функции сама может выводить, а промежуточные значения — нет.
Все эти лишние действия только увеличивают время нахождения проблемы.
Иметь возможность остановить выполнение программы и посмотреть её состояние — бесценно, но Chrome не может знать, что именно мы хотим увидеть.
Ну, вообще-то может. Рецепт такой:
1) Ставим breakpoint в месте ошибки, либо отмечаем опцию «Pause on exceptions»
2) Используем панель Call Stack, переходим вверх по вызовам
3) Смотрим состояния переменных/параметров функций, либо наведением на них курсором, либо через панель Scope Variables
4) При желании, выполняем свой код в консоли в контексте текущего места в коде, либо используем панель Watch Expressions
5) Возвращаемся к п.2 до тех пор, пока не нашли истинное место проблемы
Заметьте, ни единой правки в коде не было произведено для отладки.
Что вам еще нужно? :)
По-моему, это новость пятилетней давности — www.membrana.ru/particle/1937
Вот более свежие (2011 г.) результаты от той же группы ученых: www.membrana.ru/particle/16803 (по ссылке статья «Учёные впервые извлекли кино из мыслей подопытных» с потрясным видео)
Боюсь, что даже один пользователь, который в несколько потоков начнет запрашивать несколько картинок c разницей в размерах 1px, сможет, во-первых, «убить» кеш, а во-вторых, занять практически все процессорное время.
Откуда дровишки?
2. это уже другой вопрос :)
Действительно не могу определить use case для этой библиотеки. Вам же все равно приходится через stack trace (только текстовый) искать проблемное место. Потом нужно дописывать вызов библиотеки. Лог писать специально для того, чтобы найти проблему. А если вы нашли не то место, где нужно исправлять? Тогда нужно продолжать подниматься по стек трейсу и уже в другом месте писать вызов библиотеки, ну и лог при необходимости. А лог нужно будет писать часто, т.к. библиотека только аргументы функции сама может выводить, а промежуточные значения — нет.
Все эти лишние действия только увеличивают время нахождения проблемы.
Ну, вообще-то может. Рецепт такой:
1) Ставим breakpoint в месте ошибки, либо отмечаем опцию «Pause on exceptions»
2) Используем панель Call Stack, переходим вверх по вызовам
3) Смотрим состояния переменных/параметров функций, либо наведением на них курсором, либо через панель Scope Variables
4) При желании, выполняем свой код в консоли в контексте текущего места в коде, либо используем панель Watch Expressions
5) Возвращаемся к п.2 до тех пор, пока не нашли истинное место проблемы
Заметьте, ни единой правки в коде не было произведено для отладки.
Что вам еще нужно? :)
Вот более свежие (2011 г.) результаты от той же группы ученых: www.membrana.ru/particle/16803 (по ссылке статья «Учёные впервые извлекли кино из мыслей подопытных» с потрясным видео)
Напомнило это :) www.youtube.com/watch?v=LJJ05fkkLaU&feature=player_detailpage#t=74s