Objective Caml - Суббота, 23 апреля 2011

Objective Caml

ocaml@conference.jabber.ru

Суббота, 23 апреля 2011< ^ >

Конфигурация комнаты

Участники комнаты

GMT+4
[00:08:38] zert вышел(а) из комнаты
[00:20:48] Typhon вошёл(а) в комнату
[00:21:44] ftrvxmtrx вышел(а) из комнаты
[00:22:48] ftrvxmtrx вошёл(а) в комнату
[00:32:12] Kakadu вышел(а) из комнаты
[00:53:59] ygrek вышел(а) из комнаты
[01:42:31] ermine вышел(а) из комнаты
[01:49:57] Typhon вышел(а) из комнаты: Replaced by new connection
[01:50:00] Typhon вошёл(а) в комнату
[01:55:57] Typhon вышел(а) из комнаты: Replaced by new connection
[01:56:00] Typhon вошёл(а) в комнату
[01:59:13] Typhon вышел(а) из комнаты: Replaced by new connection
[01:59:16] Typhon вошёл(а) в комнату
[02:02:38] Typhon вышел(а) из комнаты: Replaced by new connection
[02:02:40] Typhon вошёл(а) в комнату
[02:07:51] Typhon вышел(а) из комнаты: Replaced by new connection
[02:07:53] Typhon вошёл(а) в комнату
[02:21:36] Typhon вышел(а) из комнаты: Replaced by new connection
[02:21:39] Typhon вошёл(а) в комнату
[02:35:11] Typhon вышел(а) из комнаты
[02:49:00] ftrvxmtrx вышел(а) из комнаты
[02:49:12] ftrvxmtrx вошёл(а) в комнату
[05:01:12] komar вышел(а) из комнаты: Replaced by new connection
[05:01:12] komar вошёл(а) в комнату
[11:34:52] ermine вошёл(а) в комнату
[11:36:08] <gds> удивительно, но сделать штуку "обрабатывать очередь сообщений не более чем N процессами, каждый со своей жизнью и с правом сдохнуть" поверх message passing -- это не так-то просто.  (при сдыхании процесс отправляет сообщение в очередь выбранному нами процессу, можно даже специально-выделенному для этой цели, но слабо помогает.)
[11:37:29] ygrek вошёл(а) в комнату
[11:53:58] <gds> вводить, что ли, очередям сообщений атрибут "сколько процессов читают из неё" либо вообще "список читающих"?  Чтобы не по сообщению типа `Exited, а по этому признаку смотреть, нужно ли рожать ещё процессы для обработки следующих сообщений.
[12:17:17] Typhon вошёл(а) в комнату
[12:47:27] zert вошёл(а) в комнату
[12:53:02] <Typhon> gds, не понял, зачем рабочим процессам умирать (а затем другим рождаться). как я себе это вижу (через csp-призму). есть очередь (канал).  рабочие процессы выглядят как-то так:
try loop (fun () -> read queue >>= do_actual_work) with NoMoreMessages -> suicide.
тогда сначало спаунится N процессов и они в этих циклах читают мессаги и работают с ними. тогда больше N процессов не сможет работать с очередью, никаких спецсигналов и флажков делать не придётся вроде. такое ложиться в модель ?
[12:54:50] <Typhon> queue, теоретически, может быть процессом, который принимает Get of source_pid и шлёт туда следующую мессагу из очереди.
[13:27:36] <gds> Typhon: 1. процессы могут сдыхать -- а хочется эрланговский let it crash воплотить хотя бы частично, 2. не хочется рожать сразу стопиццот процессов.  (а в будущем -- хочется убивать убивать убивать, когда, например, >= 3/4 процессов пинают балду.)
[13:32:48] <gds> впрочем, сдыхающие процессы можно обработать так: выродить отдельно "монитор", который на каждый сдохший процесс будет рожать нового.  (за сдохшими нормально следить умею уже -- Cmd (`Exited (pid, status)) шлётся.)
[13:33:29] <gds> теперь осталось прикинуть, как определять, нужно ли рожать ещё один процесс и можно ли убить кого-нибудь.
[13:35:26] <gds> объясню, зачем мне "let it crash" вообще сдался: думаю про то, что некоторый код будет апгрейдиться по-разному, и будут моменты, когда между процессами идут сообщения как бы разных типов.  в результате получателю сообщения проще сдохнуть, подождав, пока либо его, либо отправителя проапгрейдят на правильную версию сообщения.
[13:43:42] <ygrek> сдыхать будут по-любому
[13:44:03] <ygrek> мир то не идеальный, баги в сишных либах, oom-киллер, железо
[13:44:40] <gds> вот-вот.  и порой проще переоткрыть транзакцию в БД (откатив / не фиксировав старую, понятное дело), чем пытаться восстановить всё это по всем правилам.
[13:48:12] <gds> прикидываю эти "параллельно, но не больше", и думаю, что "selective receive" был бы очень в тему.  но его долго кодить.
[13:59:22] bobry вышел(а) из комнаты
[14:22:11] ftrvxmtrx вышел(а) из комнаты
[14:25:47] <gds> в случае, когда уже запущено N процессов и каждый работает над своим делом, надо наверное как-то притормозить приём новых сообщений, чтобы по памяти не загнулись.  Сделать, что ли, функцию для блокирующей постановки сообщения в очередь?  Чтобы выходила тогда, когда сообщение реально кто-то возьмёт.  Если такое будет, то можно будет сделать отдельный монитор, делом которого будет реагировать "вышел рабочий -- надо запустить нового", и количество рабочих будет поддерживаться, и очередь в памяти не будет расти.
Альтернатива для "не загнуться по памяти" -- иметь очередь фиксированного размера и слать отлупы в случае её переполнения.  Но это мне не очень нравится, как-то ненадёжно.  Или нет?
[14:58:45] ftrvxmtrx вошёл(а) в комнату
[15:12:56] <gds> http://paste.in.ua/2206/ -- прошу, поглядите, нормальный ли алгоритм для "не более N процессов".
[15:13:59] <zert> gds: http://www.ideone.com/Se7Gv
[15:15:56] <gds> zert: MaxOutstanding отрубает лишние ждущие процессы (ждущие, пока остальных будет <= chan)?
[15:16:22] <zert> ага
[15:16:25] <zert> это golang
[15:16:59] <gds> семафор -- это ок, я понимаю.  Главное -- чтобы сдыхающий процесс его отпустил ещё.
[15:17:14] <gds> но ты подкинул идейку -- гуглю по "semaphore over message passing"
[15:17:40] <Typhon> distributed semaphore
[15:18:02] <gds> тоже пошёл искать.
[15:18:32] <zert> посмотри вообще на golang в целом, может ещё чего интересного найдёшь
[15:18:49] <zert> перспективный язык, вощемта
[15:19:09] <gds> это гугловский который, или что-то другое?
[15:21:42] <zert> да
[15:22:03] <zert> системные вещи на нём писать очень хорожо
[15:23:08] <gds> "Distributed Semaphores   Mahendra Ramachandran and Mukesh Singhal"
страшно.
[15:26:28] komar вышел(а) из комнаты: Replaced by new connection
[15:26:28] komar вошёл(а) в комнату
[15:30:43] <gds> посмотрел про distributed semaphores -- сложно, и их сводят к paxos.  пока не очень хочется, тем более, задача проще.
однако у меня пока непонятно, к чему всё идёт, поэтому от имплементации (от lwt в данном случае) стараюсь требовать поменьше.  И поэтому думаю, стоит ли вводить в список требований операцию "блокирующая отправка сообщения в данную очередь" (то есть, отправка до тех пор, пока его не прочитает хоть кто-нибудь -- а в моём алгоритме это будет только тогда, когда монитор будет поддерживать не менее N процессов живыми).
[15:32:12] <gds> * то есть, отправка _с последующей блокировкой_ до тех пор, пока его не прочитает
[15:35:45] <Typhon> блокировка в смысле, что нельзя положить ещё или процесс просто блокируется и ничего не делает? если первое, то это МВар, кажется, а если второе -- то это мне странно.
[15:37:10] <Typhon> и если имелся ввиду мвар или что-то подобное, то такое может понадобиться
[15:47:24] bobry вошёл(а) в комнату
[15:52:43] <gds> Typhon: так вот, я как раз Lwt_mvar взял для реализации очередей.  Неблокирующая отправка у меня выглядит как Lwt.ignore_result (Lwt_mvar.put mq val).  Криво, но хотел самое тупое реализовать пока что.  Так вот, блокирующая отправка -- вполне таки Lwt_mvar.put mq val.  Вот там, где M>=N, и хочу использовать её.
[15:58:08] <gds> но вообще криво это.  Может сразу нормальную очередь оформить там?..  С другой стороны, не знаю, какую и как.  Взять тупо Lwt_mvar, заменить там contents : option 'a на Queue.t 'a, и переделать матчинг поверх contents так, чтобы клало без блокировки пока длина очереди меньше 9000, а в остальное время отлупы давало?  Или блокировалось?  Хрен знает.
[15:59:38] ygrek вышел(а) из комнаты
[16:11:51] Kakadu вошёл(а) в комнату
[16:14:15] komar вышел(а) из комнаты: Replaced by new connection
[16:14:15] komar вошёл(а) в комнату
[16:39:03] <gds> вот что интересно: понятие "блокироваться" нормально вписывается только в локальные очереди сообщений.  По сети же оно как-то странно выглядит.  Либо явный отлуп, либо tcp/ip-соединение, по которому как бы начали посылать сообщение (послали pid адресата, например), но само сообщение либо ещё не послали, либо послали и там его приняли, но на него не получили ответа типа "всё дошло ок", и висим-ждём.  А без блокирования -- не знаю, как сделать более-менее надёжно в локальном случае.  С очередями фиксированного размера получится так: если будет дофига сообщений внезапно, то только часть из них попадёт в очередь, а остальное проигнорируется.  Криво же.
[17:44:47] komar вышел(а) из комнаты
[17:50:22] komar вошёл(а) в комнату
[18:31:36] <Kakadu> komar: а если тебе надо породить яваскрипт, то ты пишешь файл .eliom или генеришь js-файл отдельно?
[18:42:31] <komar> Э-э?
[18:42:34] <komar> Я пока пишу руками.
[18:42:48] <Kakadu> ага, понятно
[18:43:36] <Kakadu> может ещё знаешь... пример miniwiki должен генерить html из вики формата или нет?
[18:48:16] <komar> Было бы неплохо.
[19:06:03] Kakadu вышел(а) из комнаты
[19:07:03] Kakadu вошёл(а) в комнату
[19:16:22] ygrek вошёл(а) в комнату
[19:16:37] ygrek вышел(а) из комнаты
[19:17:01] ygrek вошёл(а) в комнату
[19:38:06] komar вышел(а) из комнаты
[20:13:11] ygrek вышел(а) из комнаты
[20:26:20] <gds> возникла нужда поставить под gentoo всякое там камло.  с более-менее стандартным вопросов нет, нужное нашлось, а вот своё локальное говно куда ставить -- это для меня загадка.
Пока выродил юзера+хоумдиру, планирую компилировать там, ставить локально (куда-то под /home/myuser/site-lib/...), однако не уверен, что 1. это самый прямой путь, 2. всё будет ок, если софтина захочет загрузить какую-нибудь из длл, расположенных в /home/myuser/site-lib.
Может лучше не мучиться и ставиться системно, sudo ocamlfind install и все дела?
[20:33:29] <Typhon> я бы сделал пользователь kamlo, папку для него /opt/kamlo, и туда ставил и камло и все пакеты, включив себя в группу. но жду ответа от f[x] %)
[20:35:26] <gds> а как с ocamlfind жить-быть?  а с байткодом, грузящим длл чуть что?
[20:37:09] <gds> хотя вот, думаю, может в оверблд обновить камло до упора, пофиксить то 3.12-специфичное, что вылезет под линуксом, а потом уже думать про венду?..  Прикину, но остальные варианты интересны тоже.
[20:40:24] <Typhon> а с окамлфинд что должно быть? у меня на убунте сейчас почти так, и всё ок. для длл LD_LIBRARY_PATH поставил для своего пользователя. у пользователя kamlo всё должно итак ок быть. (хотя может пути прописать тоже придётся).
[20:44:37] <gds> бинарники будут запускать от разных юзеров, потому и ссыкотно.  Системно прописать LD_LIBRARY_PATH -- вариант.  Или OCAML_LD_.., вроде что-то такое было.
[21:04:47] Typhon вышел(а) из комнаты
[21:58:46] <ermine> будет ли с моей стороны наглостью импортировать в camlimages собственные биндинги?
[21:58:59] <ermine> ну, в свой форк
[21:59:48] ermine перебиндила freetype2
[22:02:00] <gds> предполагаю, что это даже очень круто.  следовательно, не "нагло", а максимум "дерзко" :]
[22:05:58] <ermine> хе
[22:40:07] komar вошёл(а) в комнату
[22:53:34] <gds> подскажите пожалуйста, кто ахтунг: французы, svn-с-тарболами или я?
из http://caml.inria.fr/cgi-bin/viewcvs.cgi/ocaml/version/3.12/ взял "Download tarball", смотрю его (cat | gunzip | tar -tv):
-rw-r--r-- viewcvs/viewcvs   43538 2010-06-04 14:01 3.12/config/gnu/config.guess
конечно, в сраном ./configure стоит сраное
if host=`../gnu/config.sub $host_type`; then :; else
В общем, если конструктивно: как взять свежую версию с правильными атрибутами файлов?
[22:57:25] <gds> ещё плюс окамла: есть люди (наподобие меня), которым неплохо бы закидывать в голову кучу разных-разных проблем, они там варятся себе в фоновом обдумывании, и жизнь интереснее (есть всегда о чём подумать, а то и не одно), и по сумме производительнее, чем одну-две проблемы решать за раз (проверял).  Сейчас порядка пяти различных проблем, все как-то связаны с окамлом.  Как же мне хорошо.
[23:13:18] <ftrvxmtrx> :))
[23:15:18] <bobry> многозадачность в действии :)
[23:15:24] <ftrvxmtrx> действительно, с окамлом как-то интереснее обдумывать какие-то задачи
[23:16:16] <zert> а с ерлангом не интересно ничего обдумыват
[23:16:19] <ftrvxmtrx> особенно осознавая, что на других языках их решать -- уныло и неинтересно
[23:16:35] <zert> я вот сегодня мог бы чего-нибудь пообдумывать, а вместо этого пошёл пить пиго с поцонами
[23:16:59] <gds> многозадачность -- факт.  Измерял по количеству сделанного (в попугаях, конечно).  Про печальные выводы о рабской психологии не буду, но вообще порядка 3..4 задач за раз -- около оптимума.
[23:18:21] <gds> с окамлом интересно обдумывать, да, но бывает так, что сам окамл ставит эти задачи.  Я как бы про это.  Но, факт, на многих других языках было бы слишком уныло.
(а там, где не уныло, нужно было бы профайлер расчехлять, по статистике.)
[23:18:54] <gds> zert: так правильно, шаббат же.
[23:19:15] <zert> ш-батъ
[23:19:24] <zert> в к-нун на п-йсахъ
[23:20:41] <gds> пейсах вроде чуть раньше был, по слухам, во вторник где-то.  Но это не должно мешать кушать мацу с салом.
[23:21:12] <zert> сало кошерное, одобрено раввинатом
[23:23:50] Kakadu вышел(а) из комнаты