Про Аду еще не забыли?

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

Исключения в Аде появились раньше, чем в C++. Они были уже в стандарте 83-го года. Это была одна из продающихся фишек первого стандарта языка. Как поддержка исключений соотносится с безопасной средой исполнения кода? В Аде есть элементы GC? Там что-то было про подчищение памяти еще в стандарте 83-го года, но я уже давно все забыл.

Гарантируется ли в Аде безопасность на базовом уровне? Не может ли брошенное исключение привести к утечке или какому другому дефекту в памяти? Если нет, то как это соотносится со скоростью исполнения кода?

Возможно, что задам очень глупый вопрос. А в 2020 году есть шансы распространять закрытые либы для C++ в объектных файлах + необходимые хедеры для одной узкопрофессиональной ниши? Там C++ так-то используют во всю. Кто-то сейчас распространяет так либы?

Привязка к версии компилятора и к оси, в принципе, будет норм. Это не массовый продукт. Больше для R&D разных компаний и академии с уклоном в науку и производство. Может быть, вообще, нафиг никому не нужно будет)

Можно ли запустить программу, написанную на языке rust, на компьютерах с процессорами Эльбрус?

Как я понимаю, llvm не рассчитан на такую архитектуру. Правда, есть двоичная трансляция кода. Можно ли рассчитывать хотя бы на 80% скорости по сравнению с тем, как если бы был оптимизирующий родной компилятор с языка rust для Эльбруса?

Вопрос возник по языку Haskell. Допустим, у меня есть множество пакетов. Я хочу собрать это все в одну либу (DLL) статически так, чтобы либа не зависела от того, установлена ли среда Haskell на компьютере пользователя или нет. Максимум, что могу себе позволить - это динамическую компоновку с либой Sqlite3. Цель: дергать свою либу из сишного кода.

Интересуют варианты создания такой либы для версий Windows, Linux и макоси. Все системы важны.

Такое кто-нибудь проделывал? Какие есть подводные камни, кроме тех, что описаны в документации GHC? И нет ли подходящего туториала?

Нашел один туториал [https://www.fpcomplete.com/blog/2016/10/static-compilation-with-stack]. А есть ли еще?

В перспективе мне нужен будет обмен сообщениями в Rust между процессами кластера. Что-то в духе Эрланга, Akka или Cloud Haskell. Как понимаю, на системном языке уже имеет смысл использовать Open MPI. Что используется в Rust?

Пока нашел вот это:

https://github.com/andrewjstone/rabble

https://github.com/bsteinb/rsmpi

Как один из основных вариантов рассматриваю непосредственное использование Open MPI через код unsafe.

Для тех, кто не читает рассылку Haskell Cafe. Вышла новая версия платформы. Не все пакеты еще подтянулись. Например, svg-builder хандрит.

Ох, уж эти любители задавать точные границы для версий пакетов! Никогда их не понимал. Меня самого агитировали, но я отказался.

Спешу успокоить тех, кто далек от Haskell. В stack все работает, как и прежде работало.

Вопрос касается кода, скомпилированного с помощью -O2 -threaded и запущенного с помощью +RTS -N.

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

Тут понадобилась опция -threaded. И что я вижу: на алгоритмически однопоточном коде на процессоре Intel с двумя ядрами и гипертредингом нагрузка под 70% (от максимальной 100%) при использовании опций запуска +RTS -N. А потоков создается не меньше десяти! Как будто загружены 3 ядра из 4-х. Меня это удивило, мягко говоря. Подозреваю, что black holes имеют определенную стоимость в многопоточном коде, как и RTS.

Если взять тот же самый код, но без -threaded, то он отрабатывает на доли процента быстрее, с загрузкой всего 1 ядра и с 2-я потоками в окне Мониторинга Системы, где активным, скорее всего, является всего один поток.

Есть какие-нибудь оценки по этому поводу? На сколько ядер нужно рассчитывать про запас, чтобы, скажем запустить код с 4-я активными потоками, или с 8-ю?

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

Вопрос, а как добиться в латехе красивого русского текста?

Пакет cm-super установлен. Для английского языка, например, есть пакет с Palatino. Получается хорошо для этого языка. А с русским языком есть доступные шрифты? В принципе, могу и купить шрифт, если недорого

Глупый вопрос, но во что превратили старый добрый haskell-mode? Как вернуть удобный REPL и команду Ctrl-C + Ctrl-L?

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

На это можно взглянуть и с другой стороны. Просто появился очень хороший и веский повод взглянуть на поддержку haskell в atom

А как сейчас проще всего завести свой сайт? Какой хостинг? Где регистрировать домен и т.д.?

В принципе, мне подошли бы и бесплатные GitHub Pages, но как-то несолидно скрываться за адресом username.github.io

А то тут Го-дядя заломил цену в двадцать с лишним тысяч за апргрейд за непонятно что, где львиная доля пойдет на какой-то там простенький хостинг с PHP и MySQL, которые я не использую и не планирую в принципе, хотя с ними знаком. У меня, сейчас, вообще, статические страницы, сгенеренные по маркдауну. И я немного был обескуражен их предложением.

В идеале бы иметь возможность использовать свой собственный веб-сервер, но там точно будет что-то другое.

Спасибо!

Перемещено leave из web-development

Возник вопрос в выборе средства мониторинга (распределенного кластера). Присматриваюсь к SNMP, но что-то мне оно не нравится. Эдакое чудище из прошлого. Может быть, есть более интересные варианты?

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

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

Однако, меня интересует SNMP в плане применения в Haskell. Нашел два пакета на Hackage DB. Один из них даже попадал в Stackage. Только такое чувство, что пакеты слегка заброшены.

Почему еще возникает вопрос о поиске замены. Просто есть определенный опыт использования JMX, эдакой альтернативы SNMP, но для мира Java. И даже знаю один случай, где было написано собственное веб-ориентированное средство мониторинга со своим собственным протоколом, которое успешно используется до сих пор.

Так что принято использовать в 2017 году для мониторинга?

Вышла новая версия платформы 8.2.1 для Haskell.

Может быть, не так актуально, потому что сейчас многие используют исключительно Stack, но все же. Например, на платформе удобно разрабатывать библиотеки, которые потом можно использовать через этот самый Stack.

Если в Stack все библиотеки подобраны так, что должно всегда собираться, то в платформе попытка собрать, бывает, подобна хождению по минному полю. К сожалению, еще не все библиотеки собираются, но еще и суток не прошло со времени анонса! Нужно некоторое время подождать писателей библиотек. Пришлось откатиться на 8.0.2.

Так, не собралось gtk2hs-buildtools из-за hashtable. Но это больше вопрос к самим писателям библиотек. Обычно фиксится простой правкой зависимостей (не понимаю этой моды указывать верхние границы зависимостей - решает одну проблему, но создает другие).

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

А как принято у питонистов создавать документацию? Вот, создал и запостил я пакет. Теперь, как понимаю, нужно вручную запостить еще и документацию на http://pythonhosted.org

Вопрос. А какими обычно средствами из https://wiki.python.org/moin/DocumentationTools создается дока? Не слишком ли большой выбор?

Простейшие docstrings присутствуют.

Как в последнем Rust использовать следующую вещь?

#![feature(fnbox)]

Что где нужно прописать? Использую Cargo.

Так выходит, что без Box<FnOnce> просто никуда. Там, где можно было, заменил на Box<Fn>.

Выдает такие вещи:

error: use of unstable library feature 'fnbox': will be deprecated if and when `Box<FnOnce>` becomes usable (see issue #28796)

Что-то нашел вот про это, но не помогло:

#[warning(deprecated)]

Еще пытался в Cargo.toml прописать

[features]
fnbox = []

Но не понял, оно, не оно, но тоже не помогло.

Еще запускал как

$ cargo build --features fnbox

Тот же отрицательный результат.

Что делать?

Разыскивается компонент для вывода графиков (charting component). Желательно нативный, чтобы можно было или (1) подключить через FFI, или (2) вызвать как отдельный процесс, или, наоборот, (3) ненативный на JavaScript, да чтобы легко устанавливался простым копированием файлов. Должно работать на юниксах (linux, macOS) и, что особенно важно, на винде. На худой конец, здесь подошел бы и JavaScript, потому что у меня окончательный вывод идет через HTML.

Например, компонент из Qt мог бы подойти, а вот из миров Java или .NET сильно вряд ли. На счет питона очень сомневаюсь

Нужны обычные Time Series, XY Chart, Area Chart (для Deviation Chart), столбики (для гистограмм).

Вот, существует библиотека D3.js. Есть у кого-нибудь опыт работы с ней?

Насколько хорош стандартный компонент из Qt?

Еще один очень важный критерий. Графики должны быть красивыми, очень красивыми. Просто графики у меня уже есть

Приветствую!

Вопрос такой. А какие есть интересные области применения Apache Spark?

Ну, там обработка огромных логов с выискиванием закономерностей или обработка все приходящей информации с датчиков в поисках тех же зависимостей, что подразумевает, во-первых, большие данные (big data), а во-вторых, машинное обучение (machine learning). Еще можно придумать обработку в режиме реального времени каких-нибудь постов с twitter через streaming. Можно еще обрабатывать огромные распределенные графы, пытаясь уловить связи для какой-нибудь социальной сети. Только как-то это все несерьезно, что ли.

А что еще может быть интересного и полезного? Модная технология, только и слышишь везде big data почти также часто как про какие-нибудь микросервисы, но для чего это все может быть нужно? Добавьте ноток оптимизма, а то скепсис один остался!

Мне нужна такая структура данных, которая бы позволяла делать эффективно следующие две вещи. Эффективно в смысле, как минимум, со сложностью O(log n) относительно количества данных.

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

Второе. Эта структура должна позволять эффективно удалять заданный элемент по значению. Для определенности допустим, что существует отношение упорядоченности и для значений элементов, т.е. можно строить двоичные деревья со сравнением.

Сейчас есть хип (императивный или чистый функциональный - без разницы). На основе его легко строится эффективная очередь с приоритетами. Но вот, если вводить удаление полным перебором, то там сразу возникает сложность O(n), что совсем не комильфо.

Может быть, есть более эффективный способ? Что-то ничего умного в голову не лезет.

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

Это возможно сделать? LocalNode и forkProcess подойдут для этого, или LocalNode это просто такой узкий тип сети?

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

Оба процесса должны иметь тип Process, потому как один будет отсылать, а второй принимать сообщения. Поэтому простой форк IO не подходит.

Для дела нужно соорудить веб-сайт. В принципе, на первых порах можно ограничиться одной статикой, а потому Hakyll вполне жизнеспособный вариант для меня. Однако, интересуюсь и более гибкими решениями типа Yesod, snap и happstack. Испытываю дефицит времени. Поэтому обращаюсь сюда за советом.

Был ли у кого опыт работы с такими решениями?

Как они переживают перезагрузку сервера? Могут ли сами подниматься? Насколько это сложно или просто делается?

Есть ли для них готовые виджеты, например, для создания красивого меню?

Ну, и насколько дороже хостинг по сравнению с php, если веб-сервер написан на Haskell?

Предыстория. Написав более мегабайта кода на Scala, фактически в стол, для себя я решил, что Scala - не мой язык, хотя он и становится популярным. Лакмусовой бумажкой для меня служит то, что в Scala до сих пор нет адекватного сахарка для монад. Есть несколько вариаций, но ни одной полноценной с моей пристрастной точки зрения. Последнее, что видел из интересного, это плагин effectful, но спрашивается, какого черта они требуют зависимость от scalaz, что на мой взгляд губит на корню всю идею! В общем, Scala уже давно не вызывает прежнего восторга, который определенно был, когда я зачитывался книгой Одерского и компании. Для себя я уже все решил относительно Scala. Но иногда так хочется полноценного статически типизированного ФП на JVM…

И тут сегодня обнаружил прелюбопытную для себя вещь. Называется Frege. Позиционируется как чистый функциональный язык программирования для JVM в духе Haskell. И действительно, выглядит очень похоже. Немного расстраивает отсутствие MonadFix и рекурсивной нотации do, но я надеюсь, что они добавят эти вещи в скором будущем.

Что думает народ по этому поводу? Прошу высказываться.