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

Rescue не поможет от падения ноды

> Ага, допустим что выполнение задачи завершилось неудачей и даже привело к падению ноды всегда есть возможность обработать неудачное завершении задачи не доводя до падения ноды

Ага, допустим что выполнение задачи завершилось неудачей и даже привело к падению ноды. Нода рестартовала. По-хорошему нужно ещё раз повторить выполнение задачи, ведь предыдущее не завершилось успешно. Как быть?

только класть задачи в бд

> Anatoliy Kovalchuk: > всегда есть возможность обработать неудачное завершении задачи не доводя до падения ноды Нет конечно. Ошибка в nif-е и всё.

только класть задачи в бд

в принципе, никак иначе падение ноды не переживается

идеальных решений не бывает, если есть приложение которое постоянно падает виртуальная машина от segfault то хранить что-то ценное в памяти не стоит

ничего не стоит хранить в памяти

действительно, PHP forever!

Не настолько уж, но в этом что-то есть.

Стейт в памяти препятствует горизонтальному масштабированию и отказоустойчивости.

Какие-то кэши можно и нужно держать, но даже с ними уже возникают проблемы

Кто нибудь в brunch подключал react?

я подключал

там вроде в официальных примерах всё просто

Короче вот мое жалкое поделие AVL-деревца. Английский корявый, доков нет. Короче, говнецо начинающего эликсириста, но может кому пригодится: https://github.com/japplegame/avl_tree

чот неправильное позиционирование репы) лучше писать, мол, вот реализация AVL-дерева, опенсорс MIT-лицензия (или BSD какая-нить), можно расширять при необходимости, пулл реквесты приветствуются.

А так звучит как будто предложение, мол, кто гурман, вот тут можно навернуть говнеца =)

Я стесняюсь

не надо стесняться! все так делают! :)

Вот реализация крутого бинарного дерева поиска. Самий мощний риализация во всем интернете и гитхабе в частности. Доки не нужны, можно расширять и сужать при необходимости и без таковой, Массачусетусецкастая лицезия или как там ее, в общем что хочу то и ворочу.

Может стоит по скорости с gb_trees сравнить?

ну оно сливает в семь раз обычному MapSet

Вот реализация крутого бинарного дерева поиска. Самий мощний риализация во всем интернете и гитхабе в частности. Доки не нужны, можно расширять и сужать при необходимости и без таковой, Массачусетусецкастая лицезия или как там ее, в общем что хочу то и ворочу.

всё так. :)

добавляем блокчейн. делаем ICO, и сваливаем с деньгами в Аргентину

правда на числах, на туплах разница в производительности сильно падает

а разве gb_trees позволяет кастомную функцию сравнения? Она, по-моему и есть источник главных тормозов

добавляем блокчейн. делаем ICO, и сваливаем с деньгами в Аргентину

главное блокчейн!

Надо лицуху сменить на еще более открытую, public domain, чтобы даже копирайты не нужны были

Может стоит по скорости с gb_trees сравнить?

http://joxi.ru/KAxYjVNS4NwxMr?d=1 хехе

ага я читал

даже откопал доку по этим GB Trees этого профессора, там как-то запутано и сложно все - забил

для меня, главная фишка - кастомная функция сравнения, небольшая просадка по производительности ваще не волнует

а с этим парнишкой бенчмаркал https://gist.github.com/JohnAZoidberg/87dd44c1281ffb654ff64464f9cc85ab ?

поймал себя на мысли что не понимаю что тут происходит http://joxi.ru/8AnzBGOUq3KlMA?d=1

(((

аааа

=)

теперь понял

большое вращение влево видимо

Матчится сначала структура потом возвращается другая)

дада

я вначале подумал что это одно действие

и сильно озадачился что за магический синтаксис

Я чёт не понял, зачем нужно если есть gb_set

В коробке из под OTP

повторяю КАСТОМНАЯ ФУНКЦИЯ СРАВНЕНИЯ

иначе есть MapSet и просто Map

И зачем она нужна?

И зачем она нужна?

Ты не поверишь - для кастомного порядка элементов

или для сложного поиска

Всю жизнь делал кастомные порядок элементов за счёт отображения данных на первый элемент тупла в gb_set

Ну, наверное тебе виднее

не всегда это удобно

сравнивается все равно по внутренним правилам

и накой gb_set, если есть Map?

set это set

А map - это map

Так что вопрос странный

Ну пусть будет MapSet

Или MapSet не гарантирует порядка (хотя судя по всему по-факту сортирует)?

у меня просто замороченное сравнение, не хочу городить сложные отображения, проще функцию накидать

Map set - это hash set

А gb_set - это binary tree set

Какая разница в них - ну наверное в универе изучают

чем hash-таблица отличается от бинарного дерева, я знаю

В тех программах, которые пишу я обычно это не важно

hash set требует чтобы элементы поддерживали вычисление хеша и операцию == а бинарное дерево требует только операцию <

ну и хеш-таблица никакого порядка не гарантирует, а бинарное дерево гарантирует

Короче, кому надо - используйте, а кому не надо - тому не надо. :)

Наверняка внутри ets хеш таблица, или дерево

Или и то и другое

И возможно на c++

а эти ваши gb_set и gb_tree позволяют хотя бы в обратном порядке элементы листать?

Хз, ну посмотри

и как написать отображение для обратного порядка, например, строк?

строки, которые нужно отсортировать в порядке убывания. Или туплы из пары строк, в которых первый элемент в порядке убывания, а второй в порядке возрастания?

тут-то и пригодится кастомная функция сравнения

Да, вот только в таких случаях обычно используют hash set

avl деревья же используются для поиска элементов, причём тут сортировки?

получи список элементов из него (или храни отдельно) и сортируй как душе угодно

Да, вот только в таких случаях обычно используют hash set

хэш-сет ничего не сортирует

Так сортируют для того, чтобы быстрее искать

Зачем ты вообще сортируешь?)

Так сортируют для того, чтобы быстрее искать

ага в том числе и диапазоны, скажем кусок больше чегото и меньше чего-то

Зачем ты вообще сортируешь?)

я сортирую для быстрого поиска, но хеш-таблица тоже требует функцию сравнения (==)

получи список элементов из него (или храни отдельно) и сортируй как душе угодно

точно, получи список из 100к элементов и сортируй. :)

точно, получи список из 100к элементов и сортируй. :)

да, согласен, неэкономно

Есть ets, ordered_set.

Вопрос в том, насколько быстрее сразу сделать ключи в правильном сортируемом формате по сравнению с тем, чтобы использовать кастомную функцию?

Все случаи, что я встречал - обычно сделать ключ таким(привести к такому), чтобы нативная Erlang сортировка работала - вполне достаточно.

А так звучит как будто предложение, мол, кто гурман, вот тут можно навернуть говнеца =)

прикольно))

а куда положено скидывать файло которое нужно будет в рантайме и как узнать полный путь к этому файлу в рантайме же?

надыбал :code.priv_dir но он дает путь в папке _build

при компиляции содержимое папки priv копируется вроде и вставляется рядом с скомпилированными файлами, поэтому можно использовать эту функцию, а путь джойнить

Path.join(:code.priv_dir(:app_name), "filename")

а точно. символическая ссылка создается

про джойн я знаю

спасибо