Objective Caml - Вторник, 26 апреля 2011

Objective Caml

ocaml@conference.jabber.ru

Вторник, 26 апреля 2011< ^ >

gds установил(а) тему: Камль -- http://caml.inria.fr | Логи -- http://chatlogs.jabber.ru/ocaml@conference.jabber.ru/ | Светлое будущее -- http://camlunity.ru/ | Нефильтрованное настоящее -- https://github.com/camlunity/kamlo_wiki | Портер прошлое -- http://gdsfh.dyndns.org/kamlo/ | Верблюды грязи не боятся! | release crap, enjoy NIH | репортьте баги официальным дилерам | ocaml мёртв, move on

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

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

GMT+4
[00:10:43] komar вышел(а) из комнаты: Replaced by new connection
[00:10:44] komar вошёл(а) в комнату
[00:12:28] ftrvxmtrx вышел(а) из комнаты
[00:13:59] ftrvxmtrx вошёл(а) в комнату
[00:37:54] <gds> ermine: а ведь была какая-то шняга для вкомпилирования файлов в виде строк.  Вот такая: https://forge.ocamlcore.org/projects/ocamlify/ -- но не пробовал на практике и даже не смотрел.  Просто слышал.
[00:39:05] <Typhon> оно, кстати, для оасиса используется, вроде, не?
[00:39:07] <gds> Typhon: насчёт 0mq -- крут.
[00:39:17] <Typhon> во всяком случае, мне кажется, что помню их в депендансах
[00:39:28] <gds> про оазис не в курсе, но имя автора как бы намекает.
[00:40:15] <Typhon> gds, насчтёт змку  пока рано, толком не проверил всё (но репку в камлунити запилил ^_^ ). ещё мысли на перспективу -- как-нибудь внедрить в парвел опционально его (zmq)
[00:47:41] <gds> Typhon: zmq и без парвела будет офигенный.  Однако идея хорошая, ибо вот сейчас кое-какие вещи делаю внутри процесса, и натуральным образом ссу потерять сообщения.  Эдак можно сделать, если в текущих терминах, "сервер из 'i в 'o", который кормить из zmq с дальнейшей обработкой внутри камла там, где персистентность некритична.  В общем, сурово одобряю, если будет штука, имеющая: 1. внешнее хранилище сообщений, 2. по своей сути нетормозной движок/протокол, 3. lwt, 4. вменяемый автор (тебя считаю вменяемым однозначно).
[00:48:57] <Typhon> у zmq есть (будет) "девайс" для персистентного хранилища.
[00:50:07] <Typhon> вообще, есть какие-нибудь вопросы по zmq? 27 в москве meetup с шустриком (sustrik) -- могу поинтересоваться, если что-то интересует.
[00:52:21] <Typhon> (я не знаю, насколько правильно привязывать парвел к змку: с одной стороны -- много из коробки получится (см. zguide.zeromq.org), с другой -- лишняя зависимость, в т.ч. сишная (хотя на винде собирается вроде всё хорошо, кроме openpgm). ну и ипц неизвестно как там работает )
[00:52:38] Kakadu вышел(а) из комнаты
[00:56:48] <gds> видимо я что-то путаю, но вроде слышал про штуку, когда zeromq-сообщения хранили в постгресе, и даже на окамле писано было.
В общем, тут у меня те же проблемы, что и с остальным -- надо либо попользовать самому, либо у использовавших узнать, что к чему.
Но как-то предполагал, что zmq = штатное хранилище.
[00:59:47] <Typhon> не, это ocamlmq видимо, или stomp (mfp писал ocamlmq, там на лвт построено было). в zmq они по дефолту в памяти, с помощью setsockopt скидываются на диск, но после падения не восстанавливаются, и вот скоро будет или уже есть "девайс" (сокет с примочками) с персистентностью управляемой -- когда/сколько/как часто хранить.
[01:05:07] <gds> освежил в памяти, да, ocamlmq это был.  Всё остальное понял.
Кстати вот, каждый раз, когда я в последние пару недель думаю про персистентность, прикидываю, можно ли прямым образом привязать её к окамлу (сразу_идеас.мд).  По прикидкам, тут не получается, так как тут есть смысл открыть файл принципиально в режиме append, каждое сообщение писать одним write, периодически делать flush, а остальное -- уже излишние расходы.  Получается, эта задача не для on-disk datastructues.  Или где-то промазал?
[01:07:46] <Typhon> я бы персистентность для mq делал бы append-only файлом, да.
[01:08:37] <Typhon> именно очередь -- наверное под те сразу_идеас.мд не подходит, так как очереди нужно меньшее и дешевле
[01:14:32] <gds> ага, вот именно.  Надо вообще щупать идеи всяко.  "Триз", все дела (хз что это, но слово прикольное, и там про граничные условия).
[01:15:30] <Typhon> tries которые?
[01:16:19] <gds> а, вот как оно расшифровывается: http://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D0%BE%D1%80%D0%B8%D1%8F_%D1%80%D0%B5%D1%88%D0%B5%D0%BD%D0%B8%D1%8F_%D0%B8%D0%B7%D0%BE%D0%B1%D1%80%D0%B5%D1%82%D0%B0%D1%82%D0%B5%D0%BB%D1%8C%D1%81%D0%BA%D0%B8%D1%85_%D0%B7%D0%B0%D0%B4%D0%B0%D1%87
[01:17:32] <Typhon> а, ты про этот "триз" :-) я про http://en.wikipedia.org/wiki/Trie подумал ^_^
[01:35:50] gds вышел(а) из комнаты
[02:30:50] Typhon вышел(а) из комнаты
[03:27:39] bobry вышел(а) из комнаты
[03:34:34] bobry вошёл(а) в комнату
[08:14:01] iNode вошёл(а) в комнату
[08:57:30] gds вошёл(а) в комнату
[10:27:46] f[x] вошёл(а) в комнату
[10:40:48] gds вышел(а) из комнаты
[10:41:02] gds вошёл(а) в комнату
[10:41:41] ftrvxmtrx вышел(а) из комнаты
[11:34:08] ftrvxmtrx вошёл(а) в комнату
[11:38:52] Kakadu вошёл(а) в комнату
[11:47:03] <gds> выполз эдакий "паттерн" в message passing: есть какая-то абстрактная шняга, имеющая два канала (на запись запросов и на чтение ответов), обрабатывающая сообщения по одному (один запрос = один ответ).  Но надо ещё как-то состыковать запросы с ответами.  Надо, наверное, держать Queue.t с запросами "в пути", при отправке запроса делать push, при получении ответа делать take и возвращать тупл из запроса и полученного ответа, а при отвале шняги возвращать ошибку со списком посланного, на что не пришли ответы.
[11:49:47] <zert> это ты уже amqp делаешь?
[11:58:18] <gds> о, почитал про amqp.  Люблю хорошие ключевые слова.
[12:07:45] Typhon вошёл(а) в комнату
[12:32:52] ermine вошёл(а) в комнату
[12:38:15] <gds> кстати, хорошо, что я "параллельные N процессов" сделал без pre-spawn'а и относительно корректно в плане ошибок и подобного: теперь комбинатор "запустить пользовательский процесс по приходу сообщения и перезапускать при фейлах" эквивалентен "запустить не более 1 параллельных процессов".
[13:36:21] <f[x]> хм, много кто хочет кросс-камль - http://blog.invokk.net/2011/04/cross-compilation-in-ocaml-using-mingw/
[14:16:40] <gds> о, дошёл до нужды в том, что в эрланге называют "порт": процесс-примитив для общения с процессами ОС -- чанки с байтами и всё такое.  Думаю так: конструктор должен принимать аргументы: 1. что и как запускать, 2. какому процессу слать stdout/stderr процесса (и какой чистой функцией мапить чанки так, чтобы в родной для процесса тип обернуть их).  А принимать этот процесс должен чанки, которые в stdin пошлёт, и команды "закрываем stdin" и "прибиваем процесс".
По идее, относительно прилично должно получиться?
Не нравится только то, что у меня нигде ничего нет про гарантированный порядок доставки сообщений...  А надо бы как-нибудь учесть.
[14:30:08] iNode вышел(а) из комнаты
[14:47:30] iNode вошёл(а) в комнату
[14:57:01] <gds> какие же проблемы у меня с очередями: если предположить, что очередь резиновая, то никаких.  Если предположить, что нерезиновая, то кто-то очевидно будет блокироваться на записи в неё, если она заполнена уже.  И среди блокирующихся надо как-то вводить порядок сообщений, что не здорово.
Можно облегчить дело: указать, что порядок сообщений гарантируется лишь в пределах конкретного отправителя -- а именно, если один отправил сообщения a1 затем a2, а второй -- b1 затем b2, то порядки могут быть только a1a2b1b2, a1b1a2b2, a1b1b2a2, b1b2a1a2, b1a1b2a2, b1a1a2b2.
[15:01:33] <Typhon> gds: http://en.wikipedia.org/wiki/Vector_clocks — смотрел? или http://en.wikipedia.org/wiki/Lamport_timestamps если проще нужно. частичная упорядоченность в пределах одного отправителя — ок
[15:04:39] <Typhon> кстати, a1 и a2 когда отправляются, очередь уже полна? если полна, то при попытке отправить a1 процесс заблокируется же и не сможит итак отправить a2 раньше.
[15:04:53] <gds> vector clocks смотрел, и аж прибалдел, когда впервые понял их работу.
но туплю и не понимаю, как бы это реализовать в пределах lwt относительно эффективно.
[15:05:58] <gds> в текущей реализации -- родится две писаки (a1 и a2 в общую mvar), и кому шедулер даст, тот и первый.  Это печально.
[15:07:06] <Typhon> то есть "отправить соообщение в очередь" ни при каких вариантах неблокирующая, и "два подряд" сообщения можно отправить
[15:08:09] <gds> в текущем варианте put -- да, делал с расчётом на неблокируемость и на "пусть lwt само следит".  А новый put_blocking, который уже использую для process_limit, он блокируется до первого читаки.
[15:09:28] <gds> думаю, может заменить в mvar ту option 'a на Queue.t, неблокируемость делать до какого-то условного числа сообщений в очереди (666?  740?  глобальной настройки?  настройки per-process?), а дальше -- блокировать по-честному.
[15:14:38] <Typhon> по-моему, нужно не только "блокирующая после N", но и "дающая отлуп после N" очереди. и количество должно задаваться индивидуально ( если очереди создаются кем-то) или per-process, наверное.
[15:18:12] <gds> то есть, пока есть надежда, что процесс разгребёт очередь, блокировать, а дальше, если все уже видно, что сообщения набигают, то слать отлупы?
[15:20:29] <Typhon> хм, я сначала думал, про два варианта очередей, в зависимости от нужды, но вообще, наверное, можно двумя числами обозначать очередь — когда начинаем блокировать и когда отлупы давать
[15:22:30] <gds> я тут прикинул, может после определённого предела сделать вероятность отлупа, возрастающую по мере увеличения сообщений в очереди?  Изврат :)
[15:22:30] <Typhon> соот-но, можно создать очередь (X, 0) — которая будет после X сообщений всех нафиг слать. или как-нибудь (X, Some 0);  тогда (X; None) — очередь, которая всегда будет ставить на блок после Х и не будет ругаться
[15:24:20] <gds> или [ Unlimited | Block of int | Fail of int | Block_then_fail of int and int ]
[15:27:11] <gds> ещё вот что думаю.  Представим, что есть процесс на другом хосте.  С очередью не справляется, блок/фейл наступил.  Надо как-то протащить информацию об этом, чтобы те, кто ему шлёт, не парились особо, не сериализовывали сообщения заранее, а молча получили бы свой фейл или заблокировались бы тупо, не тратя в текущий момент память как на исходное значение, так и на сериализованное, ведь некуда его засунуть, даже если передадим по сетке.
[15:28:58] iNode вышел(а) из комнаты
[15:46:38] ftrvxmtrx вышел(а) из комнаты
[15:58:18] Kakadu вышел(а) из комнаты: Replaced by new connection
[15:58:19] Kakadu вошёл(а) в комнату
[16:53:09] <gds> во я даун, сразу сообразить не мог.  Многие годы мне нужно для разных вещей выставлять разное окружение, в том числе ввенде.  Писал разные "бантики"(tm), ставящие окружение и вызывающие какую-то фиксированную команду -- make %1, например.  И только сегодня сообразил, что достаточно везде (на всех нужных хостах) создать батник, доступный из любого проекта как ..\with-env.bat, содержащий "@call хост-специфичный-путь\set-vars.bat" и затем "%*", и спокойно запускать: ..\with-env make tests например.  Квотинг вероятно кривой получится, но это либо не важно, либо как-то исправляется.
[16:54:30] <f[x]> если бы в cmd был source..
[16:55:15] <gds> call по эффекту как source, а cmd /C -- как просто вызов.
[16:55:22] <gds> в плане окружения, имею ввиду.
[16:55:46] <gds> то есть, там, где есть оверблд, у меня были бантики
@call d:\overbld\ocaml\set-vars.bat
@make all
[16:56:03] <gds> и в set-vars.bat устанавливались PATH, CAMLLIB и прочее.
[16:57:08] <f[x]> call?
[16:57:10] <f[x]> хм
[16:57:35] <f[x]> тогда в самом деле
[16:59:02] <gds> кмд больше не калл
[17:22:05] gds вышел(а) из комнаты
[17:23:13] gds вошёл(а) в комнату
[17:23:44] <gds> плохо дело, что Lwt_sequence.length выполняется за O(n).  Получается, http://ocsigen.org/lwt/sources/src/core/lwt_mvar.ml?view=content надо переколбасить на другую структуру, хотя бы contents.writers, либо, скорее, завести поле "writers_count", которое поддерживать актуальным.  Это я прикидываю, по каким условиям отлупы слать.
[17:30:37] gds вышел(а) из комнаты
[18:12:25] gds вошёл(а) в комнату
[19:31:38] Kakadu вышел(а) из комнаты
[20:08:01] <gds> когда очередь полная, по идее, надо фейлить посылку сообщения с ошибкой типа MQ_Full, надеясь на то, что фейл подхватят "супервизоры", которые перезапустят и вообще позаботятся, так?
[20:22:32] Kakadu вошёл(а) в комнату
[20:22:43] Kakadu вышел(а) из комнаты
[20:22:59] Kakadu вошёл(а) в комнату
[20:49:20] Typhon вышел(а) из комнаты
[21:34:38] <gds> ещё проблемка в парвеле.  Команда Cmd `Shutdown, как бы намекающая процессу, что надо остановиться, является "асинхронной" и вообще, не обязательной к исполнению.  А каждый процесс выполняет какие-то важные дела, в теории.  Либо ждать остановки всех процессов (и иметь зависания, если кто-то не захочет выходить добровольно), либо переделывать команду в "синхронную" (не нравится), либо сделать функцию типа join, ждущую выбранные пиды (не нравится тоже, но лучше остального).
[21:55:55] Typhon вошёл(а) в комнату
[22:20:08] ygrek вошёл(а) в комнату
[22:20:22] ygrek вышел(а) из комнаты
[22:20:58] ygrek вошёл(а) в комнату
[22:44:14] Typhon вышел(а) из комнаты
[22:44:31] Typhon вошёл(а) в комнату
[22:53:16] <ermine> капчу provided by ocaml воткнули на сервер
[22:57:51] <gds> ermine: крута.  Где зазырить?
[23:00:07] <gds> про различия original vs revised -- написал сначала "func x = ...", потом удивился, что работает, потом решил проверить:
# type r = { func : string -> unit };;
type r = { func : string -> unit; }
# { func x = print_string x };;
Error: Syntax error
[...]
# #camlp4r;;
[...]
# type r = { func : string -> unit };
type r = { func : string -> unit }
# { func x = print_string x };
- : r = {func=<fun>}
[23:01:19] <Kakadu> gds: присоединись в какую-нибудь левую конфу и введи капчу
[23:02:08] <gds> видимо, я что-то не так делаю.
[23:02:51] <ermine> gds: ну вломиться в конфу, защищенную капчой
[23:04:00] <ermine> старая капча генерилась на основе convert из ImageMagick, которая часто падала в кору и много ресурсов жрала
[23:09:50] <ermine> gds: в оригинале у полей нет аргументов
[23:09:59] <gds> ога.
[23:10:12] <Typhon> ух ты, новая каптча мне прямо в гажиме показывается, а не ссылкой в приват кидается!
[23:11:20] <ermine> Typhon: не прошло и трех лет, как гаджим допоилили (прошло два года)
[23:16:50] <bobry> а у меня не показывается :(
[23:16:57] <bobry> Typhon, у тебя unstable версия?
[23:17:11] <Typhon> bobry, последние бинарники были
[23:17:14] <Typhon> (для виндовс)
[23:17:45] <Typhon> 0.14.1 ; оно, на самом деле, страшновато выглядит, когда прямо в окне
[23:19:46] <Typhon> (страшновато, в смысле -- пугающе)
[23:30:13] <Kakadu> знаете, гелиум заставляетт меня писать с "динамической" типизацией: я примерно понимаю как это должно будет выглядеть, я смотрб на типы, которые есть и методом тыка пытаюсь подобрать то, чт с компилируется
[23:35:28] <Kakadu> ура я понял как создать сервис с 1 параметром. Но как с 2мя - вопрос
[23:47:23] ermine только ас заметила лого на ocsigen.org
[23:47:51] <Kakadu> ermine: ну ты тиккурилля блин даешь
[23:48:27] <ermine> Kakadu: в elinks нету никаких баннеров
[23:48:36] <ermine> а щас зашла файрфоксом
[23:48:54] <ermine> "нарисуй сам лого"
[23:48:58] <Kakadu> ну тогда объяснила
[23:49:12] <ermine> надо стырить идею, чоль
[23:59:58] komar вышел(а) из комнаты: Replaced by new connection
[23:59:58] komar вошёл(а) в комнату