Objective Caml - Воскресенье, 27 ноября 2011

Objective Caml

ocaml@conference.jabber.ru

Воскресенье, 27 ноября 2011< ^ >

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

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

GMT+4
[01:17:00] Kakadu вышел(а) из комнаты
[01:55:22] shaggie вышел(а) из комнаты
[02:15:27] mrm вышел(а) из комнаты
[02:17:21] mrm вошёл(а) в комнату
[03:03:57] ygrek вышел(а) из комнаты
[04:56:04] mrm вышел(а) из комнаты
[07:28:06] komar вышел(а) из комнаты: Replaced by new connection
[07:28:06] komar вошёл(а) в комнату
[11:45:01] Kakadu вошёл(а) в комнату
[11:52:30] ygrek вошёл(а) в комнату
[12:11:48] ermine вошёл(а) в комнату
[12:55:55] arhibot вошёл(а) в комнату
[12:57:10] arhibot вышел(а) из комнаты
[12:57:12] <ermine> gds: интересно, как строить дерево для быстрого поиска правил при bottom-up парсинге?
[12:57:54] <ermine> в этом дереве надо находить правила для редукции
[13:03:12] <gds> ermine: хз, думай.
[13:04:23] <ermine> gds: угу, думаю в направлении любимой хэштаблы, где в качестве ключа - список символов, в качестве значения - редукцированный символ, он же определение правила
[13:05:23] <ermine> я тут начиталась хлама, теперь у парсерика моего должен быть мощный прорыв вперед, осталось решить - парсить вниз или вверх, а может и сразу в обе стороны
[13:31:50] <Kakadu> как бы так пропатчить
#define setAbstrClass(res,clas,val)\
do{res=caml_alloc_small(1,Abstract_tag);\
(*((clas **) &Field(res, 0)))=val;}while(false)
чтобы третим аргументом можнобыло подсовывать const _* val
[13:32:59] <ygrek> сделай нормальной функцией, а не define'ом
[13:59:53] schurshik вошёл(а) в комнату
[14:02:13] schurshik вышел(а) из комнаты: qutIM : Jabber plugin
[14:05:16] ftrvxmtrx вошёл(а) в комнату
[14:08:14] ftrvxmtrx вышел(а) из комнаты
[14:09:15] ftrvxmtrx вошёл(а) в комнату
[14:10:56] ftrvxmtrx вышел(а) из комнаты
[14:51:52] <gds> http://paste.in.ua/3364/
[15:29:13] gds вышел(а) из комнаты
[15:29:23] gds вошёл(а) в комнату
[16:00:57] <gds> ermine: для вопроса "какую хрень для соответствий ключа и значения брать" я могу предложить такой вариант: в кадастр вдобавок к {императивным,функциональным} отображениям с {одной,многими} привязками к ключу добавляю враппер, который только тем и занимается, что профайлит твоё отображение -- смотрит, сколько каких операций было и сколько времени они занимали в процессе выполнения программы.  рано или поздно всё равно это буду делать, а там и автоматический выбор структуры можно сделать на основании профайлинга в будущем.
[16:05:10] <gds> а, ну ещё и нагрузку на мусорщик можно легко мерять.
[16:07:25] komar вышел(а) из комнаты
[16:08:21] komar вошёл(а) в комнату
[16:13:13] <ygrek> в reins есть автоматический выбор структуры данных
[16:14:37] <gds> фух, пронесло, а то уж было подумал, что изобрёл что-то странное.
[16:24:44] komar вышел(а) из комнаты
[16:31:22] <ermine> gds: про профайлер интересно, у меня до сих пор не было разумной практики мучения профайлера, видимо надо начинать
[16:32:14] <gds> собственно я не про профайлер общего назначения, а про профайлер для конкретных структур данных (например, отображений).
[16:33:44] <ermine> ну для bottom-up надо применять стэк токенов, который надо постоянно пытаться редуцировать
[16:34:08] <ermine> вот подумалось - есть ли хитрый алгоритм, чтобы раскладывать вместо стэка токены вдоль дерева
[16:36:25] <ermine> где-то писали, что операции редукции в bottom-up парсере - это тормозное место
[16:36:57] <ermine> в случае жирной развесистой грамматики, разумеется
[16:37:34] ermine даже в уме уже построила bottom-up парсер для xml и уже заранее похихикала
[16:38:44] <ermine> gds: ты помнишь, что такое bottom-up парсер?
[16:39:47] <gds> примерно.  мог бы освежить в памяти, но есть кое-какие другие дела сейчас.
[16:40:05] <ermine> пример: грамматика:
expr ::= expr + expr | int
[16:40:16] <ermine> парсим 1 + 2 + 3
[16:41:21] <ermine> суем в стэк три токена 1 + 2 видим что это expr + expr и исполняем семантику, привязанную к expr (определение правила) и заменяем содержимое стэка на expr и суем в стэк следующие последние два токена и повторяем
[16:42:46] <ermine> такой стиль удобен, когда надо учитывать приоритеты и ассоциативности
[16:43:23] <gds> но это может быть не "1 + 2 [ + 3]", а "1 + 2 [ * 3]", как тут будешь?
[16:44:19] <ermine> перед тем как решать надо ли редуцировать стэк, смотрим на следуюший токен (lookahead=1) и смотрим на его ассоциативности - если он победит, то суем в стэк и пытаемся заново редуцировать
[16:44:28] <ermine> поэтому умножение победит
[16:46:01] <ermine> и так же кстати победит гемор с if then else с опциональным else - тут сыграет lookahead
[16:46:22] <ermine> это все кстати относится к GLR
[16:47:52] <ermine> короче куча новых знаний чтобы стряпать дальше парсер, вот бы озарение с xsd
[16:54:40] ermine решила оставить проекуту парсера имя kombain
[16:54:49] <ermine> пусть будет комбайном :)
[16:58:48] ygrek - было настроение - чего-то там побыдлокодил
[17:00:38] <gds> ygrek: где/чо?
[17:01:19] <ermine> кутя!
[17:03:34] <ygrek> camlunity/nih
[17:03:36] ygrek afk
[17:11:34] <Kakadu> ermine: я сейчас работаю над тем чтобы меня не выгнали из универа
[17:19:40] <gds> http://paste.in.ua/3365/
[17:31:57] <Kakadu> Кто знает зачем gds эти куски кода в чат кидает?
[17:33:34] <ermine> набивает себе очки научного кода
[17:34:04] <Kakadu> этой букой надо мальньких камлистов пугать
[17:34:47] <ermine> просветлять
[17:35:18] <ermine> а вот без переписывания этих кодов в свой емакс невозможно понять, что эти коды делают
[17:35:52] <ermine> работа как раз для маленьких
[18:08:24] <gds> Kakadu: ну, последний кусок -- например про то, что при особым образом сделанной "рантайм-информации о типах" можно выборочно переопределить какой-нибудь метод (например, "show" для показа значения).
А так -- вообще, про то, что "рантайм-информация о типах" -- это вполне таки удобная штука для высокоуровневого кода.
[18:16:51] <ermine> муляж рантаймной мудрости
[18:25:26] <gds> да этот муляж умнее и реальной rtti, и того, что делается препроцессорами.
[19:00:14] <ermine> да там же строгая типизация
[19:23:38] <gds> ermine: да, которая не очень даёт, например, использовать json-{wheel,static} так, чтобы не трахаться с compile-time зависимостью от этих либ, когда они реально не используются.  или которая не даёт возможность по-разному сериализовать разные значения, исключать некоторые поля от показа, хеширования.  в общем, строгая типизация рулит.
[19:27:18] <ermine> че трахаться со старой туфтой, когда есть yojson новомодный?
[19:38:53] <gds> скомпиляй его на всех моих хостах.
[19:39:05] komar вошёл(а) в комнату
[19:56:34] <gds> ermine: а какой тип будет у функции наподобие With_the_yojson.mytype_to_json, преобразовывающей нужное значение в json согласно директивам от yojson?
[20:02:15] <gds> ermine: дальше вопрос.  Есть сериализация через yojson, через sexpr, через xmlm (3 варианта).  Для каждой комбинации вариантов, чтобы не тащить ненужные зависимости, нужно сделать по одной сборке либы, требующей только указанные зависимости, например, через подпакеты: sexpr, sexpr_xmlm, yojson_sexpr и так далее, всего 2^3.  Добавляем ещё n-3 пакетов -- сколько сборок нужно будет иметь, чтобы использовать указанные способы сериализации?
[20:13:39] <ermine> gds: пользователя надо ограничивать во всём, оставь ему только один вариант
[20:13:56] <ermine> а то будет задавать слишком много вопросов
[20:14:08] <gds> ermine: я сам пользователь, меня один вариант не устраивает.
[20:14:13] <ermine> по три вопроса на каждый подвариант
[20:14:40] <ermine> gds: тогда согласно ТЗ :P
[20:16:01] ermine кстати перевела camlimages на oasis, чтобы гибко вырубить ненужные варианты
[20:17:39] <ermine> gds: а вот осилю я парсер, и напишу парсер yaml, и тогда ты его тоже захочешь, и будет больше головного бо-бо
[20:20:10] <gds> кстати тоже yaml думал асилить.
[20:20:28] <gds> ermine: всего 2^n способов билда / подпакетов, неправда ли?
[20:23:04] <ermine> ну в camlimages есть классы, но не они в основе, а в основе обычное хэштабло с рекордом функций API таких вариантных библиотек (gif, tiff, png, etc)
[20:23:05] <gds> так вот, ТЗ для разных случаев бывает разным.  Нужно 2^n подпакетов!  Точно говорю!
[20:23:48] <Kakadu> gds: а подпакеты не решают твою задачу: (главный пакет, сериализация из одного, второго, третьего)
[20:23:51] <Kakadu> ?
[20:24:23] <gds> ermine: там, в этих библиотеках, нет нужды работать с их типами, небось.  Если они представляют интерфейс типа "прочитать файл" / "прочитать строку" или, наоборот, записать, то это решается.  Это примитивный вариант.
[20:24:46] <gds> Kakadu: решают, но частично.  "нужно сделать по одной сборке либы, требующей только указанные зависимости, например, через подпакеты: sexpr, sexpr_xmlm, yojson_sexpr и так далее, всего 2^3"
[20:25:31] <gds> да и просто сериализация -- оно понятно, сериализовать можно и в строку, и в канал, и в оналъ, это не тот случай.
[20:25:44] <gds> хочется в процессе пощупать Json_type.t например.
[20:26:05] <ermine> gds: там есть один универсальный тип картинки, а кто как его жрет - не проблема универсального типа
[20:27:11] <gds> ermine: я предпочитаю без универсального типа, объединяющего Json_type.t, xml, sexpr.  Это и копирование значений туда-сюда, и извращения в случае попыток объединить воедино необъединимое.
[20:28:03] <ermine> gds: незачем объединять
[20:28:26] <ermine> gds: у тебя только одна структура, в которой есть поля и подструктуры в виде типов камля, и всё
[20:28:56] <gds> ermine: давай идею, как работать и с json, и с xml так, чтобы при нежелании работать с json не требовалась json_wheel с определением Json_type.t.
[20:30:14] <ermine> gds: ну у тебя jspn и xml только снаружи, на входе/выходе, это только представление структуры для иных миров
[20:30:42] <ermine> gds: ты просто знаешь как маппить json в тип камля (ну сам со собой договариваешься, что знаешь)
[20:31:25] <ermine> именно из-за нежелания разделять структуру языка и представление данных в иных форматах возникают проблемы с головой
[20:31:27] <gds> ermine: хочется в процессе пощупать Json_type.t например.
[20:32:18] <gds> > ты просто знаешь как маппить json в тип камля (ну сам со собой договариваешься, что знаешь)
маппить строку с json или собственно Json_type.t?
[20:33:50] <ermine> gds: ну я думаю что у тебя должно быть представление, какие данные тебе суют в json, или вообще любые данные надо жрать, не зная об их семантике?
[20:34:12] <ermine> gds: лучше опираться на семантику
[20:34:56] <gds> ermine: у меня есть 1. камловские типы, 2. значения Json_type.t, 3. строки/каналы.  Со всем из этого нужно работать.  С xml-представлением в виде Xmlm.какой-то-тип тоже.
[20:35:07] <Kakadu> gds: а ты не делай сборок либы. пускай них собирает
[20:35:17] <Kakadu> нужный вариант в зависимости что есть
[20:35:23] <Kakadu> в системе уже установлено
[20:35:47] <gds> Kakadu: не получится, них под другое точится -- под то, что уже есть библиотека, которую известно, как собирать.
[20:36:10] <Kakadu> gds: configure!
[20:36:21] <gds> Kakadu: про "что есть" -- тоже не катит, вдруг я забыл поставить xmlm, и софтина отвалится при сборке с такой недоделанной сборкой либы.
[20:37:07] <gds> с помощью configure можно отсечь некоторые из n вариантов, но всё равно их будет 2^n.  плюс вопрос о переносимости бинарников на другие хосты тоже стоит.
[20:37:48] <Kakadu> чтобы ты не забыл надо писать них.конфиг
[20:39:42] <ermine> gds: я тут маюсь с xsd, как раз чтобы не мучаться с ручным писанием пары сотен файлов однотипного кода, в xsd нет семантики, про семантику долдна знать прога, которая будет этим пользоваться. Сгенерю то что получится, будет маппинг в типы камля и обратно и апи, которое высветит ocamldoc, и вот этого достаточно
[20:41:35] <gds> в общем, вы какие-то костыли предлагаете.  зацените моё решение: 1. имеем пакет и n подпакетов на каждый вариант сериализации (вместо 2^n), 2. используем нужные подпакеты, которые тянут нужные зависимости, по подпакету на каждую внешнюю зависимость.  Какие подпакеты использовали -- такие зависимости и имеем.  Просто, эффективно.
[20:42:32] <Kakadu> gds: твой rtti --- тормозящий изврат
[20:42:49] <Kakadu> имхо
[20:43:49] <gds> Kakadu: не пользуйся.
[20:43:57] <Kakadu> вводишь в них новый вид зависимости --- "опциональная для ....".
учишь них в правильно порядке собирать.
???
профит
[20:44:31] <ermine> скайнет всех обобрет
[20:44:33] <gds> мне нужно также то, чтобы в бинарник не линковалось лишнее -- то, что не нужно для задачи.
[20:44:53] <ermine> и человек будет не нужен с его дурацкой семантикой
[20:45:55] <gds> ещё не нужно подключение ненужных библиотек в виде .so в случае переноса на другой хост -- например, на моём хосте есть все нужные виды сериализации, а я хочу перетащить бинарник на другую машину, где только json.
[20:46:09] <ermine> кстати у меня парсер должен сначала прочитать описалово грамматики, потом парсить грамматику (ну или генерить код), во так в мечтах у меня
[20:46:40] <gds> ermine: правильно, так и надо.
[20:46:40] <ermine> как напишешь код - так он тебя накажет
[20:47:58] <ermine> там в грамматиках оказывается самое главное - делить символы на нетерминалы и токены, токены как раз в bnf не помечаются разумным образом
[20:54:37] <gds> в последнее время в программировании необходимо больше удобство и предсказуемость, нежели подсчёт циклов процессора.  удобство для себя я делаю, предсказуемость даёт камло, следовательно, реальные задачи на практике я буду решать быстрее, чем если бы не использовал свои удобства, а оптимизировать потом несложно, если вдруг какие-нибудь 3% кода потребуют этой оптимизации.
[21:06:20] mrm вошёл(а) в комнату
[21:06:27] mrm вышел(а) из комнаты
[21:12:16] mrm вошёл(а) в комнату
[21:15:27] arhibot вошёл(а) в комнату
[21:21:11] arhibot вышел(а) из комнаты
[22:21:03] ftrvxmtrx вошёл(а) в комнату
[23:33:51] ftrvxmtrx вышел(а) из комнаты
[23:34:12] ftrvxmtrx вошёл(а) в комнату
[23:56:22] komar вышел(а) из комнаты: Logged out
[23:56:25] komar вошёл(а) в комнату
[23:56:43] Typhon вошёл(а) в комнату