to post messages and comments.

На накосе смог открыть, наконец, образы Copland, которые не кололись 7zip’ом. SOM DTK там внутри не обнаружил, а это, например, IDL для SOMObject. Но системные IDL там были в изобилии. Однако, что показалось мне странным, многие из них не содержат описание классов. Там только структуры и обратные вызовы.

Но были и те, что с классами, например, всё, что начинается на HI. Это была интересная наводка. Я вспомнил, что в накосе для более лёгкого портирования была (и сейчас есть, но только для 32х бит) система библиотек Carbon. Теперь, когда в экосистеме классической макос мне известно что-то объектное, кроме OpenDoc, стало логичным посмотреть, а куда это делось в Carbon. В статье на Википедии про Carbon прочитал такое:

HIObject — a completely new object-oriented API which brings to Carbon an OO model for building GUIs. This is available in Mac OS X v10.2 or later, and gives Carbon programmers some of the tools that Cocoa developers have long been familiar with. Starting with Mac OS X v10.2, HIObject is the base class for all GUI elements in Carbon. HIView is supported by Interface Builder, part of Apple's developer tools. Traditionally GUI architectures of this sort have been left to third-party application frameworks to provide. Starting with Mac OS X v10.4, HIObjects are NSObjects and inherit the ability to be serialized into data streams for transport or saving to disk.
Но какой может быть «completely new» в системе библиотек, которые нужны только для портирования? Это осколок былого величия, наскоро сделанная замена SOM. Вместо somBuildClassHIObjectRegisterSubclass, вместо somDataResolveHIObjectDynamicCast и т.п. Кстати, доступ к полям через HIObjectDynamicCast значит, что это нехрупкое ABI. Также, через QuickTime SDK, HIObject попал и на Виндоуз тоже, в собственно плеер, Сафари и айТюнс.

OS/2 2.0 Technical Library: System Object Model Guide and Reference
Бывает забавно производить впечатление на разработчиков Objective-C (которые делают libobjc2 для GNUStep, например) тем, что в SOM нехрупкое ABI появилось в 1992м. Они проверяют, и да, так и есть. То, что они, как им кажется, повторяют за Эппл, гораздо старше, чем они думали. Да и в Эппл, с учётом SOM, получается, что нехрупкое ABI появилось не в 2000х, а на десять лет раньше. В 2000х было просто возвращение к некогда занятым позициям, утраченным с приходом Джобса и переходом на менее совершенный в те годы Objective-C.

Но 1992ой — это появление SOM 2.0, который сильно отличался. Там вместо старого SOM OIDL был принят CORBA IDL с дополнениями, было реализовано множественное наследование (к сожалению, по типу C++, а не Dylan/CLOS), и механизм скрещивания метаклассов по требованию. И большая часть материалов по SOM, что удалось найти, была из 1994-1996 годов. Чем был, а чем не был SOM 1.0, соответственно, оставалось неизвестным, и на всякий случай на 1991й год я не замахивался.

Теперь с обнаружением этого документа можно утверждать, что нехрупкий ABI был в SOM с самого начала, с 1991го года. На странице 13 (1-2) прямо указано, что можно добавлять и методы, и поля, и даже удалять непубличные. А на других страницах можно видеть описание старого синтаксиса OIDL, который был только в SOM 1.0.

Пара программ, котороые мне очень нравились, в Эпп Стор не присутствуют: Disk Inventory X и Colloquy, потому что их забросили, хотя если последний Colloquy требует 10.7, то Эпп Стор к тому времени уже точно был (10.6.6), так что странно. Это ж такая мегаштука! Как глоток свежего воздуха после Thunderbird вернуться на шустрый и одновременно приятный некрасному глазу Colloquy.

Обнаружил в 10.11 El Capitan /etc/pf.conf , pf.anchors и прочее, а ведь в 10.4 Tiger был ipfw. Здорово, давно не виделись.

На каникулах в 2006м году попросила меня одна фирмёшка, которую, со слов начальника, задолбали хакеры, сделать им сервер и шлюз понадёжнее. Поставил им NetBSD, pf, djbdns, qmail в chroot и ftp-proxy (ALG для активного режима FTP, а то у них очень важные скрипты не работали с внешним сервером). Заработал 3000руб., первые деньги в своей жизни.

Мучаюсь с уже трёмя мёртвыми почтовыми ящиками. С живым-то хорошо, в крайнем случае создал учётку на новом компе, и через несколько часов он уже всё слил и проиндексировал. А вот как сделать, чтобы почта, которая есть в установленном клиенте на другом компе, со всеми папками попала из одного клиента в другой — это очень весёлая история. В Apple Mail при первом запуске апгрейд почтового ящика завершался сегфолтом, пока я не переименовал ~/Library/Mail в ~/Library/Mail.old и не начал заново. Если теперь попытаться импортировать из другой папки, импортёр очень долго думает, а потом показывает список с галочками из десятков тысяч файлов. Так как там и живые ящики, и мёртвые, надо будет переместить директории так, чтоб для импорта остались только мёртвые. Но всё ещё не понятно, куда эти письма пойдут, будет ли структура как была раньше.

Есть идейка поставить уже наконец Citadel и влить туда на IMAP архив всех старых ящиков, а оттуда разлить по компам.

Ubuntu для мобильных устройств: посмертный анализ
В какой-то момент мне пришлось пересобирать и обновлять моё приложение glmark2 в каталоге, потому что вышел OTA с обновлёнными клиентскими библиотеками Mir, хотя ОС заявляла тот же уровень совместимости, что и раньше. Затем стало ясно, что схема версионирования просто гарантирует, что официальный метод написания приложения гарантированно работает, но официальный метод — это просто QML и HTML5. Программа glmark2 взаимодействовала напрямую с Mir, как и многие другие (например, игры с использованием SDL). Приложения в каталоге могли просто прекратить работать, если не проверять и обновлять их после каждого OTA. Вы по-прежнему можете запускать старые Android-приложения на современном Android-смартфоне, но вот приложение Click с прошлого года может прекратить работу после следующего OTA, если вы не отслеживаете его постоянно. Я помню яркую дискуссию в IRC в конце 2015 года, во время которой несколько разработчиков Canonical были озадачены этим фактом и спрашивали у сотрудников группы SDK, как, по их мнению, разработчикам приложений работать в таких условиях.
Такое чувство, что то, что гремело в 1990х и чем я долго интересуюсь, теперь стало какой-то эзотерикой. Папуасы откуда-то нашли магнитофон, уже не могут сделать ни такой же, ни лучше, зато могут сломать последнее, что есть. Из рук всё валится.

Так что многие из нас создавали простенькие веб-приложения
Вот-вот.

Попробовал собрать приложение для теста (TextEdit) и обнаружил, что оно на Mac OS X 10.11 El Capitan даже не запускается, собрано под 10.12 Sierra. Ну ладно, подумал я, и попытался переключить SDK и цель на 10.11. А нету SDK для 10.11! Xcode может работать на 10.11, но собрать может только для 10.12.

Весь Xcode прежней версии качать неохота было, качнул только утилиты командной строки. Поставил. Поставились. Теперь компилятор для 10.11 есть. А SDK нету. Так уж и быть, качнул Xcode 7.3.1. Поставил. Теперь есть и компилятор, и SDK для 10.11. Но только для них (не считая забекапленной 10.12, конечно). Странно, а вроде раньше по-другому было. В те дни, когда я думал, что 10.6.8 — потолок, я поставил Xcode 3, и там были 10.4u, 10.5, 10.6, то есть, начиная от самой первой x86’ой до самой последней поддерживаемой. А тут одна.

Вычитал такое:
I can copy MacOSX10.11.sdk from another host, but presumably Apple has something else in mind here.
Just to be clear, Apple policy since Xcode 7 has been to only distribute the newest SDK with Xcode.app.

Так, теперь понятно, как Эппл пасёт чебурашек. Ставим разработчиков в дурацкое положение, когда они не могут просто взять и собрать для минимальной достаточной версии OS, как это делается на Windows, со слабым связыванием опциональных фич. Если не предпринимать специальных действий, если не писать на Delphi, C++ Builder или GNAT Ada, а именно из Xcode, то получаются приложения с неоправданно завышенными системными требованиями. Пользователи вынужденно обновляют ОС и/или железо, Эппл собирает кассу, разработчикам с этого пирога ничего не перепадает.

Однако нашёл ещё такое и такое. То есть, несмотря на ужимки Эппл, возможность собирать как лучше для людей имеется.

И это отличный источник входных файлов для BridgeSupport и анализатора, которым я также собираюсь прочесать GNUStep (до и после отравления TGC) и Cocotron на предмет пересечения. Где что появилось, где устарело, где изчезло. Пока что это мутная толща воды, и в неё надо забуриться.

Сайты, которые нужно знать китайскому поклоннику открытых исходников:
opencas.org
oss.org.cn

code.csdn.net
coding.net
git.oschina.net

Но при этом какой-нибудь tangram.baidu.com вполне может вести на банальный GitHub.

Думал, куда бы свалить с пидорского BitBucket. На международных CodePlex, BitBucket, Google Code, Assembla, SourceForge какой ни возьми, варианты SCM разные, и Mercurial тоже был. На трёх указанных китайских — нет. Беда. Глянул в китайскую вики, там тоже не видать своих сервисов.

Как же не люблю, когда всё пропадает из Интернета. Ну было же великое событие, появление BridgeSupport, до которого описание было только в заголовочных файлах Objective-C и не было аналога COM TLB, SOM.IR и т.п. Для Qt что-то такое уже было, для Gtk+ было, и только Cocoa была последней крепостью. И эта крепость пала. Всё это было в Mac OS X 10.5 Leopard, а у меня был Mac OS X 10.4 Tiger, но я следил за этими событиями, в частности, ставил MacPorts, и через него всё замечательно ставилось и на Тигре тоже. Недальновидные разработчики не могли придумать ничего лучше моста в Python и Ruby. Чуть более дальновидные на его основе сделали взамен устаревшего встроенного моста Cocoa-Java новый RoCocoa. И совсем то, что доктор прописал, было в первую очередь поступить с этой метаинформацией как в COM TLB, то есть, конечно же, привязки для Delphi и Ada, а уж потом всякие скрипты-шкрипты.

Пока не установил МакОС, из которого выпилили эмуляцию PowerPC, я даже не подозревал, сколько у меня таких программ. Причём, каких! Игры!

Ricochet Lost Worlds, Marble Blast Gold, Luxor 2, Luxor Mahjong, Monster Fair Pinball, Nanosaur — всё это оказалось PowerPC. Кто говорил про обязательные нативные порты, теперь посрамлён. Можно пользоваться программами в эмуляции и даже не знать об этом, пока эмуляцию не отключат. А если не отключать, так и вообще хорошо.

Запарился мигрировать всё с Хакинтоша, на котором Ассистент миграции вообще не может в сеть (Mac OS X 10.4.10 Tiger). В принципе, там был порт FireWire, но какой с него толк для миграции, если на Хакинтоше нет Open Firmware и Эпловской разновидности EFI, в которую нужно загрузить донора. Короче, полный голяк. Некоторое время полюбовался на Mac OS X 10.6.8 Snow Leopard на купленном устройства. Там всё ещё узнаваемый стиль Аква и шрифт Lucida Grande. Антиалиасинг без хинтинга и мыла. Всё такое приятное, круглое, пластмассовое.

Сделать образ диска, с которого запущена операционка — это оказалась творческая задача. В Хакинтоше у меня два диска, и можно бекапить первый на второй. Очень мудро я в своё время поступил, разбив основной ЖД на кучу мелких разделов, хоть как-то себе жизнь облегчил. Ещё бы привод DVD никуда не делся, я б прямо с Хакинтошного DVD загрузился бы и Дисковой Утилитой сделал образ как надо. Но привода нет. А hdiutil в Single Mode не заработал. Пришлось dd'шечкой делать. На 10.6.8 образ в таком формате сходу не подключился (нет таблицы разделов), но его оказалось возможным сконвертировать, и этот сконвертированный уже работал лучше. Его подмонтировал, запустил Ассистент Миграции, выбрал вариант «с другого раздела», и этот виртуальный образ был в списке кандидатов.

Этот макОС — какой-то новый Турбо Паскаль
Exception Type:        EXC_ARITHMETIC (SIGFPE)
Exception Codes:       EXC_I386_DIV (divide by zero)
Exception Note:        EXC_CORPSE_NOTIFY

SOLVED: My MacBook Pro didn't have a battery installed. I had to remove it b/c it got bloated one day. I installed a new battery and the upgrade didn't crash. Upgraded successfully to El Capitan.
Кто ж мог знать, что без батареи установщик превратит макбук в макбрик. Ни туда и ни сюда теперь.

Обнаружил в последнем обновлении приложение Paint 3D. Понабросал объектов, надоело, нажал закрыть и… он закрылся! Не спросив, а не хочу ли я сохранить свою мазню. Ну вдруг она мне очень дорога, а я погорячился. Впрочем, с учётом прошлого опыта что-то такое было ожидаемо. В приложении ВКонтакте долго писал пост, решил развернуть на весь экран, развернул, при этом панель написания поста уехала, а когда я её открыл заново, моего текста там уже не было. Охренел и с тех пор не запускал. Приложение Скайп пробовал, но однажды пропустил несколько важных сообщений, и Скайп никак о них не сообщил, хотя висел открытый в панели задач. Охренел и с тех пор не запускал.

В этом — весь UWP. Похоже, кроме как через Project Centennial, принципиально невозможно написать нормальное приложение для Магазина. Впрочем, с приложениями, которые были разработаны средствами PC, я большого опыта ещё не имел. Нельзя исключать, что и там талантливые инженеры придумали, как безнадёжно всё сломать.

Увидел среди новых TLD .ads, пока без возможности регистрации. Наверное, хорошо подходит для адских библиотек, там по широко принятому соглашению .ads = ADa Specification, человеческий аналог заголовочных файлов.

Не получается у заказчика через cPanel добавить запись NS, там есть только A, AAAA, CNAME, SRV и TXT, и через WHM тоже не сработало. У меня и в Windows 2003 получилось, и в Яндекс.ПДД порядок, только домены-то при этом мои, а надо, чтоб заказчика. Который день это уже длится. Пытаюсь сагитировать его взять ещё домен второго уровня, уж там-то NS поставятся как надо. $3 в год за .science, $30 сразу за 10 лет — вот столько стоит твоё потерянное время, говорю. Не сдаётся :)

putting.om.Environment.solveMetaclassConstraints
Нашёл ту функцию, которая подбирает нужный метакласс или конструирует новый, если ни один из запрошенных не подходит. На всё про всё 40 строк кода. Вот, насколько упростил Гвидо ван Россум свой Питон, отказавшись это сделать, и сломав метаклассы по сравнению с моделью из книги, которой он вдохновлялся.

The metaclasses book describes a mechanism whereby a suitable metaclass is automatically created, when necessary, through multiple inheritance from M1 and M2. In Python 2.2, I have chosen a simpler approach which raises an exception if the metaclass constraint is not satisfied; it is up to the programmer to provide a suitable metaclass through the __metaclass__ class variable. However, if one of the base metaclasses satisfies the constraint (including the explicitly given __metaclass__, if any), the first base metaclass found satisfying the constraint will be used as the metaclass.

XIII Международная научно-практическая конференция «Объектные системы — 2016 (Зимняя сессия)»

Таки опубликовали сборник. Без моей статьи. А за полгода, прошедшие с декабря, как-то сообщить мне нельзя было, чтоб я на другую конференцию успел подать? Может, ещё бы очно пообщался, если поближе к Барнаулу найти вариант. И на письмо так и не ответили. С кем я связался.