В юниксе стандартизированы очень низкоуровневые по нынешним временам интерфейсы. Ну файл... И что? Как из него выбрать нужные элементы? Очередной grep/awk? Что-то мне ими .odt обрабатывать не очень хочется чтобы, скажем, таблицу сделать полосатой. Не говоря о том, что стандартные юниксовые средства не включают GUI - и врезультате, скажем, стандарта скриптования GUI нет. А вот полуоси он был.

Чем оно лучше GObject?

Может, и GObject не нужен? В OpenSource мире не было многих вещей в силу того, что пилил народ то, что ему было интересно. Так было в эпоху базарной модели разработки, но на смену ей идёт возврат к соборной модели. Вы посмотрите, как за прошедшие 10 лет изменился Linux, и связанные с ним технологии... А почему? Потому, что данная ОС стала востребованной у очень серьёзных компаний. Которые стали разрабатывать и проталкивать в ОС, и смежные проекты то, что нужно миру бизнеса. Если SOM окажется круче GObject, и серьёзные дяди из RedHat или Google его поддержат, SOM будет буквально везде уже через пару лет. Как сейчас везде пролазит GObject, D-Bus и systemd. Бизнес отлично понимает, что стандартизация позволит сократить расходы. Меньшими усилиями, и с меньшими затратами, можно будет решать больше задач. Стандартизация не избежна. Отход от философии UNIX, где всё есть файл - тоже. Рано или поздно всё будет объектом, и в 21 веке альтернативы этому нет. А для любителей текста будут программы, которые будут прослойкой между объектной моделью, и старым ПО, основанном на текстах, файлах и потоках.

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

Да, согласен. Ловите: http://octagram.name/pub/somobjects/

Здесь особый интерес представляют SOMobjects Developer Toolkit Version 3.0 Programming Guide A4 Volume 1; SOM and DSOM и отчасти SOMobjects for Mac OS. Одной из целей автора было добавить DSOM к SOMobjects for Mac OS, так что устройство яблочной версии повлияло.

теория без практики - бесплодна, сделай ты хоть super-mega-ultra-SOM, но если этим нельзя просто воспользоваться - то не взлетит...

Примерно в таких настроениях я пребывал, когда решил во что бы то ни стало отыскать хотя бы Windows версию. OS/2 в виртуалке мало, кто поставит, компиляторов негусто, к своим разработкам не прикрутишь, а вот Windows версия — совсем другое дело. То, что я раскопал, превзошло мои ожидания, поэтому я сам ещё не успеваю всё изучить, публикую как есть.

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

Спасибо! Знай - эта технология ультра-актуальна для Linux и вообще других ОС, крайне важно и например я чертовски заинтересован в создании простых примеров чтобы это полетело.

Как с тобой можно связаться? Jabber?

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

Не понимаю =( Может кто нибудь на пальцах объяснить, зачем это нужно и как применяется. Из статей ничего не понял...

вот я программист, хочу сегодня же связать программу на допустим free pascal (не люблю паскаль, но допустим) и программу на C++/Qt - где практические руководства по сборке, настройке, подключению и программированию с помощью этой штуки?

Не так быстро. Кто–то, кто готов потратить ради Free Pascal своё время, делает Emitter. В somFree сейчас нет Emitter Framework, но, скорее всего, появится, а тем временем можно экспериментировать с Emitter Framework, используя SOM compiler из оригинального IBM SOM for WinNT (например, на Wine).

Далее, кто–то другой, кто готов потратить время на SDL или wxWidgets, ну или Qt, если сможет проглотить, изучает, как делать SOM фасады. По ссылке Object REXX как раз это и описывалось: чтобы подключить плюсовую библиотеку из REXX, для неё делается SOM–обёртка, а на OS/2 между SOM и REXX интеграция, как между COM и JScript в Windows.

Если библиотека небольшая, то руками делается, и начинать, наверное, следует с таких малых целей. Либо можно только ограниченный функционал выставлять в сторону SOM. Например, только QtSql. Вручную.

Для тех, кто крутой инженер, можно посоветовать автоматическую генерацию фасадов. Инструменты при этом могут пригодиться всё те же, что и для генерации привязок. Вот, например, SWIG можно было бы модифицировать, чтоб он для SOM научился генерить .idl'ки и реализацию прокси–объектов. Во многих проектах можно обнаружить хедеры с инструкциями для SWIG, в том числе wxWidgets. Для Qt можно попытаться воспользоваться опытом привязок к какому–нибудь языку. Например, QtAda. Не разбирался с Qt, но для Ada там автоматически привязки сделаны.

аффтар молодец, большую работу сделал - а теперь пора применять - КАК?

Если отбросить такой хардкор, как другие языки и автоматически сгенеренные фасады для других библиотек, то документация–то есть. Многие вещи как ни в чём ни бывало гуглятся, потому что всё это было в OS/2.

Вот же некроманты. Может, лет 10 назад это и могло взлететь, но сейчас CORBA в Linux окончательно похоронена в пользу GObject.

Это может взлететь до тех пор, пока что–то не похоронило C ABI. А C ABI живее всех живых. libyaml берём — там API (и ABI) для C, а не GObject или XPCOM.

В OpenSource мире смысла в компонентах и поделиях навроде ole/com/xpcom/.. нет.

И, тем не менее, они почему–то хорошо процветают.

Лично для меня ещё как есть. Меня просто тошнит от того, чем считает нормальным быть open source. Отношение к компилируемым программам как к скриптам. C++ вместо объектной модели с привязкой к компилятору. ./configure --with, ./configure --without, и прочая ересь. Когда я слышу «open source», я представляю себе что–то такое же, как закрытое, только лучше, а на деле такого правильного open source'а очень мало. В гробу я видел эти --with и --without. Не должно быть всяких там по–разному сконфигурированных версий одного и того же. Реальная возможность использовать библиотеку должна зависеть только от наличия её объектных файлов во время исполнения, но никак не во время компиляции. Проекты должны либо безальтернативно требовать наличие некоего SDK, либо тащить IDL'ки и хедеры своих зависимостей, не вошедшиx в этот SDK, с собой.

Индивидуально сконфигурированные версии должны быть вытеснены из мейнстрима в какой–нибудь embedded, где жёсткие требования по размеру и действительно уместен индивидуальный подход.

Это может взлететь до тех пор, пока что–то не похоронило C ABI

Ты предлагаешь слой поверх C ABI, подобный GObject. Новый слой может быть лучше задуман, но 1) сам по себе еще не существует 2) не поддерживается никакой библиотекой.

libyaml берём — там API (и ABI) для C, а не GObject или XPCOM.

И какой вывод? SOM там тоже нет.

Не должно быть всяких там по–разному сконфигурированных версий одного и того же

Почему?

Реальная возможность использовать библиотеку должна зависеть только от наличия её объектных файлов во время исполнения

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

На окраинах еще догнивала Новелл Нетваре.

Вы будете смеятся… шёл 2013 год, «не тварь» всё ещё использовалась, проектировались и строились новые большие сети.

obvious fix

[…] а настоящий тру ЮНИКС, где все - это файл

s/ЮНИКС/ПЛАН9/

Учите основы.

Чтоб php'шникам не искать php_zip.dll или php_zip.so, а просто zip.dll или zip.so, подходящая ко всем SOM–совместимым языкам программирования. Чтоб, используя C++ и DLL, не страдать от проблем типа fragile base class, из–за которых, кстати, от C++ отказываются вовсе в пользу C (у автора FQA Lite читал в блоге). А SOM, наоборот, целенаправленно стремится сохранять двоичную совместимость при максимальном количестве трансформаций. Допустимых трансформаций больше, чем у GObject и Objective-C. При этом люди, которые работали над IBM SOM, были довольно искушены в других языках программирования, знали CLOS, CommonLoops, SmallTalk и, не забывая про двоичную совместимость, формировали объектную систему так, чтобы она была сопоставимо гибкой. Двое разработчиков SOM написали книгу Putting Metaclasses to Work by Ira R. Forman, Scott Danforth, Addison-Wesley 1999, которая впоследствии оказала влияние на устройство метаклассов в Python.

То есть, SOM — это бинарная совместимость + продвинутая объектная модель.

Чтобы, используя труднопортируемые большие фреймворки, не быть привязанным к тому же компилятору, что и использовавшийся для фреймворка. Может быть, кому–то хочется Intel C++ compiler или Comeau поюзать. Но в Linux они будут второсортными жителями, если только не удастся собрать ими желаемые библиотеки.

SOM — это эволюция DLL

SOM — это эволюция DLL

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

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

Во–вторых, то, что критично, можно линковать как обычно. В SOM всё начинается с создания классов. Классы ядра SOM создаются вызовом somEnvironmentNew. Для создания остальных классов экспортируется и импортируются НазваниеКлассаNewClass. Реализацию этой функции обычно генерирует SOM Compiler на основании IDL. В IDL указаны родители и другие классы, которые могут понадобиться, например, метакласс. Все эти классы при необходимости создаются аналогичными вызовами NewClass, формируется специальная структура и вызывается somBuildClass. Когда класс создан, уже можно использовать методы собственно SOM. Создание объекта — это метод somNew класса, удаление и прочее — после создания класса всё можно делать только через методы.

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

>> libyaml берём — там API (и ABI) для C, а не GObject или XPCOM.

И какой вывод? SOM там тоже нет.

И было бы удивительно, если б он там был, учитывая, сколько лет нельзя было хотя бы Windows скачать хотя бы закрытый дистрибутив от IBM.

А вывод: место всё ещё вакантно

Во–первых, уже сейчас легко и непринуждённо возникает помойка собранных бинарников, которые неизвестно, что понимают

Почему же. Если автор проги не является адептом динамичности, то ldd всё показывает. Ну и для красоты используем dpkg -S и uniq.

Захочешь перейти на PostgreSQL, а выяснится, что не одно, так другое было собрано без PostgreSQL, потому что его в системе тогда не стояло, а без этого не судьба

Честно говоря, я никогда не имел таких проблем, т.к. мейнтенеры моего дистрибутива обычно не имеют проблем типа «потому что его в системе тогда не стояло», а все зависимоcти задают жёстко твоими любимыми --with :).

Как с тобой можно связаться? Jabber?

http://octagram.name/ (лучше email)

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

https://bitbucket.org/OCTAGRAM/somobjects

Когда я получил дистрибутив SOM 3.0 для WinNT, план был сначала завести это дело на VisualAge, потом перевести на рельсы Borland C++ 5.5 free, который уже поддерживался в IBM SOM, но, как выяснилось, это был Borland C++ for OS/2, а не Windows. Затем я бы мог опубликовать дистрибутив IBM SOM & Borland C++ 5.5 Free, такой, чтобы в нём сходу можно было пособирать примеры и написать свои программы. А уже потом двинуться к GCC и Microsoft.

На VisualAge запустить удалось (релиз 3.0.1), на Borland — по крайней мере, один пример собрался и заработал, для остальных надо правила make писать. В репозитории фиксов не делал, но в Issue #3 достаточно подсказок, чтобы воспроизвести. Где–то в этот момент меня настигла новость о somFree, и планы перестали быть актуальными, хотя и не целиком. Теперь надо оценивать somFree и переоценивать планы, но это не сразу, поэтому я решил сначала написать новость на линукс.орг.ру, а потом со всем разбираться.

А потом система тащит мне поддержку корейского языка и письма справа налево. Из-за чего я и ущел с дебиана на генту. Я, правда, пока не понял, может ли эту проблему решть SOM :-) В идеале, конечно, отсутствие библиотеки должно простолишать соответствующей функциональности, но пока я в этом плане решением вижу только D-Bus, который для нечастых вызовов будет вполне пригоден - производительность не просадит.

Из-за чего я и ущел с дебиана на генту. Я, правда, пока не понял, может ли эту проблему решть SOM :-)

Цитата:

Не должно быть всяких там по–разному сконфигурированных версий одного и того же

--

но пока я в этом плане решением вижу только D-Bus

это не решение данной задачи, т.к. dlopen() ты заменяешь на dbus_g_bus_get(), не имея вообще никаких выгод, а только теряя производительность.

вывод: место всё ещё вакантно

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

Если я тупо сделаю неуспешный dlopen и попытаюсь обратиться к тому, что оно (не) получило - я огребу сегфолт. Если я отправлю сообщение чему-то, чего в D-Bus нет - я получу ругань, но моя софтина останется жить, а ругань этту я должен уметь обрабатывать в любом случае по ряду причин. В общем, code path в случае D-Bus получается куда проще. Ну и возможность не знать, что конкртено ответит на мой запрос - тоже хороша, хотя можно что-то вроде alternatives использовать в случае dlopen. Опять же - там много дополнительных плюшек. Например, можно штатно оплучить список всего, что может быть запущено менеджером шины, можно реализовать централизованный «хаб», на к тором на лету править или логировать сообщения...

И, ко всему, мне идея двусторонней отправки сообщений кажется во многих случаях более оправданной, чем модель вызова метода объекта. D-Bus это даёт из коробки.

всё правильно сделал, новость написал - заинтересовал!!!

написал тебе в скайп, но если почта - на какую лучше?

Языки - это хорошо, однако разве на самом деле они используются где-то кроме gnome? Yorba со своим Shotwell'ом, например отказалась от оффтопика. А других живых проектов на Vala как-то и не вспомнить (Pino под Linux'ом тоже как-то скончался :-/ )

Если я тупо сделаю неуспешный dlopen и попытаюсь обратиться к тому, что оно (не) получило - я огребу сегфолт.

Если ты не проверяешь коды возврата, то программировать вообще не стоит.

В общем, code path в случае D-Bus получается куда проще

совсем не проще, т.к. в случае dlopen - это dlopen()+dlsym()+прямой вызов, в случае d-bus - это API намного сложнее, чем dlopen(), [де]сериализация данных, и расходы на IPC.

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

Всё это прекрасно для задач, которым это нужно, например HAL или udisks. Но для задач dlopen - это как ездить за хлебушком на болиде F1.

Там не в кодах возврата дело. Я могу валить миллион неуспешных сообщений на D-Bus, получатьошибку и отваливаться. code path при этом не меняется. Если же у меня dlopen - я вообще не должен заходить в те ветки, где естьобращения ксоответствующим функциям библиотеки. Ну и побочные неудобства - зависимость от ABI, а в случае D-Bus несложно сделать так, что даже API снизу вверх можно менять, вообще не затрагивая не знающего о новых версиях клиента. Я так понимаю, сабж это тоже умеет, надо покопать, чего от него ещё добиться можно.

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

Я всё это мыслю в основном в контексте построения более «управляемого» десктопа, где собственно GUI - это просто такой клиент (один из), использующий API ядра приложения - и так для любого приложения. И для этого мне важна рефлексия, существующая в D-Bus, вагон биндингов к нему на различных языках, стандартный интферфейс и невозможность сегфолта ни клиента, ни у сервера, что бы ни совали в шину.

но были законченные компиляторы (Zortech C++), полностью(!) реализовавшие direct-to-som.

поправка. Metawhare High C, конечно. Впрочем, всё одно --- наследник зортеха.

что-то у меня склероз начался :(

SOM (начиная с SOM 2.0 от IBM) - реализация CORBA

агащаблин

Об этом было сказано в документации SOM. Тебе есть что возразить?

Понятие подмножества от понятия точного равенства не отличаем?

А при том, что массовым сервером тогда была Windows NT. На окраинах еще догнивала Новелл Нетваре.
Но OS/2 не могла ни туда и не сюда, вот ее быстренько и

В только появившийся тогда AD, да, не могла. В домен в смысле «рабочей группы NT» — легко. Да и свой файловый сервер держал нагрузку очень и очень достойно.

В домен новелла --- легко, был официальный клиент.

Справедливости ради, в варкрафт на четырёх метрах можно было играть и под вин 3.1.

Но она таки зависит.

Зачем полуоси «интегрироваться» в какой-то там «домен», если она появилась на много лет раньше этого домена?

А при том, что массовым сервером тогда была Windows NT. На окраинах еще догнивала Новелл Нетваре. Но OS/2 не могла ни туда и не сюда, вот ее быстренько и закопали.

Во-первых, ос/2 не закопали, она до сих пор применяется, а начали ее применять аж в конце 80-ых - больше десятилетия активной жизни, и это в худшем случае, поскольку и сейчас еще жива в той или иной степени и даже выпускается в виде новых дистров, но с другим названием ;) И под нее пилят софт. Ваше «по-быстрому» звучит крайне глупо. Во-вторых, она прекрасно входила в домены как невари, так и винНТ, которая и была изготовлена на базе ос/2, кстати. Для новела был соотв. инструмент, а для винды было еще проще - поставить сетевые протоколы и указать домен. Криворукие, привыкшие к менюшкам винды, конечно, не в теме ;) В-третьих, только в убогих мелких конторках РФ, где винда была поголовно ворованной, пользовались винНТ (комп под НТ, пожирательницу ресурсов, стоит целое состояние, еще и за ось платить?! ;)), крупные и уважающие себя конторы сидели под более надежной и быстрой нетварью, а ее админы ценились. Лохам же лень учить команды, разбираться в командной строке, им графические кнопочки подавай, а потому - кривая НТ, вечно теряющая сегменты сети, принтеры, пожирающая ресурсы под свои ненужные никому службы. Благо, платить за нее не надо, ага.

Под полуось был апач, была бесплатная ограниченная дб2. Это к другим репликам о том, что этих прог под полуось не было. Остальное прекрасно докупалось. Думаю, многие помнят тот же Ватком, писавшие отличные компиляторы Си и Фортрана. Для винды всё, чем тут так кичатся, стоило денег, и не малых, не меньше, чем под полуось, если не больше. Впрочем, сама НТ тоже стоила не мало по сравнению с полуосью.

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

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

Помню, в середине 90-ых портировал прогу, написанную для какой-то ЕС-ки на ПК. Всё было написано на Фортране, требующие память подпрограммы активно пользовались винтом. Часть переписал на Си, остальное перевел на современный Фортран и Ваткомовский компилятор. Потом собрал под полуось и под дос с расширением памяти (dos4gw, кажется), а еще под НТ. Так вот под полуосью прога считала чуть ли не в два раза быстрее, чем под дос4гв. И это без всякой оптимизации под нее. Вот это показатель операционки и ФС. Под НТ с нтфс получилось еще медленнее, чем в ДОС. Только идиот может говорить, что перегруженная кривая надстройка над ОС/2 под названием ВинНТ хоть как-то выигрывает самой полуоси. Разве что в рекламных проспектах. Не даром МС сама ее потом закопала.

Я иногда встречаю программы на vala в самых неожиданных местах. Нет никаких причин к тому чтобы писать на ней программы только под гном.

Другое дело, что в других средах свои иконы...

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

Школоте было влом все это расписывать. Один хрень с нею (OS/2) не работали, и что либо доказывать не имеет смысла. За сим откланиваюсь.

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

она прекрасно входила в домены как невари, так и винНТ

только OS/2 LAN Manager server, который стоил как самолет.

громогласный пердеж.

Тут и сравнивать нечего, в то время когда NT 4 уже работала в составе многомашинных кластеров, в os/2 даже не было журналируемой фс и размер файла был ограничен 2 гигами.

У меня было около 100 серверов COMPAQ с Windows NT и я знаю о чем говорю.

Кого закопала MS?

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

Я видел. Брррр.

SOM (начиная с SOM 2.0 от IBM) - реализация CORBA

агащаблин

Об этом было сказано в документации SOM. Тебе есть что возразить?

Понятие подмножества от понятия точного равенства не отличаем?

Я - отличаю, ты - явно нет.

многомашинных кластеров

Стесняюсь спросить - а одномашинные кластеры существуют?

Ну существуют же множества с количеством элементов равным одному, так pourquoi бы и не pas?

Ну существуют же множества с количеством элементов равным одному, так pourquoi бы и не pas?

Ну как бы я не утверждал равенства. Более того, как бывший OS/2-прогер, я точно знаю, что SOM != CORBA.

Только идиот может говорить, что перегруженная кривая надстройка над ОС/2 под названием ВинНТ хоть как-то выигрывает самой полуоси.

Только идиот не замечает очевидного факта, что Windows уже выиграла у OS/2, еще в прошлом веке. Даже 1С Бухгалтерия под os/2 не работала и российские пользователи дружно сказали «закопать».

система тащит мне поддержку корейского языка и письма справа налево. Из-за чего я и ущел с дебиана на генту.

Я аж слезу пустил. Нам вас очень будет не хватать...

Для нищебродов жадных до мегабайтов придумали localepurge.

Возможно. Я наверняка пробовал запускать (точно не помню, это было году в 95-96-ом) и в w3.1 и в w95, но не пошло. Может быть руки кривые.

Угу. Локали. А то, что это поддерживается отдельными библиотеками (которые можно не тянуть, если задать правильные ключики при сборке) - вы не в курсе? То есть мегабайтов таки жалко - тех, которые в памяти.