Комментарии 44
А есть утилиты меряющие глубину стека и выдающие его статистику для конкретного метода?
Вы говорите про какой-то конкретный язык?
Глубина вызовов я думаю присутствует на любом языке. Но хотелось бы анализатор бинарника. Под MSVC было бы не плохо, соответственно любое сопутствующие языки C#, С++, C…
Т.е. без запуска кода измерить стек? Это невозможно сделать, ровно как и доказать математически корректность кода.
То есть если взять исходный код и проанализировать все вызовы функций по тексту, также как и сделать это с бинарником по методу машинного кода CALL — это не возможно?
Псевдокот:
Анализ Exe-шника ничего не скажет о возможной глубине стека.
void recursive(int value)
{
if(value==0)
return;
else
recursive(random(0..100));
}Анализ Exe-шника ничего не скажет о возможной глубине стека.
Анализ EXE может более объективно показать стек, поскольку функции с возможным inline будут отсутствовать. Пример с рекурсией можно отсечь по воссоздаваемому стеку при анализе, проверяя повторные вхождения методов. Смысл анализа не в логике возможных ветвлений, а в глубине вложенности методов.
Не, понимаю зачем это нужно, но по-моему IDA или одно из её расширений это умеет.
Как небольшая бонус фича. Во время дебага и так все видно. Но никто не будет специально дебажить каждую функцию и записывать все варианты стеков, скажем, для соблюдения принятой архитектуры кода. Иногда это помогает оценить нагруженность отдельного метода, вложенностями или вызовами. Ну и помощь при рефакторинге, также как и помощь при разборе незнакомого кода.
А когда у тебя получается неявная рекурсия, то это будет сразу видно.
А когда у тебя получается неявная рекурсия, то это будет сразу видно.
Скрытый текст
Мне как-то также говорили что нормали для трехмерной модели пересчитать невозможно и не приемлемо, из ряда «российских ученых». Тем не менее функция присутствует в любом движке и даже не требует от редактора сохранять сами нормали модели. На что я получал возглас «ну, это же в движке» — как-будто это магия маленьких зеленых человечков, которые живут внутри этой функции.
А что там с нормалями было-то, как обосновывалось?
Необходимая глубина стека-то неопределяема из-за проблемы останова, тут "а, ну это в движке" не пройдёт.
«А ну это в дебаге», подойдет? Я уже описал область применения и реализуемый алгоритм, не говоря уже об имеющемся полноценном аналоге.
А что там с нормалями было-то, как обосновывалось?CrossProduct или векторное умножение не считает объективно только параллельные вектора, но треугольник с параллельными сторонами сам по себе исключаем. Результат есть всегда. Что же касается конкретики расчета нормалей на множестве треугольников, то это задача изначально алгоритмическая и как таковых «пользовательских» нормалей нет. Разве что в виде карты нормалей и прочего уже ручного вмешательства в цепочку от моделирования до рендеринга. Ну и соответственно все утверждения что реализация подобного алгоритма невозможна от лукавого.
Если функции умеют вызывать себя (рекурсия) — в общем случае невозможно
Есть более сложные примеры с динамическими указателями, в которых действительно хотелось замерить глубину стека, но вот то что это «невозможно» утверждать поспешно. Поскольку тут можно эмулировать вызов метода заданный в ручную.
Это практически классическая проблема останова
ru.wikipedia.org/wiki/Проблема_остановки
Которая доказательно не имеет решения для тьюринг-полных языков.
Если язык не является тьюринг-полным (например, в нем нет рекурсии и любой цикл может выполняться только некоторое, известное до начала цикла, число раз) то тогда это возможно.
Примером таких языков являются некоторые (несовременные) языки шейдеров.
ru.wikipedia.org/wiki/Проблема_остановки
Которая доказательно не имеет решения для тьюринг-полных языков.
Если язык не является тьюринг-полным (например, в нем нет рекурсии и любой цикл может выполняться только некоторое, известное до начала цикла, число раз) то тогда это возможно.
Примером таких языков являются некоторые (несовременные) языки шейдеров.
Есть задача с данными: склад с 10 тоннами зерна, настало время раздачи зерна нулевому количеству потребителей. Сколько зерна получит каждый потребитель? Вспоминая утверждение что «на ноль делить нельзя» — задача не решается. Тем не менее каждый потребитель получает 0 зерна или ни сколько.
Вот и у вас, точно такая же, трактовка решения задачи «на ноль делить нельзя» — задача не решаема, конец.
Ты хочешь решить обобщенную задачу деления на ноль. Тем не менее частный случай, который из себя представляет конкретная программа или конкретные условия, может иметь решение.
Вот и у вас, точно такая же, трактовка решения задачи «на ноль делить нельзя» — задача не решаема, конец.
Ты хочешь решить обобщенную задачу деления на ноль. Тем не менее частный случай, который из себя представляет конкретная программа или конкретные условия, может иметь решение.
Конечно, частный случай может иметь решение.
Вот пример решения: Запустить и посмотреть.
Те программы, которые достаточно быстро завершатся, выдадут решения, и являются нашим «частным случаем».
Тут просто проблема в том что такая утилита, которая работает лишь для тривиальных программ, имеет мало пользы (потому что тривиальные программы обычно тривиально и проанализировать)
Вот пример решения: Запустить и посмотреть.
Те программы, которые достаточно быстро завершатся, выдадут решения, и являются нашим «частным случаем».
Тут просто проблема в том что такая утилита, которая работает лишь для тривиальных программ, имеет мало пользы (потому что тривиальные программы обычно тривиально и проанализировать)
Мне нет необходимости запускать программу, чтобы по ссылке метода перейти на его реализацию в коде. Также по таким ссылкам, выше стоящим, посчитать количество вложенностей до возможного — ограничивающего момента, результат [3..(бесконечность)] глубина стека — задача решается.
В больших программах, абстрактность вызовов распространена ровно также как и тривиальное прямое обращение к функциям, но они большие. А уж тем более если это расчетные задачи (например геометрические). То кода, без каких либо рекурсий, там тонны, но разобраться бывает также сложно как в абстракциях.
потому что тривиальные программы обычно тривиально и проанализироватьУ меня гигабайтный текст программы, запоминать что где не реально, особенно с абстрактными методами и прочим, приходиться смотреть на все исходные коды каждого метода, чтобы отрефакторить код. Но я не буду лазить по всем подряд методам поскольку если я вижу глубину их стека, то есть знаю насколько они тривиальны. Также как вижу насколько глубоко находиться текущий метод и имеет ссылки на себя или нет. На ряду с не анализируемыми участками кода по причине останова, но могу смоделировать их использование.
В больших программах, абстрактность вызовов распространена ровно также как и тривиальное прямое обращение к функциям, но они большие. А уж тем более если это расчетные задачи (например геометрические). То кода, без каких либо рекурсий, там тонны, но разобраться бывает также сложно как в абстракциях.
имеет мало пользыЕсли брать все возможности интеллисенса, то по отдельности они все тривиальны и имеют мало пользы.
Если у вас есть абстрактные методы — то бинарник вашей программы каким-то простым алгоритмом уже не проанализировать. Вы просто не сможете узнать те самые "такие же вышестоящие ссылки" без выполнения декомпиляции.
Зато есть и другие методы. Но в вашем примере результат [0..0] для метода на который должны ссылаться. Но если указать конкретный метод (любого из наследуемых классов) — смоделировать ситуацию, то проблем нет, и декомпилировать ни чего не требуется, тем более при наличии дебаг информации. Для чистого EXE утилита была бы пригодна к дизассемблерам, но смысла в ней мало.
Получать такою информацию без использования IDE, которая уже может и дебаг получить и все остальное подвязать, вообще смысла нету. Поэтому это очередной пример сферического коня в вакууме. На ряду с реальными примерами использования которые вы продолжаете игнорировать.
Получать такою информацию без использования IDE, которая уже может и дебаг получить и все остальное подвязать, вообще смысла нету. Поэтому это очередной пример сферического коня в вакууме. На ряду с реальными примерами использования которые вы продолжаете игнорировать.
Да я запамятовал, MSVC прекрасно показывает декомпилированный код, проблем также, c выдуманным камнем преткновения, не вижу. Но сам по себе анализ EXE подразумевает его своеобразную декомпиляцию на уровне алгоритмов анализа. Да, это сложный момент, но реализуемый. При этом не требует составления полного аналога дизассемблера. Тут достаточно определять размер команд в машинных кодах. Но все будет зависеть от сложности алгоритма анализа.
Конечно нет, учёные мужи бились над этой проблемой ещё в прошлом столетии. А иначе никто бы просто тесты не писал. Если я правильно понял вопрос, то он сводится к подзадаче https://en.wikipedia.org/wiki/Halting_problem
Попробуйте, может удастся решить, впишите себя в историю :)
Очень сложно спорить с людьми утверждающие что что-то невозможно, основываясь на тривиальных научных терминах, в то время когда этим активно пользуются, в том или ином виде. Меня всегда удивляла такая упоротость.
Ещё раз — можно построить flame graph во время работы, можно построить граф вызовов по коду, но однозначно предсказать заранее глубину стека во время будущей работы — нет, нельзя.
P.S. Я думал у нас конструктивный разговор, а Вы теорему называете "тривиальным научным термином". В этом свете даже не так обидна моя "упоротость". Ловите заслуженный минус в карму.
Ещё раз — можно построить flame graph во время работы, можно построить граф вызовов по коду, но однозначно предсказать заранее глубину стека во время будущей работы — нет, нельзя.
Вот вы сами со своими выводами спорите и хотите назвать это конструктивным разговором? А тем временем я ни где не конкретизировал «предсказание стека» — даже в такой формулировке ВОЗМОЖНЫЙ вариант стека, даже на уровне выше и ниже по вызовам метода, без каких либо данных (как часть дерева и каким либо другим образом), уже реализуемое решение. Но в ходе разговора я слышу только что — это не возможно. Какой тут возможен конструктив если вы, игнорируя реалии, все уже за меня додумали и решили?
Я же говорил о какой либо статистике! Опять же разговор о прогнозах или реальной работе все это уже реализовано как статически так и профайлерами.
Само по себе слово «предсказание» не требует ни какой точности лишь приближения к варианту работы. Но нет — это невозможно. А иначе как назвать такую зацикленность, на невозможности решения кроме как «упоротость»?
Сложности в реализации возможны для любой задачи, но кидать свое «профессиональное» «не реализуемо» в представлении только своего не реализуемого, не обозначенного и не обоснованного варианта — нет тут ни какого конструктива.
Предсказать и построить постфактум — в этом ключевая разница. Если ее учесть, противоречий в моих словах нет.
По поводу «додумали» — основывался на этом:
задал уточняющий вопрос:
Вы его не опровергаете, а задаете свой уточняющий к слову «невозможно»:
Соответственно я делаю вывод, что именно эту тему обсуждаем, а именно получение глубины стека без запуска, что в моем понимании является предсказанием.
Ок, уточню свою мысль — эту задачу корректно решить невозможно. Примерные эвристические алгоритмы могут существовать и неплохо работать на практике.
По поводу «додумали» — основывался на этом:
Анализ EXE может более объективно показать стек
задал уточняющий вопрос:
Т.е. без запуска кода измерить стек?
Вы его не опровергаете, а задаете свой уточняющий к слову «невозможно»:
То есть если взять исходный код и проанализировать все вызовы функций по тексту, также как и сделать это с бинарником по методу машинного кода CALL — это не возможно?
Соответственно я делаю вывод, что именно эту тему обсуждаем, а именно получение глубины стека без запуска, что в моем понимании является предсказанием.
Ок, уточню свою мысль — эту задачу корректно решить невозможно. Примерные эвристические алгоритмы могут существовать и неплохо работать на практике.
Ок, уточню свою мысль — эту задачу корректно решить невозможно.Иначе говоря «предсказание», на основе полученных данных от ветвлений методов, на основе конкретных адресов вызова или названий функций — получить не возможно. И тебе это не кажется противоречивым?
У меня есть данные что метод «вызывался..» и «вызывал..», а соответственно построить листы этих последовательностей (уже имеющееся решение), и на основе этого я не могу получить ни какого предсказания. ЗАШИБИСЬ.
Соответственно я делаю выводТы понимаешь, что ты делаешь вывод о том что невозможно сделать анализ текста или бинарника! Сюда же можешь поставить в ряд, невозможность открытия файла в тотал командере.
корректноКорректно это делает дебагер и то не каждый (возможно это вопрос так же и для дебагера), а не представленный мною алгоритм. И как я уже сказал это твое представление о корректности предсказания в твоей необхобимости решения задачи, о которой я не упоминал.
Иначе говоря «предсказание», на основе полученных данных от ветвлений методов, на основе конкретных адресов вызова или названий функций — получить не возможно. И тебе это не кажется противоречивым?
Нет, не кажется.
Сюда же можешь поставить в ряд, невозможность открытия файла в тотал командере.
А какая тут связь?
А какая тут связь?
Передо мной целая статья об утилитах которые анализирует файлы, а мне только что сказали — «этого сделать невозможно». Да еще о том что связи, с тем что «открыть файл в тотал командере — невозможно», ни какой нет.
facepalm.
В рамках своих же восклицаний о «невозможности» могли бы представить случай когда доступ к файлу происходит несколькими программами.
И вы хотите от меня конструктивизма?
sobolevn Спасибо за подборку.
heartrate — Простая визуализация выполнения вашей Python программы в реальном времени.
portray — Утилита для генерации документации из исходного Python кода.
heartrate — Простая визуализация выполнения вашей Python программы в реальном времени.
portray — Утилита для генерации документации из исходного Python кода.
Для меня удачной и своевременной находкой был Gitea — веб-интерфейс для работы с репозиториями git (очень похож на GitHub), который можно установить локально. Для тех, кто привык к GitHub, но хочет держать исходники на локальном сервере — отличная находка.
Видимо их сайт словил Хабр-эффект, хорошая реклама
Скорее РКН-эффект.
TL;DR: Они хостятся в Digital Ocean, и часть их IP-адресов заблокировано всякими разными инстанциями.
Который к тому же, в 10-15 раз легче GitLab
GitLab во многом сильно впереди. Тем более, если речь идет про коллаборативную работу.
(да, у gitea тоже есть плюс — она сильно легче по необходимым вычислительным ресурсам для работы)
За npkill спасибо :)
а как же Sampler
Я думал заняться визуализатором процесса компиляции, чтоб смотреть за тем, как красиво твой код не компилируется, но всё руки не доходили.
Одна из самых интересных статей за минувший период (хотя фактически она написана в июле) — статья Дена Абрамова про Algebraic Effects. Написано просто, доступно, есть ссылки на более глубокие материалы: https://overreacted.io/algebraic-effects-for-the-rest-of-us/
Посмотрел. Мое мнение нисколько не может считаться авторитетным, но пока мне начинает казаться, что JavaScript'еры извращенцы. Вместо того, чтобы пользоваться тем, что уже есть в других языках, они пытаются сделать JS лучше. То, что при этом придется тащить груз совместимости их не пугает. Касательно алгебраических эффектов — ну, похоже на callback'и (они даже в Си реализовывались с грехом пополам), только не нужно переписывать весь стек вызовов, т.е. интерпретатор добавляет эту фичу скрыто, но ценой еще меньшей эффективности интерпретируемого кода. Вот интересно — когда же мы остановимся в создании этих абстракций над абстракциями? Почему не попытаться взять более лучшие (ага) инструменты (типа Rust, Haskell etc.), а не "усовершенствовать" свой велосипед? Ответ у меня только тот, что перечисленные инструменты требуют квалификации для использовании. А на js — сел и начал писать код.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
9 лучших опенсорс находок за август 2019