Доброй осени, дамы и господа. Подготовил для вас подборку самых интересных находок из опенсорса за август 2019.
За полным списком новых полезных инструментов, статей и докладов можно обратиться в мой телеграм канал @OpensourceFindings (по ссылке зеркало, если не открывается оригинал).
В сегодняшнем выпуске.
Технологии внутри: Python, Rust, JavaScript, Go.
Тематика: веб разработка, администрирование, инструменты разработчика.
heartrate
Простая визуализация выполнения вашей Python программы в реальном времени.
Написано на и для Python.
npkill
Утилита для поиска и удаления всех node_modules на вашей системе. Чистит сотни мегабайт места!
Написано на TypeScript.
ciao
Утилита для простого мониторинга HTTP адресов и статус кодов. И проверок здоровья. С красивым веб-интерфейсом.
Написано на Ruby.
returns
Набор примитивов для написания типизированных монад и способов их трансформации и композиции.
Написано на и для Python.
pastel
Утилита для работы с цветами из командной строки.
Написано на Rust.
chart.xkcd
Библиотека для создания графиков в стиле xkcd.
Написано на JavaScript.
portray
Утилита для генерации документации из исходного Python кода.
Написана на и для Python.
nushell
Новый shell от Yehuda Katz (Ember.js) и Jonathan Turner (TypeScript, Rust). Главная идея: все внутри = данные.
Написано на Rust.
Ссылка
Ознакомительный пост в блоге создателя
wtf
Дашборд внутри вашей командной строки.
Написано на Go.
Бонус!
Одна из самых интересных статей за минувший период (хотя фактически она написана в июле) — статья Дена Абрамова про Algebraic Effects. Написано просто, доступно, есть ссылки на более глубокие материалы: https://overreacted.io/algebraic-effects-for-the-rest-of-us/
На сегодня все. Для тех, кому подборка понравилась — подписывайтесь на канал. Там много и других интересных проектов. Предложения по улучшениям, ссылки на проекты, обратную связь — пишите в комментарии.
panteleymonov
А есть утилиты меряющие глубину стека и выдающие его статистику для конкретного метода?
sobolevn Автор
Вы говорите про какой-то конкретный язык?
panteleymonov
Глубина вызовов я думаю присутствует на любом языке. Но хотелось бы анализатор бинарника. Под MSVC было бы не плохо, соответственно любое сопутствующие языки C#, С++, C…
QtRoS
Т.е. без запуска кода измерить стек? Это невозможно сделать, ровно как и доказать математически корректность кода.
panteleymonov
То есть если взять исходный код и проанализировать все вызовы функций по тексту, также как и сделать это с бинарником по методу машинного кода CALL — это не возможно?
Jesting
Псевдокот:
void recursive(int value){
if(value==0)
return;
else
recursive(random(0..100));
}
Анализ Exe-шника ничего не скажет о возможной глубине стека.
panteleymonov
Анализ EXE может более объективно показать стек, поскольку функции с возможным inline будут отсутствовать. Пример с рекурсией можно отсечь по воссоздаваемому стеку при анализе, проверяя повторные вхождения методов. Смысл анализа не в логике возможных ветвлений, а в глубине вложенности методов.
Jesting
Не, понимаю зачем это нужно, но по-моему IDA или одно из её расширений это умеет.
panteleymonov
Как небольшая бонус фича. Во время дебага и так все видно. Но никто не будет специально дебажить каждую функцию и записывать все варианты стеков, скажем, для соблюдения принятой архитектуры кода. Иногда это помогает оценить нагруженность отдельного метода, вложенностями или вызовами. Ну и помощь при рефакторинге, также как и помощь при разборе незнакомого кода.
А когда у тебя получается неявная рекурсия, то это будет сразу видно.
mayorovp
А что там с нормалями было-то, как обосновывалось?
Необходимая глубина стека-то неопределяема из-за проблемы останова, тут "а, ну это в движке" не пройдёт.
panteleymonov
«А ну это в дебаге», подойдет? Я уже описал область применения и реализуемый алгоритм, не говоря уже об имеющемся полноценном аналоге.
CrossProduct или векторное умножение не считает объективно только параллельные вектора, но треугольник с параллельными сторонами сам по себе исключаем. Результат есть всегда. Что же касается конкретики расчета нормалей на множестве треугольников, то это задача изначально алгоритмическая и как таковых «пользовательских» нормалей нет. Разве что в виде карты нормалей и прочего уже ручного вмешательства в цепочку от моделирования до рендеринга. Ну и соответственно все утверждения что реализация подобного алгоритма невозможна от лукавого.ShadowTheAge
Если функции умеют вызывать себя (рекурсия) — в общем случае невозможно
panteleymonov
Есть более сложные примеры с динамическими указателями, в которых действительно хотелось замерить глубину стека, но вот то что это «невозможно» утверждать поспешно. Поскольку тут можно эмулировать вызов метода заданный в ручную.
ShadowTheAge
Это практически классическая проблема останова
ru.wikipedia.org/wiki/Проблема_остановки
Которая доказательно не имеет решения для тьюринг-полных языков.
Если язык не является тьюринг-полным (например, в нем нет рекурсии и любой цикл может выполняться только некоторое, известное до начала цикла, число раз) то тогда это возможно.
Примером таких языков являются некоторые (несовременные) языки шейдеров.
panteleymonov
Есть задача с данными: склад с 10 тоннами зерна, настало время раздачи зерна нулевому количеству потребителей. Сколько зерна получит каждый потребитель? Вспоминая утверждение что «на ноль делить нельзя» — задача не решается. Тем не менее каждый потребитель получает 0 зерна или ни сколько.
Вот и у вас, точно такая же, трактовка решения задачи «на ноль делить нельзя» — задача не решаема, конец.
Ты хочешь решить обобщенную задачу деления на ноль. Тем не менее частный случай, который из себя представляет конкретная программа или конкретные условия, может иметь решение.
ShadowTheAge
Конечно, частный случай может иметь решение.
Вот пример решения: Запустить и посмотреть.
Те программы, которые достаточно быстро завершатся, выдадут решения, и являются нашим «частным случаем».
Тут просто проблема в том что такая утилита, которая работает лишь для тривиальных программ, имеет мало пользы (потому что тривиальные программы обычно тривиально и проанализировать)
panteleymonov
Мне нет необходимости запускать программу, чтобы по ссылке метода перейти на его реализацию в коде. Также по таким ссылкам, выше стоящим, посчитать количество вложенностей до возможного — ограничивающего момента, результат [3..(бесконечность)] глубина стека — задача решается.
У меня гигабайтный текст программы, запоминать что где не реально, особенно с абстрактными методами и прочим, приходиться смотреть на все исходные коды каждого метода, чтобы отрефакторить код. Но я не буду лазить по всем подряд методам поскольку если я вижу глубину их стека, то есть знаю насколько они тривиальны. Также как вижу насколько глубоко находиться текущий метод и имеет ссылки на себя или нет. На ряду с не анализируемыми участками кода по причине останова, но могу смоделировать их использование.В больших программах, абстрактность вызовов распространена ровно также как и тривиальное прямое обращение к функциям, но они большие. А уж тем более если это расчетные задачи (например геометрические). То кода, без каких либо рекурсий, там тонны, но разобраться бывает также сложно как в абстракциях.
Если брать все возможности интеллисенса, то по отдельности они все тривиальны и имеют мало пользы.
mayorovp
Если у вас есть абстрактные методы — то бинарник вашей программы каким-то простым алгоритмом уже не проанализировать. Вы просто не сможете узнать те самые "такие же вышестоящие ссылки" без выполнения декомпиляции.
panteleymonov
В вашем примере результат [0..0] для метода на который должны ссылаться. Но если указать конкретный метод (любой из наследуемых классов) — смоделировать ситуацию, то проблем нет, и декомпилировать ни чего не требуется, тем более при наличии дебаг информации. Для чистого EXE утилита была бы пригодна к дизассемблерам, но смысла в ней мало.
Получать такою информацию без использования IDE, которая уже может и дебаг получить и все остальное подвязать, вообще смысла нету. Поэтому это очередной пример сферического коня в вакууме.
panteleymonov
Да я запамятовал, MSVC прекрасно показывает декомпилированный код, проблем также, c выдуманным камнем преткновения, не вижу. Но сам по себе анализ EXE подразумевает его своеобразную декомпиляцию на уровне алгоритмов анализа. Да, это сложный момент, но реализуемый. При этом не требует составления полного аналога дизассемблера. Тут достаточно определять размер команд в машинных кодах. Но все будет зависеть от сложности алгоритма анализа.
QtRoS
Конечно нет, учёные мужи бились над этой проблемой ещё в прошлом столетии. А иначе никто бы просто тесты не писал. Если я правильно понял вопрос, то он сводится к подзадаче https://en.wikipedia.org/wiki/Halting_problem
Попробуйте, может удастся решить, впишите себя в историю :)
panteleymonov
Очень сложно спорить с людьми утверждающие что что-то невозможно, основываясь на тривиальных научных терминах, в то время когда этим активно пользуются, в том или ином виде. Меня всегда удивляла такая упоротость.
QtRoS
Ещё раз — можно построить flame graph во время работы, можно построить граф вызовов по коду, но однозначно предсказать заранее глубину стека во время будущей работы — нет, нельзя.
P.S. Я думал у нас конструктивный разговор, а Вы теорему называете "тривиальным научным термином". В этом свете даже не так обидна моя "упоротость". Ловите заслуженный минус в карму.
panteleymonov
Вот вы сами со своими выводами спорите и хотите назвать это конструктивным разговором? А тем временем я ни где не конкретизировал «предсказание стека» — даже в такой формулировке ВОЗМОЖНЫЙ вариант стека, даже на уровне выше и ниже по вызовам метода, без каких либо данных (как часть дерева и каким либо другим образом), уже реализуемое решение. Но в ходе разговора я слышу только что — это не возможно. Какой тут возможен конструктив если вы, игнорируя реалии, все уже за меня додумали и решили?
Я же говорил о какой либо статистике! Опять же разговор о прогнозах или реальной работе все это уже реализовано как статически так и профайлерами.
Само по себе слово «предсказание» не требует ни какой точности лишь приближения к варианту работы. Но нет — это невозможно. А иначе как назвать такую зацикленность, на невозможности решения кроме как «упоротость»?
Сложности в реализации возможны для любой задачи, но кидать свое «профессиональное» «не реализуемо» в представлении только своего не реализуемого, не обозначенного и не обоснованного варианта — нет тут ни какого конструктива.
QtRoS
Предсказать и построить постфактум — в этом ключевая разница. Если ее учесть, противоречий в моих словах нет.
По поводу «додумали» — основывался на этом:
задал уточняющий вопрос:
Вы его не опровергаете, а задаете свой уточняющий к слову «невозможно»:
Соответственно я делаю вывод, что именно эту тему обсуждаем, а именно получение глубины стека без запуска, что в моем понимании является предсказанием.
Ок, уточню свою мысль — эту задачу корректно решить невозможно. Примерные эвристические алгоритмы могут существовать и неплохо работать на практике.
panteleymonov
У меня есть данные что метод «вызывался..» и «вызывал..», а соответственно построить листы этих последовательностей (уже имеющееся решение), и на основе этого я не могу получить ни какого предсказания. ЗАШИБИСЬ.
Ты понимаешь, что ты делаешь вывод о том что невозможно сделать анализ текста или бинарника! Сюда же можешь поставить в ряд, невозможность открытия файла в тотал командере.
Корректно это делает дебагер и то не каждый (возможно это вопрос так же и для дебагера), а не представленный мною алгоритм. И как я уже сказал это твое представление о корректности предсказания в твоей необхобимости решения задачи, о которой я не упоминал.
mayorovp
Нет, не кажется.
А какая тут связь?
panteleymonov
Передо мной целая статья об утилитах которые анализирует файлы, а мне только что сказали — «этого сделать невозможно». Да еще о том что связи, с тем что «открыть файл в тотал командере — невозможно», ни какой нет.
facepalm.
В рамках своих же восклицаний о «невозможности» могли бы представить случай когда доступ к файлу происходит несколькими программами.
И вы хотите от меня конструктивизма?
chemtech
sobolevn Спасибо за подборку.
heartrate — Простая визуализация выполнения вашей Python программы в реальном времени.
portray — Утилита для генерации документации из исходного Python кода.
sobolevn Автор
Поправил, спасибо!
unchase
Для меня удачной и своевременной находкой был Gitea — веб-интерфейс для работы с репозиториями git (очень похож на GitHub), который можно установить локально. Для тех, кто привык к GitHub, но хочет держать исходники на локальном сервере — отличная находка.
Vendict
Видимо их сайт словил Хабр-эффект, хорошая реклама
aXe1
Скорее РКН-эффект.
TL;DR: Они хостятся в Digital Ocean, и часть их IP-адресов заблокировано всякими разными инстанциями.
rgaliull
Который к тому же, в 10-15 раз легче GitLab
gecube
GitLab во многом сильно впереди. Тем более, если речь идет про коллаборативную работу.
(да, у gitea тоже есть плюс — она сильно легче по необходимым вычислительным ресурсам для работы)
Kanut
За npkill спасибо :)
rgaliull
а как же Sampler
mapcuk
А как же The fuck?
На github ~ 46K? между прочим!
aleki
rm -rf /он тоже исправит наsudo rm -rf /?iig
Для gcc нет такого же? :)
QtRoS
Ей сто лет в обед, а пост вроде про август.
ElvenSailor
хмм, идея отличная!
только вот когда оно не так исправит, и что-то с концами грохнет, будет не так прикольно)
BlindBillyJoe
Я думал заняться визуализатором процесса компиляции, чтоб смотреть за тем, как красиво твой код
некомпилируется, но всё руки не доходили.gecube
Посмотрел. Мое мнение нисколько не может считаться авторитетным, но пока мне начинает казаться, что JavaScript'еры извращенцы. Вместо того, чтобы пользоваться тем, что уже есть в других языках, они пытаются сделать JS лучше. То, что при этом придется тащить груз совместимости их не пугает. Касательно алгебраических эффектов — ну, похоже на callback'и (они даже в Си реализовывались с грехом пополам), только не нужно переписывать весь стек вызовов, т.е. интерпретатор добавляет эту фичу скрыто, но ценой еще меньшей эффективности интерпретируемого кода. Вот интересно — когда же мы остановимся в создании этих абстракций над абстракциями? Почему не попытаться взять более лучшие (ага) инструменты (типа Rust, Haskell etc.), а не "усовершенствовать" свой велосипед? Ответ у меня только тот, что перечисленные инструменты требуют квалификации для использовании. А на js — сел и начал писать код.