Чтобы не забыть команды WinDBG

нужно записать их все сюда.

Примерно в таком порядке я их и использую при отладке минидампов из OCA:

!sym noisy	Включает подробный лог поиска и загрузки символов
.reload /f MyApplication.exe	Перезагружает символы для MyApplication.exe. Предыдущая команда позволяет посмотреть откуда и почему не грузит.
.symopt+0x40	Разрешить грузить даже unmatched PDB файлы
kb	Показать наконец стек

Сжатие старых файлов

В очистке диска начиная с Windows XP появилась бесполезная возможность сжимать "старые" файлы. Из-за того что система оценивает сколько на этом можно выйграть места приходится долго ждать пока появится возможность удалить всё остальное. Я всё время забываю путь в реестре, где это отключается. Запишу тут (Windows XP):

Включается


Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\VolumeCaches\Compress old files]
@="{B50F5260-0C21-11D2-AB56-00A0C9082678}"
"Priority"=dword:0000012c
"StateFlags"=dword:00000000


Выключается


Windows Registry Editor Version 5.00

[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\VolumeCaches\Compress old files]


jpeg lossless rotation & crop

При просмотре фотографий часто выясняется, что держать фотоаппарат боком - не лучшая идея. Приходится разворачивать снимки. Раньше я всегда поворачивал такие изображения только на время просмотра и не сохранял (или сохранял в PNG, что сильно увеличивало размер файла), так как при повторном сохранении в JPEG картинка ухудшится (а мой фотоаппарат сохраняет фотографии именно в JPEG). От этого я особенно не любил встроенный просмотрщик в Windows XP, который при повороте сразу пересохранял изображение.
Оказывается люди придумали решение этой проблемы: jpegtran, который обеспечивает lossless rotation и crop.
Оказалось также, что есть куча программ, которые это используют, вот список.
При помощи gwenview я и развернул и пересохранил большинство своих фотографий. Правда следует учесть что делал я это в gwenview из kde3, gwenview из kde4 (версии 4.3.1) при повороте меняет изображение, что можно заметить даже по пятнам в вычитании двух изображений в GIMP. Насколько я знаю и нагуглил, ImageMagic тоже не умеет вращать или обрезать JPEG без потерь, так что придётся старый gwenview оставить. Под Windows вероятно самым доступным приложением является Irfanview с плагином.

Планшет G-Pen 560 и openSUSE 11.2

Случилось мне прикручивать планшет G-Pen 560 под openSUSE 11.2. Сам планшет без драйверов отлично работает и в Windows и в GNU/Linux как мышка, или как тычпад. Однако ценность планшета именно в абсолютном позиционировании и разной степени давления.
Сначала я попытался делать аналогично инструкции, однако с поправками на дистрибутив. WizardPen есть в OBS и доступен тут, поэтому никакой возни со сборкой и установкой. После загрузки и установки x11-input-wizardpen-0.7.0.alpha2-2.1.x86_64.rpm и x11-input-wizardpen-tools-0.7.0.alpha2-2.1.x86_64.rpm запустил калибровку:

wizardpen-calibrate /dev/input/wizardpen

При этом калибровка попросит ткнуть сначала в один угол планшета, потом в противоположный ему и выдаст подобные строки для xorg.conf:

Driver "wizardpen"
Option "Device" "/dev/input/wizardpen"
Option "TopX" "329"
Option "TopY" "500"
Option "BottomX" "11836"
Option "BottomY" "8910"
Option "MaxX" "11836"
Option "MaxY" "8910"

Далее выяснилось что в openSUSE 11.2 файла xorg.conf уже нет, и всё работает автоматически и без него. Тем не менее, я создал xorg.conf при помощи Sax2 и вставил в него эти строки. После перезапуска исков, они стали падать при любой активности планшета.
Добрые люди подсказали что теперь всем заведует HAL, поэтому мучить нужно его. Я удалил ненужный более xorg.conf (если работает без него, значит пусть и работает дальше).
После этого открыл /etc/hal/fdi/policy/99-x11-wizardpen.fdi, переименовал ключ info.product из "TABLET DEVICE" в "Aiptek" (надо будет разобраться на досуге зачем) и изменил значения остальных ключей в соответствии с тем, что выдала калибровка. Получился такой файл:

<?xml version="1.0" encoding="ISO-8859-1" ?>
<deviceinfo version="0.2">
<device>
<!-- "info.product" MUST match the name of your tablet: -->
<!-- grep -i name /proc/bus/input/devices -->
<match key="info.product" contains="Aiptek">
<merge key="input.x11_driver" type="string">wizardpen</merge>
<merge key="input.x11_options.SendCoreEvents" type="string">true</merge>

<!-- Modify these configurations accordingly -->
<!-- Use "man wizardpen" for the full-set of -->
<!-- configurable options -->
<merge key="input.x11_options.TopX" type="string">329</merge>
<merge key="input.x11_options.TopY" type="string">500</merge>
<merge key="input.x11_options.BottomX" type="string">11836</merge>
<merge key="input.x11_options.BottomY" type="string">8910</merge>
<merge key="input.x11_options.TopZ" type="string">75</merge>
<merge key="input.x11_options.debugyn" type="string">0</merge>
</match>
</device>
</deviceinfo>

В TopZ регулируется чувствительность к касанию, настраивается индивидуально.
Воткнул планшет и он заработал как надо! Правда GIMP думает что это Aiptek, но это не суть важно.

Крабозябры в IRC

Меня уже несколько раз спрашивали, и уже надоело объяснять каждый раз заново. Поэтому ответ будет лежать тут, пока не понадобится мне в очередной раз.

Дано: люди, пишущие гигантской длины сообщения в IRC с кириллицей.
Проблема: люди видят крабозябры вместо обрезанного сообщения.

Как написано в RFC 1459 на 8й странице,
а также в RFC 2812 и
RFC 2813
на 6й странице:

IRC messages are always lines of characters terminated with a CR-LF
(Carriage Return - Line Feed) pair, and these messages SHALL NOT
exceed 512 characters in length, counting all characters including
the trailing CR-LF. Thus, there are 510 characters maximum allowed
for the command and its parameters. There is no provision for
continuation of message lines.


Это ограничение довольно быстро достигается в случае длинных сообщений, кроме того перед непосредственно сообщением идёт также служебная информация протокола, которая тоже занимает место в этих 510 байтах. Например, в случае отправки сообщения в канал это выглядит как:

PRIVMSG #имяканала :имя сообщения\r\n

по двоеточию сервер догадывается, с какого места идёт собственно сообщение. Все лишние байты сервер попросту обрежет. Более того, при передаче другому клиенту сообщение ещё более сократится, чтобы вместить служебную информацию (кто сказал) и все равно уместиться в 510 байт.

логин!идент@маска PRIVMSG #имяканала :имя сообщения\r\n

Бороться с нехваткой байт под длинное сообщение можно по-разному. Большинство клиентов либо обрезает сообщение перед отправкой до 512 байт, либо отправляет как есть и тогда его обрезает уже сервер. Некоторые (например, XChat и некоторые скрипты к mIRC) разбивают сообщение на несколько и отправляют их подряд.

Ситуация усугубляется тем, что в UTF-8 кодировке символы кириллицы представляются двумя байтами. Если разрезать сообщение посреди символа, то такая последовательность байт уже не будет правильной unicode-последовательностью и у многих клиентов возникают проблемы с корректным отображением такой строки. И если WeNet и Rusnet используют однобайтовые кодировки, то на Freenode используется именно UTF-8 и пользователи нередко начинают выяснять отношения.

Для иллюстрации вышесказанного я нашел свой старый эксперимент по написанию IRC-бота, перенастроил его на FreeNode и дописал следующий код на команду "sayit":


if(order == "sayit")
{
// в этой строке 540 байт (UTF-8)
const char bigline[] = "КрабозябраПридиКрабозябраПридиКрабозябраПриди"
"КрабозябраПридиКрабозябраПридиКрабозябраПридиКрабозябраПридиКрабозябраПриди"
"КрабозябраПридиКрабозябраПридиКрабозябраПридиКрабозябраПридиКрабозябраПриди"
"КрабозябраПридиКрабозябраПридиКрабозябраПридиКрабозябраПридиКрабозябраПриди";
send_private_message(bigline, channel);
}


540 байт это явно больше 510. Моя реализация send_private_message не обрезает сообщения и посылает его как есть. Таким образом, в данном случае обрезание выполняется сервером, который рассылает это сообщение клиентам.

Для демонстрации я взял IRC-клиенты, находящиеся у меня под рукой: KVIrc (версии 3.4.3 и 4 из svn), XChat (версия 2.8.6), Konversation (версия 1.2). Интересно было бы проверить ещё на mIRC, но у меня его нет.

Заведя бота и клиентов на уединённый канал, я несколько раз дал боту комманду "sayit", затем попытался отправить очень длинные строки из каждого клиента и проанализировал результаты.

KVIrc

Этот используемый мной клиент - лучший выбор когда нужно читать. В нём корректно отобразились все строки, посланные всеми клиентами (с учётом укорачивания, конечно). К сожалению, отправляемые строки сам клиент режет по 512 байт, ничуть не заботясь о границах символов. Надеюсь, это кто-нибудь исправит, или хотя бы напишет скрипт.

XChat

Этот клиент успешно делить длинные сообщения на несколько, что делает выбором тех, кто пишет. Сообщения от бота он тем не менее пережил нормально, видимо обрезалось удачным для алгоритма образом. А вот длинные сообщения от KVIrc и konversation он показал крабозябрами.

konversation

Этот клиент корректно показал сообщения от kvirc, но показал крабозябры от бота. Сам он умеет делить сообщения на несколько, но это совершенно не спасает от проблемы обрезания сообщения сервером после добавления имени и маски.

Вывод

Дело с клиентами IRC обстоит как всегда печально. Повтор одного и того же длинного сообщения несколько раз заставляет клиенты то показывает его правильно, то неправильно. Это видимо зависит от того, как трактует их алгоритм преобразования байт в символы. Если вы хотите избежать выяснения у кого клиент хуже, и что вы пишете-таки в UTF-8 - пишите сообщения покороче.

Qt 4.6.1

Тролли ударными темпами делают свою библиотеку. Казалось бы недавно только вышел 4.6.0, как уже готов bug-fix release (changelog). В основном эта версия чинит производительность (открытие файла наконец не вызывает stat) и лики. Также починили waitForConnected под Windows, что радует.
С нетерпением ждём следующих версий.

Сообщения об ошибках


int main()
{
long long long int a;
}


Компилятор Microsoft:

error C2632: '__int64' followed by 'long' is illegal

Скучно и как-то казённо. Вот g++/mingw - другое дело:

error: ‘long long long’ is too long for GCC