Обновился инструмент для работы с агентами в C++: SObjectizer 5.5.5

Круто. А кто авторы проекта? И насколько экспериментальна поддержка сборки CMake?

Кстати, отсюда:

message(FATAL_ERROR «Your C++ compiler does not supported.\nPlease mail me on san@masterspline.net Your compiler ID '${CMAKE_CXX_COMPILER_ID}' and this error message.»)

сразу видно, что авторы русскоязычные)

А кто авторы проекта?

Я + еще несколько моих бывших коллег.

И насколько экспериментальна поддержка сборки CMake?

Поддержка CMake была добавлена Алексеем Сырниковым. С тех пор мы стараемся поддерживать CMake-скрипты в актуальном состоянии, вроде бы получается. Жалоб пока не было.

Перед релизом сборка посредством CMake проверяется под FreeBSD и clang, а так же под Linux и GCC.

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

сразу видно, что авторы русскоязычные)

Ага, есть такое дело :)

«Шо, опять?» (с)

Напоминает чем-то: «Данила строгает ножиком транзистор... Данила стругает рубанком ножик...» (с) (А когда коту делать нечего...)

«Шо, опять?» (с)

Вам-то что не нравится?

Я ваще забан, а что? :) Кто-нибудь этим пользуется? Истории успеха не видать, но аттеншонвхоринг регулярный.

Кто-нибудь этим пользуется?

Пользуются.

Истории успеха не видать,

Про открытые проекты на SO-5 мне не ведомо. Рассказывать про закрытые довольно стремно, ибо к компании, в которой SO-5 используется, отношения уже не имею. Нет желания нарываться.

но аттеншонвхоринг регулярный.

Проект открытый, под Linux-ом работает. Полагаю, если бы подобными анонсами правила LOR-а нарушались, администрация ресурса уже бы высказала бы свое мнение.

«У нас есть такие приборы, но мы вам про них не расскажем...» (с) «Ну вот и вы говорите» (с)

администрация ресурса уже бы высказала бы свое мнение.

МВИМ - тоже мнение, высказанное на ресурсе неоднократно (мнение оно у всех есть, такова селяви) :)

«У нас есть такие приборы, но мы вам про них не расскажем...» (с) «Ну вот и вы говорите» (с)

Ну если я скажу, что программные компоненты на основе SO-4/SO-5 использовались и используются в реализации систем мобильного банка для ряда крупных российских и не только банков (например, Сбербанк в РФ, Халык-банк в Казахстане), в платформах мобильной коммерции для крупных сотовых операторов (МТС, Мегафон), в системе оплаты сотовой связи для одного из крупнейших банков РФ, в платформе агрегации SMS/USSD-трафика с поддержкой SMS-рассылок объемом в сотни миллионов сообщений (и с подключениями более чем к 30 операторам сотовой связи в странах СНГ и Восточной Европе)... Но не смогу рассказать о деталях, т.к. это под NDA, вам станет легче?

Зачем пытаться прилепить к говну модель акторов, если есть языки, которые поддерживают ее естественным образом, семантически? Не лучше ли оставить говно в покое, пусть плавает в своем свободном плавании, а конкурентные системы писать на нормальных ЯП?

а конкурентные системы писать на нормальных ЯП?

Это каких, например?

Сферических, в вакууме))

видимо, речь про go, erlang, scala+akka

Сферических, в вакууме))

Я бы предпочел услышать «правильный ответ» :)

Есть, конечно, Erlang. Но это динамика, да еще и не очень шустрая. Да еще и ставшая популярной не так давно. Да еще в последнее время попадаются на глаза реплики о разочаровании в Erlang-е, наступающем после первоначального энтузиазма.

Был еще язык E, но вряд ли он вышел за пределы очень узкого круга пользователей.

Хотя есть у меня серьезное подозрение, что аноним говорил о каком-то варианте Lisp-а :)

go

Это не модель акторов. Go дает типизированные каналы. Если нужен «актор» которому следует работать с несколькими каналами, то это все нужно будет делать вручную.

Кроме того, отсутствие в Go нормального ООП, шаблонов и исключений, делает этот язык подходящим далеко не для всех. Впрочем, это к теме actor model не относится.

erlang

Это да. Но это динамика. Причем не самая производительная.

scala+akka

Это тоже самое, что и C++ в связке с SObjectizer, или C++ в связке с C++ Actor Framework.

Каждый тред одно и то же. ТС, создай отдельную страницу-FAQ, где ответь на все стандартные вопросы: «где применяется», «ерланг рулит», «код говно» и т.д. Прикрепляй ссылку на него в этих своих новостных постах и не ведись на провокации.

ТС, создай отдельную страницу-FAQ

А где об этом прочитать можно?

Хм, прочитать, о том, как написать FAQ? Если вопрос в том, где его разместить, то хоть на ЛОРе отдельной темой или файликом на гитхабе.

Каждый тред одно и то же. ТС, создай отдельную страницу

Но, ведь тогда вообще никаких комментариев не будет. Раньше вон, хоть писали, что SF - аццтой, и вообще без ГитХаба жизни нет, собирать проект каким-то mxx не с руки и так на пару страниц. А щас тока и могут, что «английский не достаточно английский» или «тормозной эрланг да Жава-акка круче».

Кста, по поводу «код - говно». Код проекта проверяется регулярно coverity (который даже при первом прогоне ничего подозрительного не нашел).

отдельную страницу-FAQ

Я подумал, что речь идет о FAQ-е именно на ЛОР-е и что здесь есть для этого какие-то правила. Может есть какая-то инструкция или свод рекомендаций на этот счет.

А сделать FAQ в другом месте не проблема.

Зачем пытаться прилепить к говну модель акторов, если есть языки, которые поддерживают ее естественным образом, семантически? Не лучше ли оставить говно в покое, пусть плавает в своем свободном плавании, а конкурентные системы писать на нормальных ЯП?

Иногда тебе нужны свойства «говна»(нативность, управление памятью, эффективный код и пр.). В том числе и при создании конкурентных систем.

Кста, по поводу «код - говно». Код проекта проверяется регулярно coverity (который даже при первом прогоне ничего подозрительного не нашел).

Я имел в виду код самих акторов. Многословненько.

go

Почти бессмысленный язык. Мода на него определенная есть, но она не оправдана, если смотреть на возможности языка. Кроме того, акторов там из коробки нет и нужно писать/использовать что-то библиотечное. сопрограммы на стероидах + каналы могут не все. Это несколько другая модель, чем акторы.

erlang

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

scala+akka

Хорошее решение и хороший язык. Но не всегда мы разрабатываем для JVM. Нативность еще востребована.

Многословненько.

Уменьшению многословности постоянно уделяется много внимания. И обсуждения, в том числе и на LOR-е, сильно способствуют уменьшению многословности.

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

Кроме того, отсутствие в Go нормального ООП ... Впрочем, это к теме actor model не относится.

Еще как относится. Нормальная, бескостылная, реализация акторов возможна только в языке с чистым ООП, где все есть объект. Объект инкапсулирует состояние и поведение, актор инкапсулирует состояние, поведение и процессинг. Одно ложится на другое. Любая другая реализация — это уродство и костыли.

А какие преимущества и недостатки у SObjectizer в сравнении с http://actor-framework.org/ ?

Вот, что писалось на эту тему около года назад:

http://eao197.blogspot.com/2014/07/progc-sobjectizer-libcppa.html

http://eao197.blogspot.com/2014/07/progc-libcppa.html

Думаю, что в плане актуальности ничего сильно не изменилось. Разве что, по моим наблюдениям, авторы CAF сейчас свой фреймворк несколько переделывают, так что его API видоизменяется от версии к версии.

Плюс, если нужна платформа Windows, то в CAF это только через MinGW. А SO-5 поддерживает MSVC++ 12.0 из коробки.

Отсюда получается, что SObjectizer более зрелый проект, хотя у CAF тоже есть некоторые свои преимущества. Но CAF качественнее распиарен. А взаимодействовать вы не пробовали?

хотя у CAF тоже есть некоторые свои преимущества.

У меня есть достаточно сильное ощущение, что каждая разработка идет своим собственным путем и преследует собственные цели.

Когда история SObjectizer (тогда еще SCADA Objectizer) начиналась, я лично про actor model вообще не знал. Знакомство с этой моделью и, тем более, ее использование в качестве «красной тряпки» при анонсах релизов SO-5, произошло гораздо позже.

SObjectizer идет от задач, характерных для АСУТП (SCADA). Собственно, мне сегодня напомнили про одно из таких внедрений SO-4. Это очень похоже на то, для чего когда-то давно мы свою модель агентов и разрабатывали. Ключевыми чертами которой являлось представление агентов в виде конечных автоматов и предоставление агентам контекста, на котором агенты могут выполнять свои действия.

Кстати говоря, в 2002-м году мы решились потратить какое-то время на возрождение проекта Objectizer-а и разработку первой версии SO-4 после опыта написания небольшого GUI-приложения для работы с SIM-картами через PC/SC-ридеры. Там, пришлось вручную сделать часть того же самого механизма распределения работы между объектами и рабочими нитями, как мы это делали в SCADA Objectizer-е. Но очень примитивно. Зато после появления SO-4 такие вещи стали делаться много проще.

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

Разработчики CAF, как мне представляется, изначально пошли от actor model, причем от ее воплощения в Erlang-е. И своей целью они ставят упрощение утилизации имеющихся сейчас вычислительных ресурсов (в первую очередь многих вычислительных ядер) за счет распределения работы между акторами. Именно поэтому в CAF есть два типа акторов (обычные и привязанные к отдельным нитям).

Поэтому я считаю, что SO — это инструмент для concurrent programming, да еще склоняющийся в сторону задач, похожих на управление внешними устройствами. Тогда как CAF — это инструмент для parallel programming, т.е. максимальная утилизация вычислительных ресурсов.

Насколько здесь возможна какая-то синергия — не знаю.

Как по мне, так пусть лучше каждый фреймворк развивается в своем направлении. В конце-концов, в мире C++ живых открытых проектов такого уровня всего два (SO-5 и CAF), так что места под Солнцем должно хватить всем.

Но CAF качественнее распиарен.

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

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

Да и для пиара нужно иметь талант. Чего, очевидно, у меня нет.

Но, надеюсь, терпение и время сделают свое дело.

А взаимодействовать вы не пробовали?

Нет. Не думаю, что разработчики CAF-а про нас вообще знают.

используются в реализации систем мобильного банка для ряда крупных российских и не только банков (например, Сбербанк в РФ

Если какая-то вещь используется в Сбербанке, это хороший повод её обходить стороной.

повесели нас еще

Вот, для ответа на вопрос на reddit-е пришлось написать очередное сравнение SO-5 с CAF. Более актуальное, т.к. CAF за последний год, как выясняется, довольно сильно изменился.

Написано, правда, на Runlish-е, но, надеюсь, основные вещи будут более-менее понятны :)

Вот этот вот момент меня заинтересовал:

Network transparency was removed from SObjectizer-5 so the SObjectizer-5 itself has no facilities to build distributed applications. Externals libraries should be used in that case. This is a conscious decision.

То есть поддержку сети выкинули, но насколько сложно её сделать? Есть ли сериализация сообщений в не зависящий от архитектуры формат?

То есть поддержку сети выкинули, но насколько сложно её сделать? Есть ли сериализация сообщений в не зависящий от архитектуры формат?

Тут довольно непростая история. В SO-4 поддержка распределенных приложений была реализована сразу в ядре SObjectizer. И уже на ее основе другие библиотеки реализовывали тот или иной функционал. Где-то это было удобно (например, при распространении мониторинговой информации наружу), где-то не очень (например, при реализации чего-то вроде MQ и publish/subscribe).

Поэтому в SO-5 было принято решение не реализовывать коммуникационные возможности в самом ядре SO-5. А вынести это во внешние библиотеки. Для того, чтобы эти библиотеки могли тесно интегрироваться с ядром SO, в SO-5 было добавлено такое понятие, как «слой» (layer). Идея была в том, что ядро SO есть у пользователя всегда, а вот дополнительную функциональность пользователь мог бы «наслаивать» на ядро по мере надобности.

Исходя из этой идеи были реализованы библиотеки so_transport и mbapi, которые как раз являлись layer-ами для SO. Библиотека mbapi предоставляла высокоуровневый механизм обмена сообщениями между агентами. При котором обеспечивалась та самая network transparency.

Однако, все это базировалось на ACE Framework. И до августа прошлого года релизы SO-5 представляли из себя релизы сборок (assemblies), в которые входили само ядро SO-5, а так же последние стабильные версии библиотек, разработанных над этим ядром (в том числе и so_transport, и mbapi). Вот, например, анонс последней такой сборки.

Но где-то в это время по ряду причин сильно уменьшились ресурсы, вовлеченные в разработку SO-5. Фактически, с тех пор разработка ведется силами одного человека. Понятное дело, что силы эти не безграничны.

Поэтому, после того, как ядро SO-5 было отвязано от ACE Framework, разработка дополнительных библиотек (т.к. so_transport и mbapi) остановилась. На то, чтобы возродить их и довести до ума (а там, к сожалению, не все было сделано хорошо с самого начала) просто нет ресурсов.

Кроме того, лично у меня есть большие сомнения в том, что транспортный слой должен делаться на самом SO-5. Ведь есть куча готовых инструментов с поддержкой различных транспортов (навскидку: ZeroMQ, nanomsg, MQTT, AMQP, DDS, не говоря уже о разных формах на базе HTTP (REST, XML-RPC, SOAP)) и способов сериализации данных (protobuf, thrief, boost.serialization, cereal, message pack и т.д.)... И зачем создавать еще что-то? Не лучше ли сосредоточиться на эффективном и мощном диспатчинге сообщений, а средства коммуникации предоставить тем, кто профессионально этим занимается?

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

попадаются на глаза реплики о разочаровании в Erlang-е

в твоих мечтах.

нативность, управление памятью, эффективный код и пр.

да хоть на окамле, хоть на хаскеле хоть на асемблере бири и пеши уские места, лишь бы ffi был. песать на крестах веб серверы - это ж надо быть настолько умным.

песать на крестах веб серверы - это ж надо быть настолько умным.

Гуглу это расскажите. Или Facebook-у, который и VM для PHP на C++ переписывает, и трансляцию из PHP в C++ делают.

А уж с развитием IoT, где совсем маломощные устройства будут RESTful-интерфейсы наружу выставлять, актуальности в написанных на C и C++ веб-серверах не будет вообще, от слова совсем, да. Грамотеи вроде вас будут начинку для таких устройств на OCaml-е с Haskell-ем писать, а узкие места на ассемблере через FFI реализовывать.

Удачи вам в ваших теплых и уютных фантазиях.

в твоих мечтах.

Несколько месяцев назад случился эпичнейший флейм в dmzlj.livejournal. Как раз из-за того, что ув.dmz высказал свое «фи» по результатам нескольких лет использования Erlang-а. Флейм был насколько эпичным, что автор просто снес все содержимое своего ЖЖ после этого. Думаю, на ЛОР-е есть люди, которые имели удовольствие почитать, а может и поучаствовать в том сраче.

Из недавнего еще вот это можно отметить: http://eax.me/erlang-is-specific/

Ну а жалобы Erlang-еров на качество имеющихся библиотек — это вообще встречается сплошь и рядом.

к логопеду, быдлятина

А интеграция с механизмов сигналов/слотов QT возможна? Т.е. есть у меня, допустим, много-много GUI-шных форм на QT, к которым я хочу добавить функциональность фреймворка из топика. Можно ли это безболезненно сделать?

Мы делали такое в свое время в SObjectizer-4. Для Qt3 точно, и может быть, даже для Qt4. Выглядело это так:

• был разработан специальный диспетчер, который использовал для диспетчеризации очередь событий самой Qt;
• Qt-шный виджет, который хотел получать сообщения от SO-4, наследовался не только от Qt-шного класса (QWidget-а или чего-то подобного), но и от SO-шного agent_t;
• такой Qt-виджет/SO-агент привязывался к специальному диспетчеру из первого пункта.

В итоге подобный Qt-виджет/SO-агент работал на главной нити приложения, но был обычным агентом, получал обычные сообщения и т.д.

Для SO-5 необходимости интегрироваться с Qt у нас не было пока. Не вижу препятствий в реализации подобного же механизма. Разве что за исключением выбора подходящей лицензии (т.к. Qt сейчас лицензируется сразу под тремя лицензиями и разобраться в этом хитросплетении без бутылки не получается ;))

Забавно. Кажется, впервые в жизни может потребоваться множественное наследование)))Впрочем, поковыряю SO еще на досуге на предмет осознания нужно ли оно сейчас мне, или нет. Спасибо за ответ.

Проект живет на SourceForge

поцоны не качайте! там вирус комп сгорел! пишу с икеевского тапка

http://www.opennet.ru/opennews/art.shtml?num=42318

поцоны не качайте!

Да, поцонам не качать ни в коем разе!

Для всех остальных есть зеркало на GitHub.

PS. Это мне кажется или на самом деле количество долбодятлов на LOR за последние годы выросло?

количество долбодятлов на LOR за последние годы выросло?

да

да хоть на окамле, хоть на хаскеле хоть на асемблере бири и пеши уские места, лишь бы ffi был. песать на крестах веб серверы - это ж надо быть настолько умным.

Т.е. ты предлагаешь мне писать на Си для ffi всяких маргинальных языков? И это на ровном месте? И кто после этого извращенец? Ты из-за религиозной слепой неприязни к инструменту сам городишь костыли на ровном месте. Глупо.

поковыряю SO еще на досуге

Если будешь клонировать с GitHub git'ом, то там в readme написано, как это делать. В репозитории используются submodules, поэтому нужно клонировать рекурсивно, либо отдельно их подгружать.

Многословненько.

Чтобы не быть голословным, вот наглядный пример того, как меняется ситуация: http://eao197.blogspot.com/2015/05/progc11-sobjectizer-5.html

Желаю успеха в дальнейшем развитии)

Спасибо!

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