В январе 2013 года Roger Brown опубликовал под LGPL свои разработки по клонированию закрытой библиотеки IBM SOMobjects.

О том, что такое SOM, можно прочитать на русском в моей статье. Некоторое, возможно, не во всём объективное сравнение с другими объектными системами (COM, XPCOM, UNO, GObject, WinRT) можно найти в моём обзоре.

SOM главным образом ассоциируется с OS/2, где это была основная объектная система, и OpenDoc, почившим в бозе конкурентом OLE. Однако SOM — это нечто более значительное, чем просто объектная система OS/2, и спустя много лет периодически выходят журналистские статьи и петиции с просьбами к IBM опубликовать исходные коды если не всей OS/2, то хотя бы SOM.

Лучшее из OS/2 на платформе Linux

Будет ли результат похож на OS/2? Ни в коем случае! Но зато разработчики Linux получат отличную объектно-ориентированную инфраструктуру, способную сделать настольный вариант этой ОС гораздо более привлекательным для независимых поставщиков ПО. В результате должна появиться масса новых приложений, которые, в свою очередь, стимулируют интерес пользователей настольных систем к Linux.

Теперь эта мечта стала ближе.

( читать дальше... )

>>> somFree на SourceForge

Вышел релиз GNAT GPL 2009 — сборка компилятора GCC от AdaCore.

Новшества:

Добавлена поддержка автоматического импорта определений из C и C++ заголовочных файлов. Теперь не надо дожидаться, пока кто–нибудь сделает привязки. (link link)

Стандартная утилита сборки пакетов gprbuild облегчает задачу сборки смешанных проектов (Ada&C++). Это упрощает внедрение Ады в проекты, уже начатые на C или C++. (link)

Появился порт для JVM, а также набор утилит AJIS, с помощью которых можно на высоком уровне из Java кода вызывать нативный Ada код и наоборот. (link)

Почти одновременно вышел SPARK GPL 2009. SPARK — это набор утилит, проверяющих утверждения касательно кода программы. С точки зрения компилятора, все утверждения находятся в специального вида комментариях, поэтому после успешной верификации исходники компилируются обычным компилятором Ады. Это первый раз, когда SPARK сделан доступным публично. (link)

После долгого перерыва снова есть порт на Mac OS X (x86_64). Предыдущий порт на Mac OS X был в 2006м году для PowerPC.

Полный список платформ в релизе, таким образом:

• dotnet-windows
• jvm-windows
• x86-windows
• x86-linux
• x86_64-linux
• x86_64-darwin

>>> Подробности

Вот ищу вот сабж. Хотелось бы иметь много инфы в одном месте. Что порекоммендуете?

Проще всего работать с пакетами GNU Autotools
./configure --prefix=/opt/nonexistent блаблабла && make && DESTDIR="..." make install

Автотулз у меня на ура пошли. трабли были разве что с пакетом jpegsrc. Он давно не обновлялся, года так с 96го. И автотулз там тоже не новые были использованы. DESTDIR не понимается, make install не делится на make install-data и make install-exec, а ведь мне выгоднее сначала задестдирить экзеки от разных архитектур, чтобы склеить в универсальный бинарник, а уже потом добавить данные от одной архитектуры. Данные ведь всё равно склеивать не надо. Ладно, лишние подробности.

Особенно не понравились пакеты на языках perl и python. У них отсутствует ./configure и этапы make как таковые. Вместо этого там исполняемые файлы setup.py и makefile.pl. Неприятность работать с ними заключается в том, что там всё по–своему. Те пакеты, которые меня интересуют, содержат "вкрапления" на C, и мне не нравится, что, если я чего-то упустил, то система сборки начинает своевольничать. Чтобы этого не было, я сначала собираю ppc архитектуру (а у меня intel). Если система сборки вдруг решает, что она умнее, чем я, то она во многих случаях обссыкается, и я вижу, где это произошло. Если компилеру или линкеру не передать -arch ppc, то они пытаются собрать в родной i386 архитектуре, при этом зависимости собраны по-прежнему в ppc. Если я собираю pygtk, то во время компиляции я настраиваю среду окружения на ppc версию gtk+, а не на универсальную, хотя она уже к этому моменту готова. У меня складывается впечатление, что в сами python и perl вшиты какие-то ключи компиляции, которые, если недосмотреть, могут заменять те, которые хочу использовать я.

В общем, охота, чтоб в одном месте было много инфы о том, как производить сборку разнотипных пакетов. Меня интересует создание unattended инсталляций. И как настраивать среду окружения при этом. Что делать, если нужно использовать python, который стоит в системе и что делать, если нужно использовать тот, который идёт в слепке. Сами по себе слепки не является перемещаемыми, просто ни одна программа из слепка не вызывается снаружи напрямую. Снаружи вызывается обёртка, которая настраивает среду так, что все программы внутри могут нормально работать. На Mac OS X это стандартный способ портировать программы, сделанные на autotools и пр. Вообще, я видел подобные "слепки" и под linux, вспомнить хотя бы GNAT GPL. gps настраивает среду и вызывает gps_exe.

Собственно задача -- прокачать скиллы мейнтейнера, а создание слепков -- это приятное с полезным.

>>>

Переполнения буффера были и остаются частью нашей жизни. Уж сколько раз твердили миру, а мир всё пишет на C/C++.

Так вот, мне интересны техники исключения небезопасностей C++. А именно, переполнения буффера и висячие указатели, хотя бы эти источники ошибок. Меня интересуют компиляторы, виртуальные машины C++ и т. д., в которых выполнить подобную операцию было бы невозможно. В идеале -- пересобрать какой-нибудь популярный дистр этим компилятором. Но это вряд ли, как-то нереально звучит, поэтому топик в Talks. Это было бы полезно не только для безопасности юзера, но и для улучшения кода. Ошибки, которые могут быть не видны при исполнении в обычном режиме, не проскочат в режиме защищённом. Соответственно, можно слать баг-репорты куда надо. Это лучше, чем просто надеяться на авось^Wмиллион пытливых глаз.

Конечно, это падение производительности и другие затраты. Скажем, трёхкратное падение производительности на Core 2 Duo можно позволить. Просто очень хочется.