Что следует знать перед выполнением установки Windows

А что не позволило написать «перед установкой Windows»? Давайте уж сразу «перед началом выполнения установки», великий и могучий всё стерпит.

Чтобы обеспечить корректную работу всех своих возможностей, Windows может создать дополнительные разделы для системных файлов.

Установка Windows не может быть выполнена в это местоположение.

Неудивительно, что студенты в дипломах пишут:

Настоящее время – это время больших вычислительных возможностей, но качество программного обеспечения часто подводит нас своими изъянами.

Всё началось с того, что понадобился удобный способ выполнять вычисления на страницах MediaWiki. Установил расширение Scribuntu, немного почитал про Lua и реализовал необходимые функции. Дальше началось странное — функция возвращает число, которое становится значением свойства. Все значения выводятся нормально за исключением '1' — вместо него появляется ссылка на совершенно непричастную страницу. Чудеса начались.

Задаю вопрос в списке рассылки, параллельно пытаюсь повторить неправильное поведение. В процессе выясняется, что в нашей wiki была страница '1', которую затем переименовали в «совершенно непричастную страницу» без перенаправления с '1' на новую страницу. Из списка рассылки отвечают, что действительно, была такая ошибка и перенаправление в базе данных устанавливалось, даже если эта галочка при переименовании страницы была снята, надо проверить на последней версии.

Устанавливаю MediaWiki последней версии. Пытаюсь повторить странное поведение — сначала всё в порядке, но после нескольких переименований значение свойства таки меняется.

Лезу в исходники и базу данных старой wiki — действительно, в исходниках проблема есть, перенаправления в базе данных установлены. Если бы я не успел попробовать на последней версии — успокоился бы. Но в последней версии-то ошибка исправлена, а с переименованиями всё равно что-то неладно!

После долгих поисков нашлась последовательность действий, приводящая к странному результату:

• cоздать страницу ‘1’
• создать страницу ‘S’ с определением подобъекта, имеющего свойство P=1
• создать страницу ‘Q’ с запросом, выводящим подобъект и его свойство.
• переименовать ‘1’ в ‘One без установки перенаправления
• перейти на страницу ‘Q’
• убедиться, что значение P по-прежнему 1
• заново создать страницу 1 и переименовать её в ‘Two’
• перейти на страницу ‘Q’
• убедиться, что значение P изменилось на Two

Чудеса продолжаются. Точно не знаю, какое поведение правильное, но оба варианта правильными быть не могут, значит ошибка точно есть!

Включаю MediaWiki debug toolbar:

$wgDebugToolbar = true;

И с помощью отладочной печати пытаюсь разобраться, что происходит. Когда надоело повторять одни и те же действия, установил Selenium IDE и записал скрипт — «вкалывают роботы, счастлив человек».

Когда отладочной печати стало не хватать и появились мечты о нормальном отладчике PHP кода на удалённом веб-сервере, разобрался в вопросе, установил xdebug и Eclipse с PHP Development Tools. Наставил себе точек останова и нашел, что после первого переименования страницы значение семантического свойства в таблице smw_di_wikipage тоже меняется, но по окончании транзакции этих изменений в базе данных нет! Оттрассировал все операции с этой таблицей и понял, что изменения откатываются с помощью задания на обновление информации о странице 'S', которое выполняется уже после обработки переименования страницы '1', поэтому-то я его в отладчике и не поймал.

А почему же после второго переименования не произошло обновления страницы 'S' и отката изменений в семантической информации? Оказывается, есть ещё поле smw_proptable_hash в таблице smw_object_ids, в котором хранится хэш сериализованного массива свойств. Перед обновлением свойств считается новый хэш и, если он совпадает со старым, изменения не записываются, потому что они уже в базе. В этом случае данные точно не соответствовали тому, что лежало в базе, а хэши были одинаковые.

Вот и первая ошибка: при переименовании страницы таблица со значениями свойств изменяется, а её хэш не обновляется, поэтому и отката изменений не происходит — хэш не изменился, значит и изменений не было.

Но почему эта ошибка проявляется только при втором переименовании? А потому что

Вторая ошибка: при сериализации массива свойств первый раз ключами в нём являются числа, а во втором и последующих — строковое представление этих чисел. Привет поклонникам динамической типизации!

Поэтому хэши как бы одинаковых массивов оказываются разными и изменения в семантическая информации откатываются, создавая иллюзию правильного поведения. А на самом деле просто компенсировались эффекты от двух ошибок. К счастью, только при первом переименовании, потому и удалось выловить их обе. Пойду писать баг-репорты.

git clone ssh:user@host:port/path

вызывает ssh с параметром -p port. Но под Windows при использовании putty (точнее, plink) в качестве ssh возникает ошибка

plink: unknown option "-p"

потому что putty пошел своим путём и опция у него -P.

Самый простой способ решения: найти в файле plink.exe любым hex-редактором (я по старой памяти использовал hiew, достаточно демо-версии) эту опцию и исправить её: -P -> -p (0x50 -> 0x70) в двух местах (одно — разбор командной строки, второе — вывод подсказки).

Это влияет на вывод значений свойств и результатов семантических запросов — функций ask и show. Разбираясь с этой системой я довольно болезненно наступил на грабли.

Дело в том, что результат работы функций ask и show может использоваться для установки значения свойства:

[[NewProperty::{{#ask:[[Page]]|?Property}}]]

Но числа, которые являются значениями свойств, должны быть представлены в неформатированном виде — с десятичной точкой и без разделителей тысячных разрядов. Поэтому вышеуказанная конструкция работает не при всех языках и не для всех чисел. Положение исправляет явное указание, что вывод функции форматировать не надо:

[[NewProperty::{{#ask:[[Page]]|?Property#-}}]]

Однако указание формата работает далеко не со всеми форматами вывода. Например, при суммировании значений:

[[NewProperty::{{#ask:|?Property#-|format=sum}}]]

результат всегда выводится в форматированном виде. При разборе числа происходит ошибка и значение свойства не устанавливается.

Я нашел три решения этой проблемы, но одно из них не работает.

1. Конструкция {{formatnum: number |R}} должна бы из форматированного числа number делать неформатированное. Но, насколько я понял, форматирование ожидается в локали по умолчанию, а не в текущей, поэтому не работает.
2. Можно пропатчить файл mediawiki/extensions/SemanticResultFormats/formats/math/SRF_Math.php, чтобы воспринимались указания форматов. Там есть функция

   protected function buildResult( SMWQueryResult $results ) {
       global $wgLang;
       return $wgLang->formatNum( $this->getResultText( $results, SMW_OUTPUT_HTML ) );
   }
   

   поведение которой можно сделать зависимым от формата:

   protected static function getFormat( SMWQueryResult $res ) {
           foreach( $res->getPrintRequests() as $request ) {   
               return $request->getOutputFormat();             
           }                                                   
   }                                                           
   
   protected function buildResult( SMWQueryResult $results ) {
       global $wgLang;
       if( self::getFormat( $results ) == '-' ) {
           return $this->getResultText( $results, SMW_OUTPUT_HTML );
       } else {
           return $wgLang->formatNum( $this->getResultText( $results, SMW_OUTPUT_HTML ) );
       }
   }

   Но тут больше вопросов, чем ответов. В частном случае работает, но если суммирование идёт больше, чем по одной колонке, логика непонятна — какой формат учитывать?

3. Вообще не использовать суммирование средствами формата вывода. Вывести слагаемые в список со знаком сложения в качестве разделителя и вычислить полученное выражение с помощью expr. Никаких проблем:

   [[NewProperty::{{#expr: {{#ask: |mainlabel=-|?Property#=|format=list|sep=+}} }}]]