LINUX.ORG.RU

somFree: открытый кроссплатформенный клон IBM SOM

 corba, , , ,


1

3

В январе 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.

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

Объектная система, такая как SOM, может быть привлекательна для разработчиков на малопопулярных или новых языках. В отсутствие подобной системы разработчики на разных языках делают привязки независимо друг от друга, и работа одних не помогает другим. Кроме того, уровень C ABI, на котором обычно определено взаимодействие, оставляет множество неопределённостей, которые делают сложной автоматическую генерацию. Например, по опыту автора с libyaml, даже в таких пустяках, как преобразование из string в const char *, могут быть фатальные особенности: в одних местах недопустим указатель на \0, в других местах недопустим NULL. Отсутствие общего стандарта приводит к тому, что интересные идеи приходится портить, нацеливая компиляторы на платформу, где такой общий стандарт есть: JVM или Mono.

В случае с SOM одни люди могли бы разрабатывать emitters для компилируемых языков программирования (как в FPC/2), либо обёртки somDispatch() для скриптовых языков (как в Object REXX), а другие люди могли бы вместо привязок только для своего языка делать фасады для SOM, которыми могли бы пользоваться все остальные.

Если SOM наберёт популярность, можно будет ожидать свои аналоги Objective-C, C++/CX, Cyclone или Vala для SOM. У IBM такой эксперимент (Direct2SOM) остался на стадии беты, когда работы над библиотекой были прекращены.

>>> somFree на SourceForge



Проверено: tazhate ()
Последнее исправление: Dendy (всего исправлений: 2)

Ответ на: комментарий от crazy_alex

Если же у меня dlopen - я вообще не должен заходить в те ветки, где естьобращения ксоответствующим функциям библиотеки

а в случае dbus ты этого делать не должен? То есть то, что программа будет вхолостую гонять такты - это нормально?

alex_custov ★★★★★
()
Ответ на: комментарий от crazy_alex

То есть мегабайтов таки жалко - тех, которые в памяти.

Я сильно сомневаюсь, что поддержка языков с письмом справа налево займёт больше 100 Kb в секции .code

alex_custov ★★★★★
()
Ответ на: комментарий от alex_custov

В дебиане это чудо зависимостями в результате тянуло список из сорока с лишним пакетов. Ладно, здесь это суровый оффтопик.

crazy_alex
()
Ответ на: комментарий от crazy_alex

Вы лучше покажите мне конкретный deb-пакет и его зависимости. О нем и поговорим, а так я вас плохо понимаю.

BigAlex ★★★
()
Ответ на: комментарий от anonymous

концепция «всё - это файл» продемонстрировала свою недостаточность, как только появились юниксовый ioctl или «control messages to control files» в plan9, поскольку это ни что иное, как суррогат вызова методов.

fidoman
()
Ответ на: комментарий от crazy_alex

В случае, когда я готов использовать D-Bus - это более чем нормально.

Странный ты гентушник, сетуешь на письмо справа налево, а сам готов писать откровенный говнокод.

alex_custov ★★★★★
()
Ответ на: комментарий от Puzan

Полуоська - ностальгия...

Сколько я помню, в те времена весьма «хилых» по нынешним временам компов Windows 3.1 позиционировалась как «однозадачная однопользовательская система», WindowsNT - «серверная», UNIX - «многозадачная многопользовательская», а OS/2 - «многозадачная однопользовательская». Поддержка DOS в OS/2 была ШИКАРНАЯ - ни с какой Windows (ни Win 3.1, ни WinNT) не сравнимая! GUI был лучше, чем в Win 3.1 и WinNT. Жрала ресурсов в несколько раз меньше, чем WinNT.

Я её долго пользовал на домашнем компе и сменил только на Win98 - главным образом из-за новых игр. REXX в качестве скриптового языка до сих пор перекрывает все «виндовозные поделки». Насколько я знаю IBM не может открыть исходники из-за возможных патентных претензий от MS. Ностальгия.

До сих пор имею образ для qemu и периодически играю в одну из своих любимых игр - MINE3D. Под виндой аналогичной не обнаружил.

anonymous
()
Ответ на: Полуоська - ностальгия... от anonymous

Хотелось бы отметить, что при нынешнем распостранении «персональных» устройств «многозадачная однопользовательская» операционная система могла бы быть привлекательной при условии потребления меньших ресурсов, чем «многозадачная многопользовательская»(Linux). Кажется, эта «ниша» ещё не занята?

anonymous
()
Ответ на: комментарий от alex_custov

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

crazy_alex
()

Открою секрет, ни COM ни SOM вообще не нужны в мире СОВРЕМЕННОГО (!) ПО

anonymous
()
Ответ на: комментарий от anonymous

Открою секрет, ни COM ни SOM вообще не нужны в мире СОВРЕМЕННОГО (!) ПО

обоснуй, а как связывать программы и библиотеки и прочие вещи на разных языках и платформах и ОС? что-то типа ZeroMQ? да, вот реализуют уровень связи через shared memory и вообще летать будет на максимуме

но как быть с тем чтобы какую-то библиотеку на питоне использовать в Java? вот для того и надо SOM

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от lucentcode

Рано или поздно всё будет объектом, и в 21 веке альтернативы этому нет.

Фанат ооп детектед.

По сабжу — не взлетит, только если кто-то не поддержит типа рэдхэта, да и то если взлетит то будет это не скоро. Сейчас так много программ поддерживают dbus, например, но мне прекрасно живется и без этих фич.

e7z0x1 ★★★★★
()
Ответ на: комментарий от e7z0x1

Красношляпа поддержит. Они как раз корпоративным интересом руководствуются, а не размышлениями на тему just for fun.

lucentcode ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

да, вот реализуют уровень связи через shared memory и вообще летать будет на максимуме ... но как быть с тем чтобы какую-то библиотеку на питоне использовать в Java? вот для того и надо SOM

А как поможет SOM для связи на уровне shared memory между python и java? именно python, а не jython?

ИМХО никак ;)

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

обоснуй, а как связывать программы и библиотеки и прочие вещи на разных языках и платформах и ОС? что-то типа ZeroMQ? да, вот реализуют уровень связи через shared memory и вообще летать будет на максимуме

А надо ли связывать именно программы и языки? MQ позволяет сделать ESB, когда вообще заранее не известно КТО и КОГДА будет обрабатывать пакет данных. В начале одна система выкладывает, другая получает (Источник->Приемник). Дальше может понадобиться сделать цепочку обработчиков и MQ легко это реализует НЕ МЕНЯЯ УЖЕ РАБОТАЮЩИЕ ПРИЛОЖЕНИЯ (Источник -> Промежуточное звено 1 -> Промежуточное звено 2 -> Приемник).

Хотя если вы считаете это нужным - желаю успеха! ;))) Сила OpenSource не в догматах, а в разнообразии =)))

VoDA ★★
()
Ответ на: комментарий от VoDA

Хотя если вы считаете это нужным - желаю успеха! ;))) Сила OpenSource не в догматах, а в разнообразии =)))

я бы лично не отказался от SOM

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

Хотя если вы считаете это нужным - желаю успеха! ;))) Сила OpenSource не в догматах, а в разнообразии =)))

я бы лично не отказался от SOM

есть много вещей и не вещей от которых не стоит оказываться ;)))

вопрос насколько полезен SOM в текущей реальности остается открытым. Даже тот же COM/DCOM/кто там дальше нужен в очень редких случаях.

VoDA ★★
()
Ответ на: комментарий от sv75

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

lucentcode ★★★★★
()

интересно. а насколько реально изобразить SOM поверх GObject? для vala ?

или, это получается параллельная GObject вещь?

вообще, раньше в vala были профили (posix, dova) — насколько сложно сделать свой профиль с SOM, COM, в добавок к GObject?

anonymous
()
Ответ на: комментарий от anonymous

Печально, что OS/2 не прижилась (скажем так).

да, печально. вот eCS пытаются реанимировать, делают магазин приложений, объявляют баунти за приложения. но как-то некузяво: даже если и будет много приложений, что делать со старым ядром?

кабы исходники выложили, был бы рулез --- но по копирастическим причинам из-за всяких third parties этого никогда не будет.

в любом случае, то же eCS имеет проблемы: поддержка многопользовательности и 64-битности. даже если они допатчат ядро своими фикспаками, то от этих проблем никуда не деться.

хотя лучше бы пилили osFree на базе L4, да :))

anonymous
()
Ответ на: комментарий от glebiao

GObject - могильщик CORBA в Linux

да ну, уж прямо могильщик

самозакапывающийся зомби-могильщик. аааа!!!

anonymous
()
Ответ на: комментарий от I-Love-Microsoft

вот тут: ftp://ftp.software.ibm.com/publications/clubod/som30/index.html

почему бы автору не выложить это в PDF? с нормальным индексом? почему бы примеры не сделать?

+1. берёш питоновый Sphinx, переписываешь доку в rst разметке, разливаешь в pdf через тех или в html на сайт. получается годная книжечка.

anonymous
()
Ответ на: комментарий от lucentcode

В остальных случаях - только бинарный протокол на основе ООП.

1) powershell уже есть.

2) Хотя xml сожрет в 1000% больше времени, но это будет проще, чем мучить программистов. Их время дороже, чем оверхед на парсинг.

sv75 ★★★★★
()
Ответ на: комментарий от lucentcode

В остальных случаях - только бинарный протокол на основе ООП.

метаобъектного протокола на вас нет.

anonymous
()
Ответ на: комментарий от lucentcode

3) Для запускалки явы и оракла в лице redhat EL это всё совершенно пофигу.

sv75 ★★★★★
()
Ответ на: комментарий от tailgunner

Написал развернутый ответ, потом махнул рукой.

а я бы это прочел

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от crazy_alex

В дебиане это чудо зависимостями в результате тянуло список из сорока с лишним пакетов.

пожалуста название чуда и версию дебина (а можно сразу просто выхлоп apt-cache show имя_чуда)

www_linux_org_ru ★★★★★
()

Поздно. GObject introspection уже есть.

baverman ★★★
()
Ответ на: комментарий от alex_custov

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

irrelevant. OpenOffice и KD когда-то измерялись на предмет причины долгого запуска. Причина в том, что линкер ELF библиотек долго грузит и настраивает, а библиотек, которые надо подгрузить — много.

если вместо этого сделать несколько компонент с простым загрузчиком, то «проблема с производительностью запуска» уйдёт.

например, вместо 10 библиотек — три компоненты

по нормальному, надо измерять время запуска в трёх случаях:

- динамические библиотеки, линкер ld.so

- статически компилированное в один бинарник (0 накладных расходов)

- динамические библиотеки, другой вид модулей и другой загрузчик с более простым линкером

anonymous
()
Ответ на: комментарий от Nihilist

В SOM всё начинается с создания классов. Классы ядра SOM создаются вызовом somEnvironmentNew.

любопытное описание, спасибо (и за доку в заголовке топика).

Вообще было бы интересно сопоставить с GObject / COM.

Чтобы выделить какое-то общее подмножество, и сделать новый рантайм к Vala, к примеру. Вот CLR = Common Language Runtime, а нужен какой-то Common System Object Models Runtime :)) comsysrt :)

anonymous
()
Ответ на: комментарий от Nihilist

Когда я получил дистрибутив SOM 3.0 для WinNT, план был сначала завести это дело на VisualAge, потом перевести на рельсы Borland C++ 5.5 free

а под OpenWatcom собирается? OpenWatcom «из коробки» поддерживает OS/2, WinNT, Linux. 32-битный, есть не очень сильно документированная обёртка owcc с gcc-подобными ключами командной строки (не все ключи gcc поддерживаются).

anonymous
()
Ответ на: комментарий от GluckMan

Во-первых, ос/2 не закопали, она до сих пор применяется, а начали ее применять аж в конце 80-ых - больше десятилетия активной жизни, и это в худшем случае, поскольку и сейчас еще жива в той или иной степени и даже выпускается в виде новых дистров, но с другим названием ;) И под нее пилят софт

её сейчас даже продают: eCS, след. версия OS/2 и какой-то софт

там периодически всплывают вот задания для разработчиков

разработчиков пытаются заманивать баунти наградами.

имхо, для студентов вполне вариант — купить новую полуось, запрограммировать нужные задания, получить за это денюжку

Под полуось был апач

там же EMX был, а сейчас gcc 4.6.3 есть, и довольно много POSIX софта собирается

в интернетах много GNU софта для полуоси, а eCS-овцы продают свой «дистр» на диске.

anonymous
()
Ответ на: комментарий от GluckMan

До этого самого удобства линюксу ой как далеко, далеко также, как винде до заточки под себя :) ИБМ похоронили будущее.

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

Но там немаловажную роль сыграла МС, которой принадлежали часть прав на полуось. МС платило ИБМ за использование НТ, может, и сейчас платит

за винду или выкупило, а ИБМ платило МС, в итоге пострадали пользователи.

думаю, сорцы полуоси невозможно открыть именно по этой причине. Там ещё другие third parties могут быть. Обсуждалось открытие сорцов одним из разработчиков, по юридическим причинам зарубили — есть код, копирайт на которого не у IBM

OpenWatcom и сейчас жив и здоров. Работает под Linux, WinNT, OS/2, dos, qnx, кросскомпилятор из коробки. Только 32 бита, стандарт 98 года, свой ламповый IOStreams, OWSTL тоже неполный STL. Хотя они поменяли мейнтейнера, может он с новыми силами начнёт активничать.

кстати, линукс сообщество трололо: этот мейнтейнер пытался собрать GTK3/ GTK2 openwatcom-ом, GTK-шное сообчество его чуть ли не послало. он обиделсо, и советует всем пользователям openwatcom посылать GTK нах.

anonymous
()
Ответ на: комментарий от AVL2

Я иногда встречаю программы на vala в самых неожиданных местах

я вот недавно на GTK3 под винду пописал на Vala. Скачал бинарную сборку с IDE, mingw. Вполне себе работает. ValaIDE правда горбуха, там приходится ключик в реестре править, чтобы в IDE сорцы открывались ;-)))

anonymous
()
Ответ на: комментарий от anonymous

ЗЫ: хотя бы удосужились вики почитать про OS/2, а потом орать про винНТ, как она божественна.

блджад, да скачайте LiveCD с хотя бы старым eCS (который бесплатно), поставьте в виртуалку, потыкайте веточкой. это надо не читать, это надо самому щупать.

anonymous
()
Ответ на: комментарий от lucentcode

Логи, информация от различных процессах и многое другое может передаваться в форме объектов. Это упростит связывание различного ПО в одну связку.

посмотри API BeOS (Haiku) : BMessage и скриптование GUI через команду hey ( google://Scott+Hacker+BeOS+scripting )

anonymous
()
Ответ на: комментарий от anonymous

Currently only VisualAge C++ 4.0 for Win32 is supported

попробуй собери хотя бы OpenWatcom-ом. в идеале, цель — gcc, конечно.

anonymous
()
Ответ на: комментарий от anonymous

was maden by

тот случай, когда не поймешь - то ли толсто, то ли тонко.

anonymous
()
Ответ на: комментарий от anonymous

если вместо этого сделать несколько компонент с простым загрузчиком, то «проблема с производительностью запуска» уйдёт.

можно же сделать постадийно: сам SOM(free) грузится через ELF библиотеки и ld.so, а уже SOM подгружает простые бинарные модули объектов типа как в BlackBox Component Pascal сделаны модули, или модули LLVM биткода.

второй — лоадер без «тяжёлого» линкера, упрощённый.

anonymous
()
Ответ на: комментарий от alex_custov

Если программа при этом будет взлетать быстрее хотя бы на 1% - я за! Но если будет иметь типичные проблемы с производительностью запуска и даже работы для таких систем, то лично моё мнение - не нужно.

проблем со скоростью запуска нет, и вот почему :

First, you must list the mangled name of the function. To figure out the mangled name of the function you want to export, you need to run the utility CPPFILT that comes with the C Set++ compiler. This will extract all the names from your object files. You then copy the ones you want to export into your .DEF file. Needless to say, this can be an error-prone endeavor. Second, the number of export entries for a class may be huge, if the class contains a large number of member functions. Even private or protected member functions will need to be exported if they are used by an exported function. By contrast, SOM requires no more than three export entries per class, and each export entry follows a naming convention. In the following, we will show you step-by-step how to build a DLL for SOM classes.

anonymous
()
Ответ на: комментарий от anonymous

как это работает, на низком уровне.

C++ : для каждого экспортируемого класса нужно экспортировать все методы (приватные, защищённые, публичные) класса и всех классов, что ниже его по иерархии. методы манглируются, получаем «как бы» Си функции, которые умеет слинковать Си линкер. методов много, да ещё и библиотек классов много. ELF загрузчик библиотек (ld.so) требует много возни при загрузке. в итоге имеем: долгую загрузку при инициализации, showcase: KDE, OpenOffice.

SOM: нужно экспортировать 3 функции: конструктор класса, конструктор метакласса, и конструктор ClassObject. методы вызываются не через VMT (VTable), как в C++, а через ClassDataObject. бинарная совместимость не ломается, т.к. в releaseorder указываются поля в виде, не ломающем совместимость. методы вызываются через указатель в ClassDataObject, который заполняется при инициализации инстанса объекта

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.