Objective Caml - Понедельник, 19 сентября 2011

Objective Caml

ocaml@conference.jabber.ru

Понедельник, 19 сентября 2011< ^ >

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

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

GMT+4
[00:10:32] ftrvxmtrx вышел(а) из комнаты
[00:11:03] Kakadu вышел(а) из комнаты
[00:32:00] <komar> Потсоны.
[00:32:03] <komar> Какой у зерта жаббер?
[00:41:09] <gds> он уммиръ.
[00:41:46] <komar> Куда умер? Тут ломающие новости.
[00:46:08] shaggie вышел(а) из комнаты
[01:03:44] ygrek вышел(а) из комнаты
[01:37:03] komar вышел(а) из комнаты
[01:53:34] ftrvxmtrx вошёл(а) в комнату
[01:56:58] ftrvxmtrx вошёл(а) в комнату
[02:01:59] ftrvxmtrx вышел(а) из комнаты
[02:12:42] ftrvxmtrx вышел(а) из комнаты
[02:21:43] gds вышел(а) из комнаты
[02:34:16] ftrvxmtrx вышел(а) из комнаты
[02:34:24] ftrvxmtrx вошёл(а) в комнату
[03:03:38] Typhon вышел(а) из комнаты
[03:50:00] letrec вошёл(а) в комнату
[04:47:12] komar вошёл(а) в комнату
[04:48:51] letrec вышел(а) из комнаты
[05:11:12] komar вышел(а) из комнаты
[07:30:02] zert вошёл(а) в комнату
[07:51:47] ftrvxmtrx вышел(а) из комнаты
[10:22:24] Kakadu вышел(а) из комнаты
[11:11:26] klapaucius вошёл(а) в комнату
[11:18:11] ermine вошёл(а) в комнату
[11:19:10] bobry- вошёл(а) в комнату
[11:52:00] <f[x]> заявка на занесение в вики (зацепил фразеологизм в комменте) -> http://stackoverflow.com/questions/7438373/ocaml-toplevel-with-syntax-extensions
[11:54:11] gds вошёл(а) в комнату
[11:56:10] <bobry-> «It is XXI century already - use ocamlfind»
[11:56:14] <bobry-> в топек!
[11:58:46] <klapaucius> XXI century и вдруг ocaml*
[11:59:23] bobry- вышел(а) из комнаты
[12:00:29] <klapaucius> gds: И почему же строгая модель вычислений требует меньших усилий? Какое-то обоснование для этого есть?
[12:05:22] <gds> больше выражений вычисляются сразу -> есть класс зависаний, видимых сразу, при запуске программы, а не при попытке побежать по структуре данных, которая должна быть конечной в правильной программе, и не при попытке вычислить выражение, вычисление которого должно быть конечным в правильной программе.  В ленивом языке для проверки этого нужно обеспечить достаточный "code coverage" при тестировании.
[12:11:32] <klapaucius> Погодите, вы сейчас написали, что функция вычисляющая не только то, что нуждно, а больше - обеспечивает больший "code coverage", чем та, которая вычисляет только то, что нужно? Ну, это довольно очевидное соображение. Но простота тестирования этим не определяется полностью.
[12:13:38] <klapaucius> Во-первых, если модель вычислений нестрогая - можно применять более мелкогранулярную декомпозицию и писать функции, которые делают что-то одно - их и тестировать легче. При строгой модели - так не получится.
[12:14:17] <klapaucius> Во-вторых, когда функция вычисляет не только то, что нужно - это неприятный побочный эффект, с которым нужно как-то бороться.
[12:17:15] bobry- вошёл(а) в комнату
[12:21:52] <gds> конечно, тестирование определяется не только этим.  Но это -- такое свойство модели вычислений, которое всегда и везде улучшает тестируемость.
про декомпозицию -- конечно, именно так не получится, но так, как уже получается, получается вполне прилично.  А способы задержать вычисление выражения есть.
про побочные эффекты -- забавно, но именно в ленивом языке есть непредсказуемые побочные эффекты при попытке, например, напечатать значение -- может оказаться, что вот в данной точке программы значение видно, оно привязано к имени, но внезапно для печати нужно его вычислить, потратив кучу ресурсов.  а то ещё может и не вычислиться.  это тоже облегчает тестирование программ на языках со строгой моделью вычислений: если значение есть/видимо/привязано, то при его использовании не может возникнуть ошибка,связанная с его вычислением.
[12:24:13] <klapaucius> Вот, например, строгая функция map над строгим иммутабельным списком длинной N при работе размещает в памяти 2N конс-ячеек. (N - если список мутабельный). С какой функцией ее при этом не скомбинируй, это никак не изменится. Ленивый map над ленивым списком занимает в памяти один санк и, при преведении в нормальную форму N узлов. Но если скомбинировать ее с take K или head то размещаться в памяти будет уже K узлов и 1 узел соотвественно. Преимущество строгого порядка вычислений - предсказуемость. Недостаток - максимальное использование памяти во всех вариантах, за счет чего, собственно, предсказуемость достигается.
[12:24:37] arhibot вошёл(а) в комнату
[12:24:41] <klapaucius> >Но это -- такое свойство модели вычислений, которое всегда и везде улучшает тестируемость.
[12:24:47] arhibot вышел(а) из комнаты
[12:25:12] <klapaucius> Улучшает покрытие кода - да. Но и затрудняет тестируемость за счет укрупнения единицы декомпозиции.
[12:25:40] <f[x]> хорошо начинается понедельник :)
[12:26:35] <klapaucius> >так не получится, но так, как уже получается, получается вполне прилично.
Спорное утверждение. Которое еще и фактам противоречит, потому как в строгих языках массово используется нестрогий порядок вычислений для решения таких проблем.
[12:26:57] <klapaucius> >А способы задержать вычисление выражения есть.
[12:27:33] <gds> там другая декомпозиция получается, и они разумеется отличаются.
[12:27:35] <klapaucius> Есть, но вышеозначенные преимущества строгого порядка они нивелируют, потому как ничего общего со строгим порядком вычислений не имеют.
[12:28:24] <klapaucius> gds: можно подробнее про "другую декомпозицию"?
[12:29:15] <gds> бОльшая часть кода -- строгая.  Задержанные вычисления -- только в редких, нечастых и очевидных местах.  Это надёжнее, чем "везде ленивое, но опционально строгое".
[12:30:40] <gds> другая декомпозиция -- классическая структурная декомпозиция, выделение структур данных, модульная декомпозиция, изредка объекты-классы.  Фактически, выделение процедуры в какой-нибудь сишечьке -- это задержка вычисления того кода, который в процедуре, до тех пор, пока её не вызвали.
[12:32:57] <klapaucius> "везде ленивое, но опционально строгое" - такого на практике не бывает. Анализатор строгости "распространяет" строгость автоматически, а ленивость в строгом по умолчанию языке не распространяется и требует ручной аннотации всегда и везде. Точно также и вручную аннотированную ленивость компилятор строгого языка автоматически не уберет, даже если она и не нужна.
[12:35:14] <klapaucius> gds: и вы считаете, что уровень декомпозиции как в "сишечке" это нормально и для любого программиста достаточно?
[12:35:41] <f[x]> только хардкор, только машкод
[12:36:01] <klapaucius> Но тестировать при более мелкогранулярном уровне декомпозиции проще - или вы и с этим не согласны?
[12:42:39] <gds> много ленивости не нужно -- вредно для отлаживаемости.  И уж точно не нужно, чтобы её кто-то распространял.  Только ручная её простановка в конкретных алгоритмах и структурах данных.
[12:43:04] <klapaucius> gds: Почему не нужно?
[12:43:31] <klapaucius> Я, про распространение
[12:43:40] <gds> кстати, ещё для оценки производительности/завершимости излишняя ленивость вредна.
[12:44:09] <gds> про сишечьку -- это было к вопросу о задержанных вычислениях, а не о декомпозиции.  "фигурный квотинг", знаем-знаем.
[12:44:50] <gds> распространение ленивости -- ну, мне лично от этого в жылах стынет, как представлю.  непредсказуемо же будет всё.
[12:45:22] <klapaucius> Если завершимость проверяется, то разницы между ленивостью и строгостью нет вообще никакой - нельзя на языке с проверкой описать такой "эксперимент", который позволил бы определить, ленивый нормальный или аппликативный.
[12:46:04] <klapaucius> gds: а как вы к автоматическому управлению памятью относитесь?
[12:46:17] <gds> завершимость не всегда можно проверить, и иногда она зависит от входных данных.
[12:47:29] <klapaucius> >завершимость не всегда можно проверить, и иногда она зависит от входных данных.
Ну вот видите, тут и других причин хватает. А производительность тоже никто не "предсказывает", а измеряют профайлером.
[12:47:50] <gds> автоматическое управление памятью -- это хорошо, я сравнил количество действий и ошибок, и с автоматическим управлением получается лучше, при весьма небольшом оверхеде.  (хотя, кое-где ощущаемом, а кое-где и запрещающим использование автоматического управления памятью.)
[12:49:11] <klapaucius> gds: Ну и с распространиением строгости ситуация в точности такая же. Автомати дает статистически лучший результат, чем человек, но есть паталогические случаи, когда нужно вмешательство человека.
[12:49:11] iNode вышел(а) из комнаты
[12:49:13] <gds> на строгих языках верен подход "если писать код тупо / в лоб, то скорее всего будет работать быстро и жрать мало памяти, профайлер понадобится на более поздних этапах".  на ленивых -- порой профайлер нужен чтобы хотя бы запустить программу.
[12:50:40] <klapaucius> > на строгих языках верен подход "если писать код тупо / в лоб, то скорее всего будет работать быстро и жрать мало памяти
Контрпример: пишем тупой мап: map f (x:xs) = f x : map f xs - в ленивом языке работает, в строгом нет.
[12:51:34] <klapaucius> Вообще достаточно посмотреть на стандартные библиотеки SML, батарейки и Прелюдию. В прелюдии код "тупой", но работающий. В первых двух - акробатика и приключения чтоб как-то работало.
[12:51:43] <gds> про управление памятью -- тут дело собственно не в ленивости и строгости, а в разной декомпозиции и в разном подходе к написанию программ -- именно это, а не собственно ленивость-строгость, даёт лучший результат в крупной перспективе (не в вопросах вычисления конкретных мелких выражений).
[12:52:43] <klapaucius> gds: Ну так о том и речь - плюс ленивости в том, что она улучшает модульность.
[12:53:59] <klapaucius> Минус ленивости - кардинально отличающаяся "ценовая модель"
[12:59:28] iNode вошёл(а) в комнату
[13:08:20] iNode вышел(а) из комнаты
[13:10:26] iNode вошёл(а) в комнату
[13:41:47] iNode вышел(а) из комнаты
[13:47:35] shaggie вошёл(а) в комнату
[14:11:27] ftrvxmtrx вошёл(а) в комнату
[14:26:12] komar вошёл(а) в комнату
[14:41:34] ftrvxmtrx вышел(а) из комнаты
[14:53:49] iNode вошёл(а) в комнату
[15:10:58] ftrvxmtrx вошёл(а) в комнату
[15:30:58] ftrvxmtrx вышел(а) из комнаты
[15:31:06] ftrvxmtrx вошёл(а) в комнату
[15:38:15] letrec вошёл(а) в комнату
[15:38:22] letrec вышел(а) из комнаты
[15:38:38] letrec вошёл(а) в комнату
[16:14:05] komar вышел(а) из комнаты
[16:30:30] ftrvxmtrx вышел(а) из комнаты
[16:31:06] bobry- вышел(а) из комнаты
[16:34:39] ftrvxmtrx вошёл(а) в комнату
[16:39:13] <letrec> уто-нибудь исходники lwt смотрел? я правильно понимаю, что их mutex может корректно работать только в кооперативном окружении?
[16:47:02] <letrec> ага, вкурил как делается синхронизация с detached threads
[16:47:47] <letrec> изящно у них там всё сделано, странно, что раньше до этого никто не додумался
[16:47:51] <gds> letrec: "синхронизация с detached threads" -- и мне расскажи.  а то я поднимал вопрос этот, но как-то без ответов.
[16:48:39] <letrec> насколько я понял они в основной цикл шлют сообщение о завершении выполнения потока
[16:49:33] <letrec> не совсем понимаю как это с точки зрения системных select/poll выглядит
[16:50:02] <letrec> но концептуально они просто маршалят выполнение продолжения в основной поток
[16:50:30] <letrec> как это делается в винде при написании гуёвого кода использующего потоки
[16:51:02] <letrec> ну или вызова на STA COM object
[16:51:43] <letrec> просто в очередь лупа кладётся известное сообщение, которое луп знает как хэндлить
[16:52:26] <letrec> мне нравится концептуальная компактность подхода
[16:53:14] <letrec> ну и p4 рулит - не надо язык корёжить, чтобы поиметь прямой синтаксис как это сделают с C# & VB
[16:54:27] <letrec> в F# кстати тоже язык корёжить не надо благодаря computation expressions, но с ними всё равно не выглядит так нативно как в камле
[17:02:37] <gds> letrec: а если сугубо практически -- как синхронизировать detached thread и lwt thread?
[17:05:39] <letrec> к результату выполнения detached thread прицепить продолжение, когда результат станет доступен, то библиотека выполнит присоединённое продолжение на основном (lwt) thread
[17:07:13] <f[x]> для связи с select/epoll юзают signalfd или self-pipe
[17:07:40] <letrec> меня только один момент смущает
[17:08:16] <letrec> по идее продолжение надо прицепить до запуска detached thread
[17:08:58] <letrec> потому как насколько я понял там все соответствующие структуры данных потоконебезопасны
[17:11:22] <letrec> f[x]: т.е. есть заранее созданный пайп для коммуникации с основным потоком, который тоже селектится/поллится наряду со всем остальным добром?
[17:15:36] <f[x]> думаю да - стандартный подход же
[17:16:35] <letrec> я под юниксы не писал никогда, представляю select/poll чисто теоретически
[17:18:17] <f[x]> см. lwt_unix_send_notification_stub
[17:50:30] bobry вошёл(а) в комнату
[17:59:56] Kakadu вошёл(а) в комнату
[18:14:41] bobry вошёл(а) в комнату
[18:14:41] bobry вышел(а) из комнаты
[18:31:20] iNode вышел(а) из комнаты
[18:40:06] komar вошёл(а) в комнату
[19:33:05] bobry вышел(а) из комнаты
[19:33:31] bobry вошёл(а) в комнату
[19:55:49] letrec вышел(а) из комнаты
[19:57:56] ftrvxmtrx вошёл(а) в комнату
[19:57:56] ftrvxmtrx вышел(а) из комнаты
[19:59:21] bobry вышел(а) из комнаты
[20:46:10] <komar> zert: какой у тебя jid?
[20:47:02] <zert> zert@j.r
[20:47:10] <zert> АПВС?
[20:53:53] <komar> Да на всякий случай.
[20:54:00] <komar> Тут ломающие новости стали поступать.
[20:55:42] bobry вышел(а) из комнаты
[20:55:50] <zert> какие ломающие?
[20:56:00] bobry вошёл(а) в комнату
[20:56:28] komar вышел(а) из комнаты
[21:12:22] klapaucius вышел(а) из комнаты
[21:51:51] shaggie вышел(а) из комнаты
[22:02:21] ermine вышел(а) из комнаты
[22:29:13] bobry собрал core и core_extended -- с камло 3.12.1 все собралось без ошибок -- даже не знаю что у Kakadu было не так
[22:32:04] zert вышел(а) из комнаты
[22:50:57] komar вошёл(а) в комнату
[22:51:57] shaggie вошёл(а) в комнату
[22:54:50] bobry вошёл(а) в комнату
[23:02:43] arhibot вошёл(а) в комнату
[23:08:36] arhibot вышел(а) из комнаты
[23:12:58] bobry вышел(а) из комнаты
[23:13:57] ftrvxmtrx вышел(а) из комнаты
[23:14:05] ftrvxmtrx вошёл(а) в комнату
[23:30:53] bobry вошёл(а) в комнату
[23:33:40] ftrvxmtrx вышел(а) из комнаты
[23:58:31] ftrvxmtrx вошёл(а) в комнату
[23:59:02] ftrvxmtrx вышел(а) из комнаты