Below are the 20 most recent journal entries recorded in gds' LiveJournal:

[ << Previous 20 ]

Thursday, November 5th, 2009
10:43 am	Захотелось пошариться по домашнему компу (линупс) с работы (венда за NAT'ом), да не просто так, а в иксах. Без гламурных vnc. Иксы ведь подразумевали сетевую прозрачность, попробовать надо хоть раз в жизни. Любой сколько-нибудь опытный юниксоид знает, что и как, и ему будет скучно под катом. Да и всё это дело ищется в инете, но почему-то не нашёл описания, которого хватило бы целиком. ( Read more... ) (6 Comments |Comment on this)
Tuesday, November 3rd, 2009
5:47 pm	В последнее время есть куча всякой фигни, которую не успеваю доделать, и понимаю, что если буду ещё и за новую фигню браться, то уж точно не сделаю вообще ничего. Поэтому идейку отмечу тут. Вероятно, сам дойду, но кто его знает. Это к вопросу о перебросе изменений между приватным и публичным репозиториями. Как это сделать в простом случае (когда изменения последовательны и заканчиваются на tip'е), мне теперь уже понятно. Но в общем случае необходимо (лично мне): 1. уметь переупорядочивать коммутирующие changeset'ы, 2. уметь сливать несколько последовательных changeset'ов, возможно находящихся в глубине истории, в один changeset с нужным комментарием. Ключевой момент, который наломал простое решение, состоит в моём неумении применить rebase extension (включается по hgext.rebase= в секции [extensions]). Или я его не так понимаю, или оно не так работает. Планируемые алгоритмы всей этой радости есть у меня в голове, но не буду наламывать кайф от их самостоятельного изобретения. И мои алгоритмы весьма чрезжопные, тогда как более умный искатель вероятно найдёт алгоритмы попроще. (Comment on this)
Thursday, October 8th, 2009
6:19 pm	Некий человек узнавал у меня, каким алгоритмом сделать простую штуку: перебрать различные наборы из m элементов в общем множестве из n элементов (по крайней мере, сначала я понял это так, а что было потом, не суть важно). И он хотел узнать алгоритм. Предложил ход на ocaml/lisp/scheme, но ему нужно было понять алгоритм, поэтому попросил написать на императивном языке. Выбрали C. Ну я и написал. ( Read more... ) /*********** ALG ************/ void proc( list_int list, int arr[], const int arrsz , const int i, const int left ) { if (left == 0) { DBG(printf("i=%i\n", i)); print_int_list(list); } else { int j; for (j = i; j <= arrsz - left; ++j) { WITH_CONS4 ( int, &(arr[j]), list , proc, arr, arrsz, (j+1), (left-1) ); } } } /************ DATA *************/ int arr[] = {5, 6, 7, 8, 9}; int elements = 3; int main(void) { list_int nil = NULL; proc(nil, arr, sizeof(arr)/sizeof(arr[0]), 0, elements); return 0; } Многие выдавливают из себя индуса по капле в процессе работы, я же своему внутреннему индусу выделил отдельное рабочее пространство. (4 Comments |Comment on this)
Friday, October 2nd, 2009
2:03 pm	Есть вопрос про меркуриалу. Представим, что есть два репозитория -- int и ext. int я использую для приватной работы, которую никому видеть не следует: я для удобства работы указываю матерные commit messages и отпускаю расистские комментарии в меняющемся коде. Если же эти changeset'ы перекинуть в репозиторий ext через bundle, export, push или же стянуть их из int через pull, то commit messages, как и диффы, будут показаны в ext полностью. Как и в случае branch'ей. Мне хочется избежать этого. Знаю, что с точки зрения использования DVCS нужно делать кучу мелких коммитов, но некоторые вещи так оформлять неудобно. Единственный вариант, который вижу сейчас -- создать int путём клонирования ext, записать хеш ревизии, откуда начал разработку фичи, а по окончании разработки генерить дифф в int между точками начала (записанная ревизия) и окончания (int's tip) разработки, и пытаться приложить этот дифф к ext. Но вручную с диффом бодаться влом. Есть более культурные варианты? (2 Comments |Comment on this)
Thursday, October 1st, 2009
1:35 pm	overbld Ну наконец-то руки дошли выложить исходники overbld на публичный хостинг. http://sourceforge.net/projects/overbld/ (Comment on this)
Sunday, September 27th, 2009
4:52 pm	полёт мысли: документация Для проекта о базе знаний, помеси wiki+cms+mindmap нужен язык описания информации. О синтаксисе языка я долго думать не стал. html/xml -- многословные, для редактирования человеком текста малопригодные, вики-разметки обычно нестандартные, разные, да и не хочется ограничиваться только разметкой текста, если уж для базы знаний понадобится что-то явно хитрее. Итак, остаются только s-выражения. Для удобства и непересечения с естественным языком в качестве скобок выбрали "[" и "]". В документации мне нужно оформить некоторые куски кода в две колонки (исходники на двух разных языках программирования), да и вообще, подобные преобразования надо уметь делать. Если у меня есть способ задать таблицу в виде [table [список строк]], где каждая строка -- [список значений в колонках], то нужно оформить преобразование [twocolumn a b] в [table [[a] [b]]. Далее, подумалось, что нужна какая-то общая (и желательно стройная) модель преобразований s-выражений так, чтобы некоторые части вычислялись, а некоторые оставались. Подумал, что выражение [функция арг1 арг2 .. аргN] должно вычисляться, даже в примитивных случаях -- [p это абзац] оставит после вычисления список [p это абзац], и первый элемент будет определять узел, к которому относятся остальные элементы. Эдакий открытый индуктивный тип без типизации. Сформировалось правило вычислений: вычисляем только первое слово, применяем к нему остальные аргументы. Но иногда список -- это просто список. При вычислении выражения [какие-то слова] очевидно не надо вычислять "какие-то". Но случаи такие у меня будут реже, поэтому подумал, что нужна возможность процитировать список как есть. Чтобы "[list слово1 слово2 .. словоN]" в качестве результата вычисления давало список "[слово1 слово2 .. словоN]". Или, в качестве удобного сокращения для набора на клавиатуре, [= слово1 слово2 .. словоN]. Плюс добавить сюда кое-что для вычислений, подстановок, и будет старый добрый лисп (и лисп, и схему, кстати, мне пришлось изучить в процессе раскопок). Но в лиспе/схеме мне кое-что не понравилось в применении к этой задаче. Сейчас уже не вспомню, что именно. Видимо, необходимость eval/apply постоянно, или энергичный порядок вычисления, заставляющий вычислить аргументы какого-нибудь [p это абзац], или бардак с цитированиями/квазицитированиями. (давняя особенность: не помню, почему отказываюсь от решений, которые мне не нравятся.) Кроме того, отказался от "dotted pair" и "improper lists". Если нужна скорость, то строить структуры данных с помощью dotted pair можно вполне прилично, но у меня это не главное. Главное -- изобразить настолько минимально простую модель, чтобы она была не кривая и взлетела. В общем, мне оказался нужен язык, синтаксис которого напоминает лисп/схему, а семантика, скорее, ленивое функциональное программирование без типов. Типы не нужны -- эй, это ведь текстовые документы! Кому придёт в голову расставлять там типы? Ленивое -- чтобы не вычислять то, что не подлежит вычислению (те слова, которые стоят не на первом месте в списке), но с возможностью пробежаться по списку и сделать что-нибудь полезное. Ну и сама функция будет работать с аргументами -- если ей надо их завернуть в список, она так и сделает. Если надо вычислить третий, пятый и седьмой аргументы, она их использует так, что понадобится их вычисление. В общем, лентяйство идёт нам на помощь и сильно упрощает. Далее мне очень хочется иметь для удобства возможность передавать произвольное количество аргументов. Однако, в чистое лямбда-исчисление это не вписывается. Можно было бы завернуть всё в списки и однотипно рисовать что-то вроде: [p [= это абзац, а [b [= часть слов]] выделена жирным.]], но я не испытываю большой любви к лишним скобкам. Поэтому придётся идти на извращения и делать приемлемым код вида [p ква] и [p ку ку]. И, с другой стороны, хочу currying и partial applications -- они реально удобны. Если ввести в рассмотрение новую лямбда-абстракцию, кушающую произвольное количество аргументов, то становится противоречивой модель вычислений, которая включает в себя currying и partial applications -- например, возникает конфликт, передавать ли аргумент внешнему всеядному списку или передавать его внутренней лямбда-абстракции, ждущей применения. В качестве решения принял такое: есть специальные функции, к аргументу которых привязывается список аргументов, к которым их применили, и эти функции становятся недоступны для partial application: всё, к чему их применили в конкретном куске кода, оформляется в список и сразу привязывается к аргументу этой функции. Не идеально, но вполне юзабельно, думаю. Далее вопрос коснулся безопасности. Я ненавижу ms word за макросы в документах. Да и вообще, открытие документа может быть долгим (в меру испорченности автора), но не бесконечным по времени! И я сознательно убрал возможность написания рекурсивных функций. Так же, как и изменяемые структуры данных, которые не счёл нужным изначально добавлять. Однако, списки надо обрабатывать, поэтому передо мной были два варианта: 1. Разрешить структурную рекурсию, как это сделано в Coq: есть индуктивный тип данных, и есть рекурсивная функция, которая может разрушать значение индуктивного типа и вызывать себя только с параметрами, являющимися результатами деструкции. Например, если обрабатываем список, и он не пустой, то можем вызывать себя, передавая себе только голову или хвост списка, но никак не исходный список и никак не результат склейки хвоста списка с чем-либо. Таким образом легко доказать завершимость структурной индукции на ацикличных индуктивных типах данных. Представьте себе, тривиально по индукции :) 2. Предоставить наружу только комбинатор структурной рекурсии. О да, fold. Уже имеем алгебру списков -- пустой список [], функцию [cons hd tl], и остаётся добавить только foldl и foldr. Замечу, что map нерекурсивным образом выражается через foldr и cons, поэтому её добавляю исключительно для удобства. Я на данном этапе выбрал вариант №2 как конструктивный: явно описывается, что нужно делать с выражением, а не надеются на синтаксическую проверку функции -- а действительно ли там только с результатом деструкции вызывают функцию? А вы как думаете, какой вариант лучше? Но тут был проёб №1. Допустим, нет рекурсии, и надо обработать список [a [b c] d]. Вызываем fold по вкусу, получаем элементы "a", "[b c]", "d", а список "[b c]" обработать не сможем этой же функцией: "нет рекурсии -- нет мультиков". Причина в том, что я неправильно рассмотрел тип выражений при отсутствии рекурсии -- это не список значений, это список Значений|Списков, и отсутствие рекурсии тут принципиально. Пытался представить в окамле s-выражение как type lst 'a = [ Nil | Cons of elem 'a and lst 'a ] and elem 'a = [ Elem of 'a | List of lst 'a ]; и вывести для него катаморфизм, но процесс шёл тяжко (хотел сам, хотя знал, где в инете можно быстро почерпнуть решение). Более того, не получается никак склеить этот тип в один. Максимум, что получается, это представить тип как два независимых типа: тип "список" и тип "элемент списка", но вывести катаморфизм остаётся так же сложно, как и для взаимно-рекурсивных типов. Интересно, что, если принять лисповые dotted pairs, то в лиспе AST изоморфно бинарному дереву (но они оба не изоморфны моей структуре), и свёртка пишется легко и просто. Но тут в процессе раздумий обнаружился просто на редкость эпичный проёб №2. Запрещать именованные рекурсивные значения и рожать свёртки -- это хорошо, но ведь на лямбдах можно тупо изобразить Y-комбинатор и подвесить процесс вычисления документа. Вчера утром я это понял, и сразу же шерсть на жопе встала дыбом. Благодаря гуглингу понял, что мне нужно всего лишь simply typed lambda calculus. По ключевым словам нашёлся русский перевод TAPL, ещё один полезный результат раскопок. И Карандаш, и Бумажка интуитивно подтвердили -- если есть простые типы, то рекурсивный комбинатор хрен построишь. На классическом Y-комбинаторе лажа была при попытке унифицировать типы, когда к выражению с типом "a -> b" применялось выражение с типом "a -> b", а не с типом "a". То есть, нужно реализовывать проверялку простейших типов (просто удостовериться, что каждое отличающееся значение имеет тип "значение", а каждая функция имеет тип согласно значений, к которым она применяется). Затем, что радует, эту проверялку можно заставить выводить типы лямбда-выражений, пусть и простые, но может где-нибудь пригодится ограничить что-либо по типу, или сделать хитрое расширение системы типов (например, на параметрический полиморфизм или зависимые типы). А для типизации -- два варианта обхода лямбда-выражения: 1. при встрече лямбда-абстракции присваивать значению тип, который потом уточнять в нижних выражениях (а где не уточняется -- там ошибка), 2. наоборот, идти снизу, присваивать значениям типы, которые потом унифицировать, а при ошибке унификации сообщать об ошибке. Пока думаю, что вариант №2 более конструктивен и функционален. А вы как считаете? Как всегда, редакция рада любой критике, любым замечаниям и прочей фигне. (23 Comments |Comment on this)
Monday, September 14th, 2009
11:52 pm	Не, с микроскопом всё не ясно, не могу разобраться с оптикой. Судя по регулирующему ролику, поддерживается увеличение 250 вместо обещанных 282. Судя по резкости изображения, на увеличении 50 образец уже впритык к линзе, что кардинально неправильно. Ну, научусь его готовить ещё, или оптику изображу может. Понадобилось мне документировать одну штуку, в целом простую, но с подвыподвертом. Вспоминая старый птсо про помесь wiki+mindmap+cms, понял, что в качестве начального этапа эта штуковина может послужить просто хранилищем документации, с инкрементальным развитием до требуемых высот. На благо, в обсуждениях этой штуки и в попытках написать спеку мы с nicka_startcev в конце концов дорулили основу варианта, который, по сути, является чем-то наподобие лисповых s-выражений (все их преимущества есть, недостатков почти не добавляем), но с изменениями, улучшающими пригодность s-выражений для ручного ввода и редактирования общеупотребительной для человеков информации. (на самом деле, дорулили гораздо больше, но там уже идут аспекты, касающиеся связей между понятиями, словоформами и прочим, что конкретно для этой задачи мало требуется, но что можно будет без проблем добавить сюда.) Но я обязательно хочу юникод в качестве входной, внутренней и выходной кодировки. А именно, utf8, из-за его частичной совместимости с ASCII NUL-terminated strings. Но в процессе реализации выяснилось, что окамловский юникодный лексер ulex не умеет следить за номерами строк, а стандартный ocamllex не умеет следить за позициями в utf8-символах. "Не срачка — так пердячка". Неспешно родил хак поверх ocamllex для отслеживания позиций символов. Скоро будет стадия "release crap" для этого хака, оповещу. А из уже релизнутого говна — окамловская библиотека и утилита для работы с dbf-файлами. Чтобы освежить в памяти git и понять, насколько он уродливее mercurial'а, этот репозиторий я специально оформил средствами git. Фактически, по возможностям, разницы между mercurial и git мало, может разве что git умеет чуть больше извращений, никогда не нужных на практике. Однако mercurial написан для людей, а git — для линуксоидов. Вот и вся разница. Так-то! (Comment on this)
Friday, September 11th, 2009
7:24 pm	Пока не микроскоп :) keywords: jabber pidgin xmpp stanza muc ban user жаббер бан забанить конференция Так как я являюсь модератором одной жаббер-конфы, мне надо уметь банить пидоргов, как самый минимум для оперативного наведения порядка. У меня в качестве jabber-клиента pidgin, и там подобной функциональности нет. Зато есть "Инструменты -> Модули -> Консоль XMPP" (вроде "XMPP stanzas" в английском варианте; потребуется перезапуск). С помощью XEP-0045 и ermine удалось выяснить, что к чему. Включаем модуль, в нём ("Инструменты -> Консоль XMPP -> Консоль XMPP") шлём сообщение: <iq id='ban1' to='конференция@conference.jabber.ru' type='set'> <query xmlns='http://jabber.org/protocol/muc#admin'> <item affiliation='outcast' XXX /> </query> </iq> В качестве XXX — то, что мы хотим забанить. Три варианта. 1. Баним по нику: nick='nickname' 2. Баним jid: jid='user@server' 3. Баним весь сервер (не тестил): jid='server' Так-то! (3 Comments |Comment on this)
1:02 am	Мне тут брателло подогнал презенты: KVM switch D-Link KVM-121 и usb-микроскоп Chronos (не берусь судить об оптике). С микроскопом разберусь потом — это дело не терпит суеты и хуиты. Заодно может слайдэ выложу, уж как получится. Когда распаковал kvm switch, почувствовал себя осьминогом из известного анекдота наедине с волынкой. Реально много проводов, разъёмов. Венда тупая, не стала определять разрешение, использовала известное, чем и выиграла 1024x768. Убунта же повела себя излишне интеллектуально. Опросила монитор, но что-то ей мешало, и в результате я выбил максимум 800x600x60Hz. Не дело. Вообще никак. Погуглив, понял, что дело только в автодетекте. Нашёл какой-то modeline, вписал. Section "Monitor" ... HorizSync 30-96 VertRefresh 50-160 Modeline "1280x1024" 157.5 1280 1344 1504 1728 1024 1025 1028 1072 +hsync +vsync EndSection Понятное дело, что modeline левый, но я использую только заданное разрешение, и оно не переключит монитор в опасни режим. Как показывает сам монитор, это 85Гц таки. Это мне по нраву. Миква-скоп ждите в следующих сериях. (1 Comment |Comment on this)
Monday, August 24th, 2009
1:55 pm	C++ to C++ bindings upd2, final "Папа просил передать вам всем, что цирк закрывается. Нас всех тошнит." Для объекта obj с полем field должно быть так, что присвоение нового значения (obj->field = new_value) в одном рантайме должно вызывать изменение значения obj->field в другом. Учитывая, что код для доступа к obj->field (который нечто вроде *(this+offset)) уже зафиксирован в библиотеке, и поменять его невозможно, получаем, что требуется совпадение раскладки полей в памяти. Так как я его не могу гарантировать, то вся затея лишается смысла. для истории: И смех, и грех, и ёбаный стыд, и блядский C++. Нужно из одного плюсового компилятора использовать плюсовую библиотеку, созданную другим компилятором. По заверениям знающих, напрямую это не получится, потому что даже в случае одинакового компилятора, но при разных рантаймах начинается такое ололо, что проще застрелиться. В качестве предположений имеем немало: допустим, нам известно, что базовые типы (всё, что проще классов и структур) совместимы на уровне abi, у нас есть полный список классов, методов и все их типы, и проблемы начинаются в классах, методах и исключениях. (шаблоны не беру, так как вроде мне они не нужны, да и не знаю, как их рассматривать вообще) От вас же хочется критики. Как про концепции, так и про мелкие подробности. ( Read more... ) А вот теперь мне стоит подумать над следующими вещами: получится ли? Правильно ли получится? Хочу ли я этого? upd1/ FAIL. Если либа или создаёт, или возвращает объекты -- каждый возвращённый объект создавать во враппере? А если надо будет передать объект, который создался в проге, в либу? /me ушёл думать дальше. (1 Comment |Comment on this)
Tuesday, August 11th, 2009
9:35 pm	цитаты вспомнились, найти не могу Может осталось в загашниках у кого цитаты/урлы. 1. рассказ про то, как кто-то (по памяти -- Chung-chieh Shan) на реаллайф-ФП-конфе прикололся: кто-то из студентов предлагал в хаскеле сделать такое преобразование, чтобы чистую функцию автоматически доводить до функции с сайд-эффектами -- liftM/mapM делать автоматически, тайпкласс дорисовывать, или как там это у них делается, и этот Чунг ответил что-то вроде: "так уже есть такая штука -- окамл называется". Предположительно рассказывал не сам Чунг, и дело было в caml-list. 2. цитатку насчёт использования ФП для генерации гарантированно-корректных программ в контексте то ли exponential money / linear time, то ли linear money / logarithmic time (предположительно от авторов "(jon|jones)" в ocaml_beginners@yahoo). (Comment on this)
Saturday, August 8th, 2009
7:47 pm	Ух ты. Впервые в жизни побывал в топорном пункте как поциэнт. Ощущения незабываемые -- шмон, все дела. Не то, что бы я гордился собой... Но галочку поставлю. upd1: болончек с газиками слезоточивенькими таки отняли. Официально -- "ну вдруг ты дурак или пяни, и решишь кому-нибудь встромить -- низзя бьять! а если ты дома и к тебе ворвутся -- тады да, можно." Я, конечно, отморозился и не узнал, как можно такое дело в доме юзать. Да хотя бы даже в подъезде. (3 Comments |Comment on this)
Sunday, August 2nd, 2009
12:39 pm	Моя ёбаная кошка смотрит на вас как на говно: (полная версия кликабельна, если чо) Снял зенитом на плёнку. Если рассматривать попиксельно, то весьма неплохо для плёночного, скажу я вам. Но эта фотка -- скорее исключение, а мои кривые руки -- скорее правило. Ещё надо бы надрочить отчёт (с иллюстрациями в виде слайдов) о том, как я кайфово провёл 4 дня на морях в Одессе, на Лузановке, но чото всё влом. Или потом, или забью. А ещё делаю такую примитивную штуку, как thread pool на окамле (задача тупая -- обработка нескольких tcp/ip соединений в разных окамловских потоках). Хочу сделать обще, реюзабельно, заодно посмотреть, как получится с разбитием этого дела на процессы, на случай многопроцессорных архитектур. (Comment on this)
Wednesday, July 22nd, 2009
12:16 am	(по мотивам обсуждений первого выпуска известно чего) для нормального погромиста непонимание и недооценивание практической пользы функционального программирования — ровно такой же долбоебизм, как непонимание и недооценивание практической пользы императивного программирования, и ровно такой же долбоебизм, как непонимание и недооценивание практической пользы объектно-ориентированного программирования, и ровно такой же долбоебизм, как непонимание и недооценивание практической пользы декларативного программирования. Любое обратное тоже верно. То есть, я считаю долбоёбами всех непонимающих и недооценивающих любое из вышеперечисленного. И априори. Которых тоже считаю долбоёбами. а в overbld (ocaml for mingw win32) — обновки, добавлено немало. В качестве milestone выбрал компиляцию sulci (это такой jabber bot) падвендой. Получилось, но запускать особо не пробовал, хотя грубой ругани нет. Зато ocamlnet с его fastcgi таки отладил, даже падвендой по fastcgi работает с nginx, тестовые примеры вполне ок. (13 Comments |Comment on this)
Sunday, July 5th, 2009
12:03 pm	fido, текущий взгляд цитата из разговора посредством IM (ник собеседника заменил, так как не знаю, как он отреагиюрует на постинг) (11:48:13) n: меня ща беспокоит, почему ффиде нифига нет почты.. сломалось чё, или ет? (11:49:31) gdsfh: неужели наконец вся пидошка сломалась? вот щасте будет! (11:51:55) n: кому щастье? (11:52:50) gdsfh: людям щасте будет. забудут это как страшный сон. (11:53:26) n: кого забудут, бинкд или гойдед? (11:59:22) gdsfh: бинкд мало привязан к пидошным стандартам. адресация, резолвинг, спец.обработка pkt и аттачей, и вроде как всё. гойдед -- забыть надо. вместе с кучей ебанутых форматов -- msg, pkt, squish, jam и так далее. как я помню, не-ебанутых там действительно мало. соответственно, забыть нахуй тоссеры, линкеры баз, пуржеры. но это с технической точки зрения. главное же, что надо забыть, предварительно надругавшись над, это ебанутая иерархия, свинское поведение (следующее из духа фидо и иерархии), эти смешные "модераториалы" (блять, арифметика звёздочек! ебануться можно!), пидорасов-клоунов и клоунов-пидарасов, скачущих по всей пидошке, фимозников, фидарасов, ебанашек с ЧСВ овер 9000, модерашек с синдромом вахтёра, и прочих достойных личностей. НАТЕ НАТЕ НАТЕ11111 // с уважением, 2:469/105. (10 Comments |Comment on this)
Monday, June 29th, 2009
10:37 pm	gobby На данный момент единственная польза от icfpc'09, в котором я не участвовал, состоит в том, что узнал о существовании софтины gobby -- редактор, позволяющий совместно редактировать текстовые файлы, по tcp/ip, в реалтайме. Кроссплатформенный, выделение цветами кто-что редактировал, есть выделенный сервер (sobby), есть встроенный чат. Мне давно такой штуки не хватало. Может кому-нибудь тоже вдруг. Единственное, что ниасиливаю -- их концепцию файлов. Всякими autosave-{interval,file,directory} не получилось нарулить простую и тупую модель, в которой был бы сервер, хранящий файлы и директории, и была бы возможность работать с файлами, имея централизованную рабочую копию файла на выделенном сервере. Пока же получилось только так: инициатор сессии берёт свою копию файла, создаёт сессию редактирования этого файла, и уже всё работает дальше относительно его рабочей копии, что кажется не слишком удобным. (Comment on this)
Wednesday, June 24th, 2009
8:40 pm	misc Сделал бастурму по технологии d_sanin, описанной тут, с подробностями и картинками. Первые, самые мелкие кусочки уже готовы, сейчас попробовал один. Понял ошибки, понял методы улучшения, но, в целом, получается весьма приятное вяленое мясо. Есть две основные проблемы при изготовлении: 1. специя "чаман" (также известная под кучей других названий) не везде продаётся. Мне повезло, у нас на базаре есть. И продаёт её грамотный чел в шаблоноразрывающей майке "Microsoft Sales Manager", 2. свежая говядина, нужный кусок. То, что у автора называется "щуп", у нас ищется как "мясо с внутренней части бедра". Однако и из другого мяса тоже ок. Смысл -- чтобы было меньше прожилок и подобного. У меня вроде даже из шейки, не помню точно. Остальное не проблема совершенно. Справится даже самый блоггер. А я тем временем зомышляю. На icfpc команду собирать не думаю, так как я с тех пор не стал сколько-нибудь заметно лучше хоть в каком-нибудь плане, а условия тут ещё более жёсткие. Разве что чисто для себя порешаю, если будет иметь смысл. Из программирования -- пытаюсь понять на практике, до какого уровня применимы окамловские функторы. Типизация у них, конечно, интереснее, чем у обычных значений, но и ограничения: всё, что входит-выходит в-из функтор(а), может оказаться не first-class value, то есть, и не значением вообще. А, например, модулем, как любезно подсказывает К.О. Бинарные билды overbld -- это, конечно, круто, но надо бы и публичный репозиторий с исходниками поднять. В идеале -- с публичным push. Из vcs я уважаю mercurial и недолюбливаю git, однако у людей свои предпочтения. Если брать "и нашим, и вашим", то нужен какой-нибудь софт для того, чтобы иметь репозиторий (или два) с доступом как по протоколу mercurial, так и по протоколу git. Но разница между ними слишком большая, поэтому, предполагаю, технологически проще было бы сделать два репозитория и грамотную синхронизацию между ними. Фактически, от репозиториев, хранящихся где-то на сервере, требуются только функции clone, pull, push: создать копию репозитория, стянуть чужие изменения в локальную копию, засунуть свои изменения в удалённый репозиторий. А между двумя репозиториями -- two-phase commit protocol, или же тупые блокировки, что непринципиально. (Comment on this)
Sunday, June 21st, 2009
12:38 pm	Вчера отдыхали в лесу у реки. У рыбака выменяли мелкую рыбёшку (\approx 15см), и мне доставило некое удовольствие своими руками её убить, распотрошить и тут же зажарить. Пожалуй, эта рыбка посредством моих рук прошла самое быстрое преобразование из живого существа в еду, которое я видел в своей жизни. Пишите хороший код, а плохой код не пишите. Вместо написания плохого кода лучше отдыхайте на природе, в хорошей компании и с жареным мясом. (1 Comment |Comment on this)
Friday, June 19th, 2009
12:23 am	OVerbld Как обычно. Те, кому я говорил про OVerbld, мало понимали смысл, а тем, кто мог бы понять, я не говорил из-за неуместности и вообще скуки всего этого унылого процесса. keywords: ocaml windows mingw x86 x86_32 binary distribution repository В целом, я сделал систему сборки окамла и библиотек (весьма общую, не ограничивающуюся окамлом), работающую не только под юниксами, где всё тривиально, но и под виндами (конкретнее, из cygwin/mingw/msvc в качестве основы выбрал mingw как наиболее расово-верную платформу; msvc тоже нужен и скорее всего будет, а cygwin сделать вообще легко). В планах — расширение набора библиотек и прочие нехитрые радости жизни. Однако, оказалось, исходники — это мало кому нужно, и сейчас в моде бинарные билды. "Да хуйня вопрос!", — сказал я, и надрочил бинарных билдов под винду. Ну реально не жалко, и самому полезно. Всё это дело я решил обозначить урлом http://overbld.tk/, однако, из-за неведомой ёбаной хуйни данная ссылка открывается не всегда, поэтому и доступность повышу, и заодно пропеарю моего хостера, который помог как минимум мне, как максимум кому-либо из вас: http://overbld.abcname.net/ Акута матана. И вообще, уважайте матан. (17 Comments |Comment on this)
Wednesday, May 27th, 2009
1:53 pm	из рубрики "сто интересных фактов обо мне" Несмотря на то, что псиносрач является известной дисциплиной Специальной Олимпиады, позволю себе публично выразить своё мнение по этому вопросу. Я — за "живодёров", против "зоофилов". А ещё у меня дома живут две милые кошки. (1 Comment |Comment on this)