Пробовал. Картина не менялась. Но ждать было лениво.
Если получится что-то иное дай знать.
Но опять же, все может зависеть от версии.
Правда, на память особого внимания не обращал.
влияние сложности алгоритмов небольшое
Так это просто тест конкатенации.
И меня более интересовало представление строк.
О каких алгоритмах речь?
Отметим два неочевидных обстоятельства. Во-первых, нельзя запустить loop() перед spawn_link(). Казалось бы, так будет более надежно, т.к. функция-слушатель, запущенная до запуска потока-исполнителя, наверняка не пропустит ни одного сообщения от этого потока. Но опыт показывает, что в этом случае функция-слушатель вообще не получает сообщения от потока-исполнителя. По-видимому, это связано с тем, что статус отношения потоков не обновляется.
Там большая проблема это права на сами тексты, а не на их разметку.
В веб-выдаче они все равно с нарушенным порядком предложений, и сами произведения перемешаны. Автоматизировать разрешенные действия — сомневаюсь, что в этом есть что-то противозаконное. Блокировка по ip они делают все скорее для защиты от чрезмерных нагрузок.
На тему лицензий, если уж совсем серьезно, то про них ничего вообще не сказано.
А потом, какой закон, и какую конкретно статью нарушит некто, решивший таки такое опубликовать в каких-то своих никому неведомых целях?
Думаю, тут скорее действует профессиональная этика что-ли.
С НКРЯ можно попробовать расправиться через краулинг ответов с высокочастотными словами.
Правда после тысячного запроса, клиент банится по IP.
До какого-то момента я с ними возился. Но потом это все надоело.
+ У них есть серьезная проблема с интерфейсом. Иногда оно зависает и пытается выдать много одинаковых ответов на одну и ту же страничку. Много — в смысле, очень очень много. При попытке воспоизвести это в браузере привело к его падению. Хорошо, что такое поведение не регулярно.
Я не уверен, что современные sql-базы настолько примитивны. Никто не отменял отложенных записей, никто не отменял балков (говорил, же, что, все таки, неудобно).
+ Если и на диск (в чем я крупно сомневаюсь), то смотря какой диск.
Если интересно, могу свести с человеком который непосредственно этим занимался.
как эрланг начинает захлебываться (вероятно сообщениями)
Чтобы этого не было, можно попробовать, подкрутить (уменьшить?) число редукций на процесс. Но это грязно. Ну или разбирать конкретный случай, чтобы в очередях было минимальное число сообщений, и всеони пролетали очередь.
+ Сталкивался с проблемой числа файловых дескрипторов на процесс ос, но тут возможно это непричем.
В этом случае, он просто откажется выполнять библиотечные функции.
***
Горизонтально смаштабировать можно и без erlang, было бы на чем масштабировать. Как было сказано выше, мнезия только для мелких порций в малом количестве.
Пробывал redis и leveldb как альтернативу, но что-то с ними как-то не сложилось.
Есть и много других проблем.
1) При нескольких млн записях в секунду начинает резко падать скорость. Конечно можно разносить по машинам и балансировать нагрузка. Но количество машин ограничено.
2) Начинаются тормоза при двух млдр мелких записей в базе, даже когда скорость не сильно критична, такие тормоза раздражают.
Потому от mnesia мы отказались в пользу postgres. Гетерогенно и неудобно, но головной боли меньше.
Хотя бы на первых порах.
Декларативность, что ли.
Ну во общем это не к Erlang, а к функциональным языкам.
Если получится что-то иное дай знать.
Но опять же, все может зависеть от версии.
Правда, на память особого внимания не обращал.
влияние сложности алгоритмов небольшое
Так это просто тест конкатенации.
И меня более интересовало представление строк.
О каких алгоритмах речь?
Если заюзать мемоизацию, то лучше писать, по определению, имхо.
lists:reverse — раньше брезговал, но
lists:flatten — убийство.
[List1, List2], в зависимоти от целей erlang:list_to_binary
Откуда это все?
+ Какая альтернатива?
--> Можно, конечно, вложенные списки, но без опыта функ про осознать не просто.
Ну или какую-то часть словаря.
В веб-выдаче они все равно с нарушенным порядком предложений, и сами произведения перемешаны. Автоматизировать разрешенные действия — сомневаюсь, что в этом есть что-то противозаконное. Блокировка по ip они делают все скорее для защиты от чрезмерных нагрузок.
А потом, какой закон, и какую конкретно статью нарушит некто, решивший таки такое опубликовать в каких-то своих никому неведомых целях?
Думаю, тут скорее действует профессиональная этика что-ли.
Результатом стало вот это:
www.slideshare.net/w-495/dsmts-diploma
В конце концов, я же никого не хакнул, а просто автоматизировал получение доступной информации.
Да ладно, писать краулер самому и парсить все это через html5lib было интересно.
Я в частности крайне жду параллельных многоязычных корпусов.
Правда после тысячного запроса, клиент банится по IP.
До какого-то момента я с ними возился. Но потом это все надоело.
+ У них есть серьезная проблема с интерфейсом. Иногда оно зависает и пытается выдать много одинаковых ответов на одну и ту же страничку. Много — в смысле, очень очень много. При попытке воспоизвести это в браузере привело к его падению. Хорошо, что такое поведение не регулярно.
Кстати, а вот это отрабатывает корректно:
+ Если и на диск (в чем я крупно сомневаюсь), то смотря какой диск.
Если интересно, могу свести с человеком который непосредственно этим занимался.
Чтобы этого не было, можно попробовать, подкрутить (уменьшить?) число редукций на процесс. Но это грязно. Ну или разбирать конкретный случай, чтобы в очередях было минимальное число сообщений, и всеони пролетали очередь.
+ Сталкивался с проблемой числа файловых дескрипторов на процесс ос, но тут возможно это непричем.
В этом случае, он просто откажется выполнять библиотечные функции.
***
Горизонтально смаштабировать можно и без erlang, было бы на чем масштабировать. Как было сказано выше, мнезия только для мелких порций в малом количестве.
Пробывал redis и leveldb как альтернативу, но что-то с ними как-то не сложилось.
1) При нескольких млн записях в секунду начинает резко падать скорость. Конечно можно разносить по машинам и балансировать нагрузка. Но количество машин ограничено.
2) Начинаются тормоза при двух млдр мелких записей в базе, даже когда скорость не сильно критична, такие тормоза раздражают.
Потому от mnesia мы отказались в пользу postgres. Гетерогенно и неудобно, но головной боли меньше.