Об экспресс-свиданиях (speed-dates) на Хабре уже писали. Вкратце, собирается группа участников, они беседуют в парах примерно по 5 минут, затем меняются собеседниками. Каждый участник про каждого из своих партнёров отмечает, насколько сильно он ему понравился; если симпатия окажется взаимной, организаторы передают обоим контакты друг друга.

Группа исследователей из Стэнфордского университета занимается анализом человеческих диалогов, пытаясь распознать как намерения говорящего, так и восприятие речи слушателем. Несоответствие между подразумеваемым и воспринимаемым — закономерное свойство естественной речи. Для анализа использовались стенограммы с экспресс-свиданий, на которых каждая сторона оценивала «заигрывающесть» партнёра, и отмечала свою. Построенной системе автоматического распознавания флирта удалось верно определять намерения говорящего в 71.5% случаев; это превзошло точность оценок самих участников экспресс-свиданий. Как выяснилось, люди в большей степени проециируют на собеседника собственные ощущения, чем анализируют его речь.

k_s интересуется: «Я один не догнал логику разрыва ссылки на три части?»

Для ясности, вместо арабских букв в примерах будем пользоваться транслитерацией.

Текст той ссылки в HTML-коде записан так:

Например, wayawm baṣal эта ссылка yawm ʿasal выглядит разорванной

Браузер отображает арабский текст справа налево:

Например, laṣab mwayaw эта ссылка lasaʿ mway выглядит разорванной

Теперь обозначим в HTML-коде саму ссылку:

Например, wayawm baṣal эта ссылка yawm ʿasal выглядит разорванной

Браузер отображает арабский текст в прежних местах, причём части ссылки так и остаются частями ссылки:

Например, laṣab mwayaw эта ссылка lasaʿ mway выглядит разорванной

Упражнение: ткните мышью перед ссылкой, и, нажимая Shift+вправо, расширяйте выделение по одному символу. Так проще разобраться в соответствии между логическим и визуальным порядком символов.

Например, ويوم بصل эта ссылка يوم عسل выглядит разорванной

---

Арабская пословица «yawm ʿasal wayawm baṣal» означает «День — как мёд, а день — как лук.»

В комментариях к блестящему топику «Как выглядит китайская клавиатура» высказали интересную идею: рассказать про набор текста в разных языках с необычной письменностью.

Арабам относительно повезло: у них лишь 28 букв — даже меньше, чем в русском. Каждой букве можно назначить отдельную клавишу, и ещё останутся свободные. Зато с их письменностью возникают свои сложности, неведомые китайцам.

В обсуждении Windows 3.1 на прошлой неделе danSamara упомянул:

Ваша сложная и многогранная система работала у меня в виртуальной машине из под OS/2, которая уже тогда была по настоящему 32-разрядной и многозадачной, а ваша суровая многогранная правда выглядела убого и неказисто.

Как же так вышло, что убогая и неказистая Windows задушила мощную и совершенную OS/2?
Рассказывают разработчики:

Рэймонд Чен: «убойной прогой» для Windows 1.0 — той, ради которой люди готовы были купить новую ОС, — был Adobe PageMaker. Потом появился ещё и Excel.

Ларри Остерман: на самом деле, Pagemaker и Excel были «убойными прогами» для MacIntosh; уже впоследствии их выпустили и для Windows.

Насколько я помню, под Windows вообще не было «убойных прог». Windows 1.0 и 1.1 продавались скромными тиражами по паре тысяч копий в месяц. Windows 386 (версия 2.0) продавалась лучше, потому что позволяла запускать одновременно несколько DOS-приложений. Не любые приложения можно было запускать одновременно; фактически, едва ли можно было запустить что-то более сложное, чем несколько копий GWBasic.

Всё поменялось, когда вышла Windows 3.0.

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

Далее в посте:

1. Оптимизация «в глазок»
2. Стандартные функции
3. Вывод в ELF
4. Как это работает?
5. Что получилось?

В бета-версиях Windows 3.1 был скрытый и зашифрованный код, который при запуске на DR-DOS выдавал непонятное сообщение о вымышленной ошибке.

В релизе решили подобными фокусами не заниматься, но код проверок и само сообщение не убрали: они так и остались внутри WIN.COM, и достаточно изменить один байт, чтобы AARD-код снова выполнялся при каждом запуске.

Зачем его оставили? Неужели Microsoft рассчитывала однажды в будущем разблокировать эти сомнительные проверки?
Конечно же, нет. Даже сообщение в релизе осталось неизменённое: «Please contact Windows 3.1 beta support.» Если бы сообщение действительно предназначалось для показа, после окончания бета-тестирования его бы обновили.

Так зачем оставлять в релизе бессмысленный код, который никогда не выполняется?

Неоднозначную реакцию вызвал рассказ Рэймонда Чена о том, сколько усилий прикладывает Microsoft, чтобы обеспечить совместимость новых версий Windows с чужими программами.

Известен и обратный случай: когда Microsoft намеренно добивалась несовместимости Windows с «неблагонадёжными» клонами MS-DOS. Из выпуска Dr. Dobb's Journal за сентябрь 1993 г.:

Код обнаружения AARD в Windows

Если вы участвовали в бета-тестировании Windows 3.1, и на вашем компьютере стояла DR-DOS, то наверняка вы сталкивались с этим необычным сообщением об ошибке:

Non-Fatal error detected: error #2726
Please contact Windows 3.1 beta support
Press ENTER to exit or C to continue

Хотя это «нефатальная ошибка», и нажатие C продолжает запуск Windows, действие «по умолчанию» — отмена запуска.
Уже подозрительно: если ошибка нефатальная, и Windows способна работать, несмотря на неё, — зачем вообще докладывать о ней пользователю?

Такое сообщение выдавалось программами WIN.COM, SETUP.EXE, HIMEM.SYS, SMARTDRV.EXE и MSD.EXE в нескольких предрелизных выпусках Windows 3.1.
Окончательная версия Windows 3.1 по-прежнему содержит код, выводящий это сообщение. Этот код «выключен», но достаточно изменить один байт в WIN.COM, чтобы его «включить».

Самое интересное в этом сообщении — что оно выводится на всех версиях DR-DOS, включая бета-версию Novell DOS 7, но не выводится ни на MS-DOS, ни на PC-DOS. О чём же это сообщение сообщает?

Это отрывки из бесплатной главы из бумажной книги «The Old New Thing». Они ничему не пытаются научить; это просто короткие забавные эпизоды из будней борцов за совместимость новых версий Windows со старыми приложениями.

Изменяем номер версии Windows

Изменить номер версии, который Windows сообщает программам, не просто, как кажется. Например, некоторые программы проверяют номер версии так:

UINT Ver = GetVersion();
UINT MajorVersion = LOBYTE(uVer);
UINT MinorVersion = HIBYTE(uVer);
if (MajorVersion < 3 || MinorVersion < 10) {
    Error("This program requires Windows 3.1");
}

Представьте себе, как этот код отработает на Windows 95, у которой номер версии 4.0. Вторая проверка срабатывает из-за того, что 0 меньше 10.
И ладно бы программа просто выводила сообщение об ошибке и завершалась. Многие рушились: очевидно было, что их поведение на «неподдерживаемых» версиях Windows никогда не тестировалось.

Таких программ оказалось настолько много, что мы перестали исправлять их по одной, и просто изменили возвращаемый номер версии с 4.0 на 3.95.

Программы для MS-DOS тоже не все гладко реагировали на изменение версии ОС. Это удивительно потому, что к тому времени у MS-DOS уже были десятки выпущенных версий и под-версий, и разработчикам пора было бы уже научиться проверять номер версии. Но например, один пакет программ использовал номер версии DOS как индекс в таблице функций: по собственной функции для каждой вышедшей версии. В таблице было пять функций: от MS-DOS 1.x до 5.x. Когда программа запускалась под MS-DOS 6.0, она вызывала адрес за пределами таблицы, и рушилась.

Изменить номер версии, который Windows сообщает программам, — необходимый, но очень тяжёлый шаг. Пара нажатых клавиш, и падают сотни приложений, отлично работавших до сих пор; теперь отделу совместимости придётся потратить на вылавливание чужих багов лишнюю тысячу человеко-часов.

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

Далее в посте:

1. Выбор кода
2. Загрузчик
3. Изменения в п-коде
4. Генерация
5. Что получилось?

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

Далее в посте:

1. Починка бага
2. Чистка копирований
3. Что получилось?
4. Сворачивание констант
5. Реализация

Обнаружены следующие эффекты:

1. Если при первом нажатии на «черновик» / «предпросмотр» произошёл сбой соединения, то последующие нажатия просто дизаблят кнопки на несколько секунд, но не пытаются отправить топик по-новой. Необходимо перезагружать страницу и копировать в неё текст.
2. В некоторой ситуации (неполная загрузка редактора?) нажатие любой из кнопок приводило к переходу на короткий XML-документ с содержимым наподобие «запощено успешно», при этом топик фактически постился в блог. Трижды нажал на
   предпросмотр — запостил в блог три копии топика.

Коллеги, будьте бдительны!

оригинал опубликован в 2003, и относится к интерфейсу Windows XP

Короткий ответ: потому что заблуждаются.

Длинный ответ: официальное название штуковины снизу экрана — «панель задач» (taskbar). Она состоит из нескольких элементов — кнопка «Пуск», кнопки переключения между задачами, часы, и «область уведомлений» (taskbar notification area).

Распространённая ошибка — называть область уведомлений «треем» (или даже «системным лотком»). Она никогда так не называлась. Если вы встретите в документации упоминание «system tray», можете доложить, что обнаружили ошибку.

Откуда взялось это неверное название?

В ранних версиях Chicago — ещё до того, как проект получил название Windows 95 — панель задач была не панелью задач, а папкой, зафиксированной снизу экрана. Она была всегда на виду, и можно было «бросать» в неё документы и ярлыки для быстрого доступа — аналогично лотку для всякой всячины, который ставят в верхний ящик письменного стола.



Оттуда и взялось название «лоток (tray) рабочего стола». Немного сомнительное продолжение метафоры «рабочего стола на экране» — но всё ещё в пределах здравого смысла. (Вот если бы вместо обоев на стол клали скатерть...)

File names are infinite in length, where infinity is set to 255 characters.
--Peter Collinson: The Unix File System

Итак, у нас есть программа на п-коде, и в её распоряжении неограниченное количество регистров (т.е. 255). Число регистров у реального процессора куда меньше (предположим, четыре). Что будем делать?

Далее в посте:

1. Разбор п-кода
2. Время жизни
3. Реализация
4. Простые оптимизации
5. Расщепление версий
6. Работа с памятью
7. Что получилось?

Первый этап — разбор синтаксиса нашего джей-скрипа — пройден; подбираемся к генерации кода.

Начнём с генерации п-кода (промежуточного переносимого псевдокода) — нечто вроде «абстрактного машинного языка». Его выбирают так, чтобы

• его было легко генерировать;
• его было легко обрабатывать.

Обработка п-кода — это, как правило, его переработка в исполнимый машинно-зависимый код. Тем не менее, можно ограничиться лишь генерацией п-кода, и объявить его готовой скомпилированной программой. Запуск такой программы будет, по сути, интерпретацией п-кода. У этого подхода всё больше и больше сторонников; так что и мы для начала ограничимся компиляцией в п-код.

Далее в посте:

1. Выбор кода
2. Компиляция
3. Выполнение
4. Backpatching

Когда топик длиннее некоторого порога, при его сохранении в черновики конец текста необратимо стирается, что безмерно обидно.

Желаю при сохранении слишком длинного текста получать предупреждение — такое же, как при сохранении текста без хабраката.

До сих пор занимались восходящим синтаксическим разбором. Какие ещё есть варианты?
Отложим бизона в сторону, и вернёмся к теории.

Далее в посте:

1. Идея
2. Воплощение
3. Холивар
4. Бэктрекинг

С грамматиками калькуляторов поиграли достаточно, переходим к языкам программирования. Бета-тестеры статьи подали идею писать JavaScript-подобный язык: начнём с простейшего скобчатого скелета, и будем его постепенно обращивать наворотами — синтаксическим сахаром, типами данных, поддержкой функций, и т.д.

Чтобы неполноценность нашего языка была понятна уже из названия, назовём его JSkrip.

Далее в посте

1. Синтаксис
2. Грамматика
3. Парсер
4. Синтаксическое дерево
5. Pretty-printing

Это единственный пост в серии, в центре внимания которого — старообрядный сишный бизон, так надоевший некоторым. Тем, кто пишет не на Си, пост всё равно должен быть интересен, потому что похожие по принципу работы генераторы LR-парсеров существуют для очень многих языков. Тех же, кто идеологически не приемлет LR-парсеры, мне сегодня привлечь нечем.

Далее в посте:

1. Компиляция грамматики
2. Двухступенчатый парсер
3. Что у него внутри?
4. Конфликты в грамматике
5. Как это работает?

В предыдущем посте было много кода и, по некоторым мнениям, недостаточно объяснений. Будем чередовать: в этот раз будет много теории, а до практики почти не дойдёт.

Далее в посте:

1. Магазинный автомат
2. Формальные грамматики
3. LR-парсинг