⚡️ Google представил OSV-Scanner v2
Новая версия OSV-Scanner значительно расширяет возможности для разработчиков:
• Теперь сканируются проекты на .NET, Python, Java, JS, Go, Haskell — включая такие форматы, как deps.json, uv.lock, bun.lock, Uber Jars и др.
• Сводка по уязвимостям с фильтрами по критичности, пакетам, слоям в виде интерактивного HTML-отчёта
• Если вы используете Java с Maven, инструмент подскажет, как безопасно обновить уязвимые зависимости с минимальными рисками.
• Анализ образов Debian, Ubuntu и Alpine с определением уязвимых пакетов, историей слоев, идентификацией базового образа и фильтрацией ложных срабатываний
📌 Релиз
Новая версия OSV-Scanner значительно расширяет возможности для разработчиков:
• Теперь сканируются проекты на .NET, Python, Java, JS, Go, Haskell — включая такие форматы, как deps.json, uv.lock, bun.lock, Uber Jars и др.
• Сводка по уязвимостям с фильтрами по критичности, пакетам, слоям в виде интерактивного HTML-отчёта
• Если вы используете Java с Maven, инструмент подскажет, как безопасно обновить уязвимые зависимости с минимальными рисками.
• Анализ образов Debian, Ubuntu и Alpine с определением уязвимых пакетов, историей слоев, идентификацией базового образа и фильтрацией ложных срабатываний
📌 Релиз
GitHub
Releases · google/osv-scanner
Vulnerability scanner written in Go which uses the data provided by https://osv.dev - google/osv-scanner
🔥4🥰4👍3
⚡️ Перенос рекомендаций песен на Haskell
В статье рассказывается о переводе кода на F# в Haskell для задачи рекомендаций песен. Это часть серии о работе с разными языками программирования и функциональной архитектурой.
@haskell_tg
В статье рассказывается о переводе кода на F# в Haskell для задачи рекомендаций песен. Это часть серии о работе с разными языками программирования и функциональной архитектурой.
@haskell_tg
blog.ploeh.dk
Porting song recommendations to Haskell
An F# code base translated to Haskell.
👍7❤3🔥2
# 🧠 Haskell-задача с подвохом: “print vs lazy evaluation”
📘 Условие
Посмотри на следующий код:
❓ Вопрос:
1) Что напечатает эта программа?
2) Почему
3) Как заставить
---
✅ Подвох: ленивость вычислений
Haskell по умолчанию не выполняет вычисления, если результат не используется.
В результате,
---
✅ Пример вывода:
Хоть в
---
✅ Правильный способ — форсировать вычисление:
```haskell
import Debug.Trace
import Control.DeepSeq
main :: IO ()
main = do
let xs = [1..5]
let ys = map (\x -> traceShow x (x * 2)) xs
ys `deepseq` print ys
```
Теперь `traceShow` сработает **для каждого элемента**, потому что `deepseq` заставит Haskell **полностью вычислить список** перед `print`.
---
⚠️ Подвох
• `map` не вызывает функцию сразу — только когда элемент реально нужен
• `print` может не форсировать весь список
• Это вызывает недоумение у тех, кто ожидает «ленивость только в `IO`»
🎯 Отличная задача, чтобы проверить знание ленивости и управления побочными эффектами в Haskell.
📘 Условие
Посмотри на следующий код:
main :: IO ()
main = do
let xs = [1..5]
print (map (\x -> traceShow x (x * 2)) xs)
❓ Вопрос:
1) Что напечатает эта программа?
2) Почему
traceShow не ведёт себя так, как ожидается? 3) Как заставить
traceShow сработать для каждого элемента?---
✅ Подвох: ленивость вычислений
Haskell по умолчанию не выполняет вычисления, если результат не используется.
map просто создаёт ленивое представление списка. print вызывает show, но show на списках вызывает show только на нужных элементах при необходимости.В результате,
traceShow может сработать один раз или вообще не выполниться, если не происходит полного прохода по списку.---
✅ Пример вывода:
1
[2,4,6,8,10]
Хоть в
map был traceShow, только первый элемент срабатывает (или вообще никто — в зависимости от версии).---
✅ Правильный способ — форсировать вычисление:
```haskell
import Debug.Trace
import Control.DeepSeq
main :: IO ()
main = do
let xs = [1..5]
let ys = map (\x -> traceShow x (x * 2)) xs
ys `deepseq` print ys
```
Теперь `traceShow` сработает **для каждого элемента**, потому что `deepseq` заставит Haskell **полностью вычислить список** перед `print`.
---
⚠️ Подвох
• `map` не вызывает функцию сразу — только когда элемент реально нужен
• `print` может не форсировать весь список
• Это вызывает недоумение у тех, кто ожидает «ленивость только в `IO`»
🎯 Отличная задача, чтобы проверить знание ленивости и управления побочными эффектами в Haskell.
👍3❤2🔥2
🧠 Топ языков от евангелиста функционального программирования
Один из известных проповедников Haskell выложил свою субъективную классификацию языков программирования — от «святых граалей» до «цифровых окаменелостей».
Вот кратко по категориям:
Евангелист функционального программирования выложил свой рейтинг языков — и, как всегда, без компромиссов:
S: OCaml, C++
A: Haskell, Python, Rust, Kotlin
B: Scala, Go, Ruby, Swift, C#, TypeScript
C: PHP, Clojure, Java, C, Ассемблер
D: JavaScript, Bash
E: Fortran, Objective-C, COBOL, Perl
🍿 Комментарии уже взрываются — кто-то радуется за Kotlin в A, кто-то негодует за Java в C, кто-то вообще считает, что JS заслуживает отдельной категории «F».
А вот философский вопрос на подумать:
👉 Разработчики, которые всё ещё пишут на категории E — это уверенные мастера или уже цифровые археологи?
(Спойлер: COBOL-разработчики зарабатывают больше нас всех вместе взятых.)
#языкипрограммирования #fp #разработка #devюмор #tirlist
Один из известных проповедников Haskell выложил свою субъективную классификацию языков программирования — от «святых граалей» до «цифровых окаменелостей».
Вот кратко по категориям:
Евангелист функционального программирования выложил свой рейтинг языков — и, как всегда, без компромиссов:
S: OCaml, C++
A: Haskell, Python, Rust, Kotlin
B: Scala, Go, Ruby, Swift, C#, TypeScript
C: PHP, Clojure, Java, C, Ассемблер
D: JavaScript, Bash
E: Fortran, Objective-C, COBOL, Perl
🍿 Комментарии уже взрываются — кто-то радуется за Kotlin в A, кто-то негодует за Java в C, кто-то вообще считает, что JS заслуживает отдельной категории «F».
А вот философский вопрос на подумать:
👉 Разработчики, которые всё ещё пишут на категории E — это уверенные мастера или уже цифровые археологи?
(Спойлер: COBOL-разработчики зарабатывают больше нас всех вместе взятых.)
#языкипрограммирования #fp #разработка #devюмор #tirlist
❤4👍3🤡3👎1
Forwarded from Machinelearning
Метод преодоления "барьера сортировки" для задач кратчайшего пути в ориентированных графах.
Группа исследователей из университетов Синьхуа, Стенфорда и Института Макса Планика представили детерминированный алгоритм для решения задачи SSSP в ориентированных графах с неотрицательными вещественными весами, который работает за время, пропорциональное числу ребер, умноженному на логарифмический множитель, который растет медленнее, чем обычный логарифм.
Проблема поиска кратчайшего пути от одной вершины до всех остальных (SSSP) — одна из фундаментальных в теории графов, и её история тянется с 50-х годов прошлого века. Классический алгоритм Дейкстры, в связке с продвинутыми структурами данных, решает эту задачу за время, которое примерно пропорционально сумме числа рёбер и произведения числа вершин на логарифм от их же числа.
Именно этот множитель - число вершин, умноженное на логарифм, долгое время считался теоретическим минимумом, так как в своей основе алгоритм Дейкстры побочно сортирует вершины по расстоянию от источника. Этот предел известен как «барьер сортировки» и казался непреодолимым.
Алгоритм Дейкстры на каждом шаге выбирает из "границы" - множества еще не обработанных вершин ту, что находится ближе всего к источнику. Это и создает узкое место, так как размер границы может достигать величины, сопоставимой с общим числом вершин в графе, и на каждом шаге требуется находить минимум.
Алгоритм Беллмана-Форда, в свою очередь, не требует сортировки, но его сложность пропорциональна числу ребер, умноженному на количество шагов, что слишком долго.
Вместо того чтобы поддерживать полную отсортированную границу, алгоритм фокусируется на ее сокращении. А если граница слишком велика, то запускается несколько шагов алгоритма Беллмана-Форда из ее вершин.
Это позволяет найти точное расстояние до некоторой части вершин, чьи кратчайшие пути коротки. Длинные же пути должны проходить через одну из "опорных" вершин, которых оказывается значительно меньше, чем вершин в исходной границе. Таким образом, сложная работа концентрируется только на этом небольшом наборе опорных точек.
Он рекурсивно разбивает задачу на несколько уровней. На каждом уровне применяется вышеописанная техника сокращения границы, что позволяет значительно уменьшить объем работы на каждую вершину, поскольку логарифмический множитель эффективно делится на другой, более медленно растущий логарифмический член.
В итоге, путем подбора внутренних параметров алгоритма, которые являются специфическими функциями от логарифма числа вершин, и достигается итоговая временная сложность, пропорциональная числу ребер, умноженному на этот новый, более медленно растущий логарифмический множитель.
— Быстрее решаются задачи в навигации, графах дорог, сетях и планировании.
— Доказано, что Дейкстра — не предел, и можно ещё ускорять поиск кратчайших путей.
@ai_machinelearning_big_data
#AI #ML #Sorting #Graphs #Algorithm
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6❤2