Переехал с svn на git. bisect, stash и прозрачные, удобные бранчи заставляют биться в экстазе.
Паблик: git://github.com/0xd34df00d/leechcraft.git
SVN будет закрыт через неделю-другую.

Прям месяц изменений какой-то.

Внезапно обнаружил, что здесь недалеко стоит awstats, чем и воспользовался.

Соотношение WIn и Lin совсем не такое, как в общепринятых статистиках.

По браузерам все еще веселее (взяты первые N):

Если глянуть более детальную статистику, окажется, что большинство фоксоюзеров пользуется свежим 3.0.5. Заботятся о безопасности, чо. Почти никто не сидит на 3.1. Красноглазики кончились, чо.

Поисковые запросы — 72.8% принадлежит словам "openid", "account", "login", что символично, т.к. OpenID у меня до сих пор сломан. Также заставили улыбнуться следующие единичные случаи шизофрении:

• перехожу на jabber
• опенсорс
• настройка tp-link 8811 opensuse (этот не единичный, аж трое таких)
• opensuse 11.0 настройка tp link adsl 8811 (Зомг, еще один. Почему мой блог?! Я сроду не юзал opensuse и не настраивал этот девайс)
• КО-52/Н
• index-pack failed что делать

Погрели душу:

• установка debian на inspiron 1525
• скачать альбом группы cue bring back my love
• wonder what’s next
• pdf for pocket pc (и еще два подобных запроса)

А вообще, это неудивительно, ведь 75.1% хитов пришло с Windows Live, оставшиеся — с гугла. Забавно, что больше никаких поисковых систем.

В избранное добавили 10% посетителей.

Проснулся в 3 утра, пофиксил логическую ошибку в дополнялке тегов, которая не давала мне покоя уже больше полугода, ушел в сон дальше. Положительно.

Допилил Openbox + stalonetray + tint2 + conky + xcompgr.

(Кликабельно, 1MB)

У фона заметил уже один недостаток - пыль на мониторе видно.

Потребовалось тут написать прогу, производяющую хитрющие манипуляции со входным потоком байт (расшифровка спектра гамма-линий ядерного распада изотопов тория), с гуйками и прочим, и под виндой, чтобы было все красиво. Естественно, взял C++ + Qt, количество строк в программе - 48, объем конечной программы, учитывая либы куте и редист MSVS - 8 метров. Набросал скрипт для NSIS, так что в инсталлере все это весит чуть меньше пяти метров. Да, пять метров для простой тупой программы. Докатились. Надо было на пейтоне писать.

Ну вот и начала глючить вентиляция купленного в конце августа Dell Inspiron 1525. То ли засорилась пылью, то ли термопаста подсохла, в любом случае - компилирую сейчас новый Psi, а проц разогрелся до 94 градусов, корпус трещит, напоминая подводные лодки в американских фильмах. В режиме покоя сейчас под 50 градусов, а после покупки было — 38-40. Не дело, надо будет открыть, почистить и термопасту обновить.

На днях в разговоре с одним товарищем, согласившемся участвовать в LC, выяснилось, что для реализации поддержки поисковых запросов типа category:torrents AND metallica the unforgiven AND NOT (live OR video) нужны ДНФ/КНФ. Не вершины дискретного анализа, конечно же, но нехило так прибавляет мотивацию учиться.

SIGMOLE: Pigmentation fault.

Mole - родинка, есличо.

Вот уж не думал, что увижу такие цифры в обозримом будущем на своей домашней машине. А увидел.

% sudo ifconfig lo
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:104820133543 errors:0 dropped:0 overruns:0 frame:0
          TX packets:104820133543 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1144708071012775 (1.0 PiB)  TX bytes:1144708071012775 (1.0 PiB)

Если грузить библиотеку, юзающую какой-либо класс, через dlopen, то слияния объектов type_info не произойдет, поэтому имеем забавное поведение, а лично я поимел три часа секса от обнаружения сломанного dynamic_cast до написания тесткейса.

classb.h:

struct a
{
        virtual ~a() {}
};
 
struct b : public a
{
        virtual ~b() {}
};

test2.cpp:

#include <typeinfo>
 
#include "classb.h"
 
extern "C"
{
        a* getnewb() { return new b; }
        const std::type_info& gettypeb() { return typeid (b); }
}

test.cpp:

#include <dlfcn.h>
#include <typeinfo>
#include <iostream>
#include <cassert>
 
#include "classb.h"
 
typedef a *(*func_t) (void);
 
int main()
{
        func_t func;
        const std::type_info& (*type) (void);
 
        void *handle = dlopen ("./test2.so", RTLD_NOW);
        func = (func_t) dlsym (handle, "getnewb");
 
        type = (const std::type_info& (*) (void)) dlsym (handle, "gettypeb");
 
        a *a_ptr = (*func) ();
        const std::type_info& t = (*type)();
 
        assert (dynamic_cast<b*> (a_ptr));
        assert (typeid (b) == t);
}

Компилять:

g++ -g -fPIC -o test2.so -shared test2.cpp
g++ -g -o testcase test.cpp -ldl

UPD: Если чуть подробнее, type_info::operator== на линугзах (ну и везде, где есть поддержка weak symbols) в общем случае сравнивает указатели на строки с типами вместо честного strcmp по самим строкам. В обычных условиях все type_info для физически одинаковых объектов изменяются так, чтобы указатели указывали (разработчики разрабатывают) на одну и ту же строку, это и есть слияние (merging). Если грузить библиотеку через dlopen, как в примере, то этого не происходит, поэтому получаем интересное поведение, как, например, assertion failed в примере.

Однако, мне не очень понятно, почему функция-член объекта, создающая его клон, определенная в чужой библиотеке и вызываемая в моем коде, не избавляет от всех проблем. Возможно, инлайнится, надо еще об этом подумать.

http://labs.trolltech.com/blogs/2009/01/14/nokia-to-license-qt-under-lgpl/

Да, я был прав год назад, когда писал, что не стоит париться из-за покупки Нокией Trolltech.

Девятая студия ниасиливает std::find на контейнере (std::vector в моем случае) с POD-структурой, определенной внутри другого класса, если явно не определен operator== как функция-член этой структуры.

<komputes> I'm on a unix based operating system which means i get laid as many times as I have to restart my computer
<marky-b> same, but i run windows

На домашней машине:

% uptime
19:40:40 up 226 days, 5:07, 12 users, load average: 2.48, 2.43, 2.37

Захожу на what.cd, а там, наконец:

* Up: 8.88 GB
* Down: 8.84 GB
* Ratio: 1.00

Надо выкачать что-нибудь большое и толстое по этому поводу.

Накачал тут свежего флака с what.cd, а для айпода лучше бы в ogg vorbis перекодировать, чтобы драгоценное место там не занимал. Уже довольно давно для этих целей пользую flac2ogg (аттач номер 1), который вызывается в форме flac2ogg *.flac и автоматически перекодирует файл из флака в ogg, сохраняя соответствующие теги и имя файла (меняя .flac на .ogg, естественно).

Сегодня же я внезапно понял, что, имея четырехъядерный процессор, грешно перекодировать в один поток, надо бы это дело как-то параллелизовать. После недолгих раздумий решено было написать makefile, который бы просто вызывал уже существующий flac2ogg.

Все бы ничего, и makefile в пять строчек получился, если бы не наличие пробелов в имени файла. После небольшого гуглежа получаем монстрика, который сейчас лежит во втором аттаче к этому посту. Пользуйтесь на здоровье. Запускаем как make -jN -f /path/to/Makefile, в самом мейкфайле надо подправить путь к скрипту flac2ogg.

Также, не уверен, как друпал кросспостнет ссылки на аттачи в ЖЖ, поэтому для лже-читателей:
flac2ogg
Makefile