Objective Caml - Понедельник, 28 декабря 2009

Objective Caml

ocaml@conference.jabber.ru

Понедельник, 28 декабря 2009< ^ >

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

GMT+3
[00:33:41] ermine вышел(а) из комнаты
[01:07:06] Typhon вошёл(а) в комнату
[01:07:25] gds вышел(а) из комнаты: Replaced by new connection
[01:07:26] gds вошёл(а) в комнату
[01:18:39] Kakadu вышел(а) из комнаты
[01:40:37] ygrek вышел(а) из комнаты
[01:49:02] gds вышел(а) из комнаты
[02:23:59] Typhon вышел(а) из комнаты
[07:44:27] geovit вошёл(а) в комнату
[07:46:39] iNode вошёл(а) в комнату
[08:18:01] Typhon вошёл(а) в комнату
[09:00:51] gds вошёл(а) в комнату
[09:18:33] geovit вышел(а) из комнаты
[09:26:41] geovit вошёл(а) в комнату
[10:03:24] ygrek вошёл(а) в комнату
[11:22:27] animist вошёл(а) в комнату
[11:44:57] ermine вошёл(а) в комнату
[11:47:30] f[x] вошёл(а) в комнату
[11:55:50] ygrek вышел(а) из комнаты
[11:57:54] sceptic вышел(а) из комнаты: Replaced by new connection
[11:58:02] sceptic вошёл(а) в комнату
[12:00:01] sceptic вышел(а) из комнаты: Replaced by new connection
[12:00:10] sceptic вошёл(а) в комнату
[12:10:53] sceptic вышел(а) из комнаты
[12:11:01] sceptic вошёл(а) в комнату
[13:05:25] geovit вышел(а) из комнаты
[13:07:14] AKos вошёл(а) в комнату
[13:19:01] ygrek вошёл(а) в комнату
[13:22:24] michael.holub вошёл(а) в комнату
[13:23:32] michael.holub вышел(а) из комнаты
[13:27:16] geovit вошёл(а) в комнату
[14:00:05] yakov вошёл(а) в комнату
[14:00:15] <yakov> hey
[14:01:04] geovit вышел(а) из комнаты
[14:08:09] michael.holub вошёл(а) в комнату
[14:33:35] geovit вошёл(а) в комнату
[14:41:25] michael.holub вышел(а) из комнаты
[14:46:35] ygrek вышел(а) из комнаты
[15:31:48] geovit вышел(а) из комнаты
[15:37:21] Typhon вышел(а) из комнаты
[15:37:33] Typhon вошёл(а) в комнату
[15:42:54] geovit вошёл(а) в комнату
[15:55:29] <gds> читая это -- http://belnetmon.livejournal.com/977649.html?mode=reply -- слегка подумал: а как бы я писал подобную штуку на окамле, если бы целью была именно гибкость использования (синхронно / асинхронно (threads / events)).
delimited continuations -- оно понятно, а вот без них как -- это вопрос. Пихать всю логику в функтор, аргументом которого будет один модуль для синхронного выполнения, другой для асинхронного, что ли. (если в терминах монад, то код будет одинаковый, но будет выполняться при разных определениях bind/return.)
[16:04:22] <f[x]> я бы делал асинхронно, а поверх него синхронную обёртку для простых случаев исопльзования
[16:04:29] <f[x]> потому как в другую сторону всё равно не получится :)
[16:05:02] <f[x]> в jocaml-list "забавный" баг показали, /me в шоке
[16:05:25] <gds> ага, багу видел, удивительно.
[16:05:52] <gds> (тоже подписался на рассылку jocaml'а)
[16:10:52] <gds> насчёт асинхронности -- хитро тут, ибо зависит от "шедулера". если я правильно понимаю, то окамловские threads и lwt несовместимы, то есть, асинхронный код должен быть разным. (в ocaml threads код "прямой", треды прерываются на уровне системных вызовов и gc, а в lwt идёт монадный стиль вызова потенциально блокирующихся вызовов, как я помню)
[16:11:05] Typhon вышел(а) из комнаты
[16:20:57] <f[x]> к стыду своему как оно сделано в lwt я не знаю, но если event loop там есть, то асинхронное api в него должно встраиваться, правда надо будет expose'ить десрипторы файлов итп, но это общая проблема при объединении разных асинхронных "фреймворков". По хорошему в светлом будущем должен быть одна async low-level api, грубо говоря val add : (fd, (fd -> [`Read|`Write|`Error] -> [`Continue|`Remove])) -> unit и все вокруг него накручивают свои высокоуровневые фреймворки и легко объединяются. Сейчас есть одна подобная попытка имхо - это equeue из ocamlnet но его очевидно никто не использует. На мой взгляд unixqueue излишне сложен (не могу утверждать что можно сделать проще), а uq_engines это вообще тихий ужас, fsm'ы по десять экранов простыней. Хочется чего-то простого, быстрого и универсального :)
[16:24:58] <f[x]> или не будет такого светлого будущего ввиду какого-нибудь фундаментального ограничения?
[16:29:56] <f[x]> например это означает тысячи коллбэков на сишной стороне - их надо регистрировать
наверное также кроме просто event'а `Read будет ещё вариант `Read bytes - усложнение ради скорости
вообще биндинги к каким-нибудь "взрослым" async api в камле сейчас есть? (к libevent есть неизвестной степени рабочести)
ну и очевидная головная боль - всё остальное кроме IO - как быть и надо ли?
[16:31:04] <f[x]> с другой стороны делают же люди всякие node.js/twisted/итп
[16:32:56] <gds> про асинхронное -- давно думал/думаю о подобном, проблем сходу не вижу. Однако, кроме стандартного ввода-вывода, нужен доступный из апи примитив, позволяющий ждать одно/все события с каким-то таймаутом.
[16:33:06] <gds> но апи придумать можно, а реализация?
[16:34:27] <f[x]> а что реализация? трясти надо :)
[16:34:42] <f[x]> да, значит val add : timeout:float -> ...
[16:35:25] <gds> > кроме просто event'а `Read будет ещё вариант `Read bytes - усложнение ради скорости
в своё время я додумал подобную мысль до вынесения всего в нечто типа сишного лексера, парсящего простые регекспы (с группами, с указанием нужных/игнорируемых групп).
[16:36:26] <f[x]> опять таки общая проблема в том что не ко всему есть асинхронное api, например тот же libmysqlclient, надо либо в отдельный тред пускать, либо своё нативное писать
[16:36:40] <f[x]> ы, не понял, при чём тут регекспы?
[16:40:30] <gds> регекспы -- при том, что они (точнее, ast, которое их представляет) вполне удобно. например, read_int можно представить как "регексп": Sequence [Store_result (One_or_more (Char_of "0123456789")); Ignore_result (Or [Eof; One_or_more "\r\n"])], и для "123\n" оно будет выдавать результат "123". То есть, такие вещи тоже можно туда загнать.
Большинство протоколов можно нормально разбить на токены посредством подобных "регекспов".
[16:41:48] <gds> про "в отдельный тред" -- о да. Если брать те же виндовые пайпы, консоль и всё такое, то там тоже чтение всегда блокируется.
[16:42:06] <f[x]> имхо это отдельная тема, более высокий уровень
[16:42:41] <f[x]> имхо у пайпов есть асинхронный интерфейс
[16:42:53] <gds> это да. Но `Read_bytes -- усложнение как раз в эту сторону, и оно в конце концов приведёт к подобному.
[16:43:29] <gds> про пайпы -- ну не знаю. классический ReadFile не умел. разве что overlapped io брать.
[16:43:32] <f[x]> пайпы через ReadFile -> есть APC
[16:43:38] <f[x]> ну да, overlapped io
[16:44:26] <f[x]> короче болтовня всё это
[16:47:26] <gds> примерно да. на деле же -- ocaml threads или lwt в руки, и не выделываться. а в случае lwt ещё обязательно понадеяться, что они уберут select() оттуда.
[16:59:24] <gds> ещё подумалось. в рассылке сделали таки shared memory, в которую можно складывать окамловские значения, но пишут:
"Values outside the heap do not support the polymorphic comparison and hash functions. That's a hard limitation, e.g. you cannot even compare two strings, or build a hash table with strings as keys. That limits the usefulness of shared memory."
кажется, достаточно тупо поменять функции полиморфного сравнения и хеширования так, чтобы они рекурсивно обрабатывали не только значения из heap, но и из shared memory.
насчёт проблемы со сборкой мусора (в этой самой shared memory) вот не знаю. ну да поглядим, как это оформится в следующей версии ocamlnet.
[17:04:24] geovit вышел(а) из комнаты
[17:09:35] <f[x]> а как ты их поменяешь раз они в камле зашиты жёстко?
[17:16:44] <gds> в частных случаях -- переопределением "=", но конечно криво. а вообще -- патчить компилятор. имел ввиду, что проблема не техническая (т.е. понятно, как всё это решить). с другой стороны, мало кому понравится безусловный, не зависящий от использования shared memory оверхед на сравнении адресов значений с адресами выделенного блока shared memory.
[17:25:40] <f[x]> а какой там оверхед? +n сравнений на то что попадаем в границы одного из выделенных кусков shm?
[17:26:20] <gds> да.
[17:26:43] iNode вышел(а) из комнаты
[17:27:22] <gds> мало ли, что в голове у авторов и у излишне-любопытных пользователей.
[17:29:27] <f[x]> и что, это решает все косяки? т.е. фактически плюс кусок памяти без gc, но с камлевскими value
[17:31:22] <gds> главное, зачем эта штука нужна, это структуры данных, которым gc не нужен: arrays/bigarrays, ну и другие несложные мутабельные штуки.
хотя ещё надо подумать и посмотреть на то, что будет в релизе ocamlnet.
[17:31:26] gds вышел(а) из комнаты
[18:55:57] yakov вышел(а) из комнаты
[19:11:25] gds вошёл(а) в комнату
[19:24:52] iNode вошёл(а) в комнату
[19:32:31] gds вышел(а) из комнаты: Replaced by new connection
[19:32:32] gds вошёл(а) в комнату
[19:51:37] Typhon вошёл(а) в комнату
[19:52:26] gds вышел(а) из комнаты: Replaced by new connection
[19:52:29] gds вошёл(а) в комнату
[20:26:49] f[x] вышел(а) из комнаты
[20:30:23] gds вышел(а) из комнаты
[20:34:43] AKos вышел(а) из комнаты
[20:35:24] AKos вошёл(а) в комнату
[20:35:50] AKos вышел(а) из комнаты
[20:36:08] AKos вошёл(а) в комнату
[20:38:57] gds вошёл(а) в комнату
[20:52:14] animist вышел(а) из комнаты: Replaced by new connection
[20:53:37] gds вышел(а) из комнаты: Replaced by new connection
[20:53:48] gds вошёл(а) в комнату
[21:04:48] gds вышел(а) из комнаты: Replaced by new connection
[21:04:49] gds вошёл(а) в комнату
[21:08:08] gds вышел(а) из комнаты: Replaced by new connection
[21:08:10] gds вошёл(а) в комнату
[21:12:00] gds вышел(а) из комнаты: Replaced by new connection
[21:12:02] gds вошёл(а) в комнату
[21:12:54] gds вышел(а) из комнаты: Replaced by new connection
[21:12:56] gds вошёл(а) в комнату
[21:15:16] gds вышел(а) из комнаты: Replaced by new connection
[21:15:17] gds вошёл(а) в комнату
[21:37:05] AKos вышел(а) из комнаты
[21:48:50] gds вышел(а) из комнаты: Replaced by new connection
[21:48:52] gds вошёл(а) в комнату
[22:50:26] Kakadu вошёл(а) в комнату
[23:09:02] Typhon вышел(а) из комнаты
[23:12:39] Kakadu вышел(а) из комнаты
[23:16:00] sceptic вышел(а) из комнаты
[23:20:24] sceptic вошёл(а) в комнату
[23:41:41] Kakadu вошёл(а) в комнату
[23:46:46] Typhon вошёл(а) в комнату
[23:51:53] Typhon вышел(а) из комнаты