LINUX.ORG.RU

SObjectizer v.5.5.23 и so_5_extra v.1.2.0

 , , , ,


1

3

Состоялся релиз SObjectizer-5.5.23 и so_5_extra-1.2.0. Официальный анонс здесь.

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

На базе этой фичи в so_5_extra-1.2.0 реализовано несколько новых инструментов. Так, добавлена возможность отсылки сообщений, которые можно отозвать. Например:

// Отсылаем сообщение и сохраняем ID доставки.
auto id = so_5::extra::revocable_msg::send<my_message>(mbox, ...);
... // Делаем что-то еще.
if(some_condition())
   // Решаем, что сообщение нужно отозвать.
   id.revoke(); // Если сообщение еще не дошло до получателя,
                // то оно будет отозвано и к получателю не попадет.
Отзывать можно и таймерные сообщения (т.е. отложенные и периодические). В этом случае сообщение будет отозвано даже если оно уже попало в очередь получателя (обычные таймерные сообщения в SObjectizer-е в этом случае до получателя все равно доходят).

Еще одна из новых фич so_5_extra — возможность ограничить время доставки сообщения. Например, если сообщение не доставлено до получателя за 10 секунд, то оно выбрасывается и получателю уже не доставляется. Выглядит это так:

// Создаем экземпляр сообщения, которое хотим доставить.
so_5::extra::enveloped_msg::make<check_user>(...)
   // ...теперь запаковываем его в специальный конверт...
   .envelope<so_5::extra::enveloped_msg::time_limited_delivery_t>(10s)
   // ...и отсылаем конверт с нашим сообщением..
   .send_to(target_mbox);

Взять SO-5.5.23 можно на SF.net или на GitHub-зеркале.

Взять so_5_extra-1.2.0 можно на SF.net.

Хочется поблагодарить не только тех людей, которые помогали нам с этим релизом. Но и вообще всех, кто проявлял интерес к SObjectizer-у все эти годы и находил время/возможность делится с нами своим впечатлениями, соображениями и идеями.

PS. SObjectizer-5.5 развивается уже больше четырех лет. И, вероятно, развитие ветки 5.5 подходит к своему логическому завершению. Если кому-то интересно посмотреть на то, что появилось в SO-5.5 за это время, то вот небольшой конспектик.

★★★★★

Взять SO-5.5.23 можно на SF.net

Дежурное напоминание, что SF - помойка. Надеюсь, моё мнение важно для вас.

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

«Если раздавать лекарства бесплатно, то обязательно найдутся люди, которые будут недовольны цветом таблеток» (с) не мое.

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

Это да. Читал историю на пикабу, в которой владельцы магазина решили определённый объём хлеба раздавать бесплатно пенсионерам. Так там столько на них дерьма вылилось, что они свернули эту акцию.

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

А как у вас со скоростью передачи?

Передачи чего и куда?

Быстрей чем Fast Delegates или хотя бы std::functions?

У нас std::functions внутри. Это не считая того, что когда актор получает сообщение, то нужно сперва найти подписку для сообщения. При этом актор — это иерархический конечный автомат и при поиске может потребоваться просмотр не только текущего состояния, но и его родителей.

eao197 ★★★★★ ()

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

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

  • SO4, SO5 и, возможно, SO6 - это разные продукты, как libpng и libjpeg,
  • первая цифра в версии SO5 всегда 5, а поэтому, не нужна (по сути major - это 5.5 в текущей версии),
  • если убрать первую цифру из версии и дописать к оставшейся версии цифры до трех номеров, то получится на 100% семантическое версионирование, которое всем понятно и стандартизировано,
  • переход на семантическое версионирование никак не повлияет на версионирование продукта (по сути из 4-х номеров в версии продукта последние 3 - это семантическая версия, а первая цифра - часть названия продукта).

SO-5.5.23 -> SO5-5.23.0

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

если убрать первую цифру из версии и дописать к оставшейся версии цифры до трех номеров, то получится на 100% семантическое версионирование, которое всем понятно и стандартизировано

Ну так, в общем-то сейчас и есть: SObjectizer-4.4.8, SObjectizer-5.5.23 и SObjectizer-5.6.0.

Персонально мне (подчеркну, лично мне) семантическое версионирование с номером версии из трех составляющих не очень нравится. И я не думаю, это подходит для библиотек.

Для библиотек нужно иметь номер из четырех составляющих, которые явно указывают на совместимость: gen.major.minor[.patch]. Где:

gen(eration) — номер поколения. Изменение номера указывает, что библиотеки несовместимы настолько, что запросто могут смешиваться в рамках одного исходника. Вот как SO-4 и SO-5.

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

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

patch — номер обновления. Меняется когда фиксятся баги или незначительно обновляются зависимости, но ничего не убирается, не меняется, не добавляется. Вот как для случая с SO-5.5.22 и SO-5.5.22.1

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

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

Да причин не так уж и мало. Например:

SF просто работает. Просто работал 12 лет назад, когда SO там разместили, просто работает и сейчас.

SF предоставляет очень многое из того, что нам нужно, прямо из коробки. VCS на выбор, issue tracker, forums, wiki, news, blog, CDN для файлов/дистрибутивов.

С каждым релизом на SF накапливается все больше информации, которую нужно будет как-то преобразовывать при переезде на другую площадку (например, тот же самый Wiki с ссылками между страничками).

Хостинг на SF выделяет из общей массы. Не суть важно, с каким знаком — положительным или отрицательным, важно что остается зарубка «а, это те, которые на SF».

Хостинг на SF стал отличным фильтром, который явно отделяет тех, кто инструментом интересуется всерьез, от тех, кто хочет только потрындеть. Как только некто заводит шарманку о том, почему не GitHub, сразу же можно сказать с почти 100% уверенностью, что SO ему не нужен и пользоваться SO не будет. Это уже проверено временем.

Отдельно можно сказать про косяки, которые прошлые владельцы SF допускали. Во-первых, мы с ними не сталкивались. Во-вторых, SF, как и BitBucket, как и GitHub в прошлом, — это коммерческие предприятия. И на что могут пойти их владельцы ради получения прибыли... Да на что угодно. Просто первыми прокололись владельцы SF, но никто из других хостеров от этого не застрахован.

Очень надеюсь, что тему раскрыл достаточно и больше эта тема развиваться не будет.

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

Под SDL понимается Specification and Description Language.

Спасибо за ссылку, никогда раньше про такую штуку не слышал.

После поверхностного знакомства складывается впечатление, что это инструменты из совершенно разных весовых категорий. SDL — это ынтырпрайзно, глобально и надежно. Предназначено для больших проектов, с кучей подрядчиков, в которых спецификации может делать одна организация, верифицировать эти спецификации — вторая, воплощать в коде и «железе» третья, а тестировать и разворачивать это все — четвертая.

Соответственно, в SDL во главу угла ставится формальная спецификация, которая (вроде как) не привязана к конкретному языку программирования. Т.е. из одной и той же спецификации можно получить код и для Ada, и для C.

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

Тогда как SObjectizer — это небольшой фреймворк для конкретного (и одного единственного языка программирования). Соответственно, реализация на SObjectizer-е сразу же строится в программном коде, без возможностей каких-либо симуляций или верификации.

Можно, наверное, и так посмотреть. Для каких-то случаев, вероятно, из SDL-спецификаций можно было бы код на SObjectizer-е генерировать. Тогда можно было бы сказать, что SObjectizer выступает в качестве одной из «подложек», на которые можно отобразить SDL-спецификации.

Ну и еще один момент стоит отметить: SObjectizer-5 не может использоваться для построения систем реального времени. Тогда как SDL это декларирует.

PS. А вы SDL в работе применяете?

eao197 ★★★★★ ()

В конце ноября начались работы по добавлению в SObjectizer возможностей писать unit-тесты для агентов (что-то наподобие Akka's TestKit, но с сильной поправкой на особенности SObjectizer-а).

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

Есть несколько идей о том, как эта «заморозка» может быть сделана. Если кому-то интересно, то текущие варианты описаны здесь: https://sourceforge.net/p/sobjectizer/discussion/550088/thread/d0ea4b655c/?pa...

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

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

Спасибо за развернутый ответ.

А вы SDL в работе применяете?

Одно время знакомился с этим направлением. Кстати, интересный факт: если не ошибаюсь (иначе поправьте), то инструментальные средства для SDL-моделирования (фронтэнд и бэкэнд), входящие в состав IBM Rational SDL Suite (бывший Telelogic SDL Suite) были созданы в ИСП РАН еще в 90х годах. Источник: http://panda.ispras.ru/groups/space/projects.html.

Еще вопрос: в чем ключевые сходства/отличия SObjectizer от библиотеки cpp_stm_free? Для каких задач может потребоваться интеграция STM в агентный фреймворк?

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

Еще вопрос: в чем ключевые сходства/отличия SObjectizer от библиотеки cpp_stm_free?

Сходств я не вижу. Отличия же состоят в том, что Actors/CSP и STM — это разные подходы к работе с разделяемыми данными в concurrent computing.

Подход на базе Actors/CSP состоит в том, чтобы разделяемых данных не было вообще. Ну вот в принципе. Есть только отдельные сущности с собственными приватными данными и никто к этим приватным данным получить доступ не может. Но, поскольку какая-то совместная работа в приложении нужна, то между сущностями организуется взаимодействие. В случае Actors/CSP это взаимодействие выполняется на основе асинхронного обмена сообщениями.

Подход на базе STM состоит в том, что от разделяемых данных мы не отказываемся, но операции по их модификации оформляем в виде транзакций (на основе оптимистичной стратегии, т.е. надеемся, что конфликты при завершении транзакций будут редкими).

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

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

В случае STM у нас будет один общий граф, который виден всем рабочим потокам. Но работа с этим графом (или отдельными его частями) будет происходить за счет STM-овских примитивов.

Это если говорить про идеологические различия. В техническом плане cpp_stm_free — это экспериментальный proof-of-concept проект от хаскелиста, который упарывается (в хорошем смысле слова) переносом FP-шных концепций в C++. Сам автор не очень понимает, где и когда его библиотека может быть использована в реальной разработке (и какие показатели производительности она там покажет). Тут недавно было обсуждение с участием Александра Гранина: cpp_stm_free: монадическая STM библиотека для параллельного программирования

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

Для каких задач может потребоваться интеграция STM в агентный фреймворк?

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

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

Будешь конечно смеяться, но именно такие же, какие пользоваться C++ примерно. Я это серьезно причем.

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

пикабу

тонко! не подкопаться теперь, что пикабу это помойка :)

Deleted ()
Ответ на: удаленный комментарий

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

Он же мееееееееееедленный

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

Когда у тебя есть сценарии, что нужна актор модел - медленность конкретной VM там уже на последнем месте среди всех considerations

lovesan ★★ ()
Ответ на: удаленный комментарий

Специально для столь альтернативно одаренных личностей как вы, три года назад было дано максимально доступное для людей с вашими умственными способностями объяснение: Так зачем SObjectizer, если есть Erlang?

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

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

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

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

Я же вам написал: с первого раза у вас понять не получится, поэтому сосредоточтесь и перечитывайте пока до вас не дойдет.

eao197 ★★★★★ ()

SObjectizer-5.5.24 и so_5_extra-1.2.2

SObjectizer обновился до версии 5.5.24. Главное нововведение в этой версии — это экспериментальная поддержка unit-тестирования для агентов. Подробнее эта возможность описана в отдельной статье. Если кому-то интересно, то попробуйте, поделитесь своими впечатлениями. Любой конструктивный фидбэк поможет нам сделать эту поддержку лучше и удобнее.

SObjectizer может быть загружен из секции Files на SourceForge или взят из зеркала на GitHub-е. SObjectizer может быть установлен с помощью vcpkg или Conan.

Также обновился сопутствующий проект so_5_extra: мы перевели его на более свежие версии зависимостей и добавили еще один пример в набор штатных примеров.

so_5_extra может быть загружен из секции Files на SourceForge. Также so_5_extra может быть установлен с помощью vcpkg или Conan.

eao197 ★★★★★ ()

На пути к SObjectizer-5.6

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

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

PS. «Закопать» к конструктивным соображениям не относится. Желающие подобным образом поиспражняться в ослоумии могут не тратить ни свое, ни мое время.

eao197 ★★★★★ ()
Ответ на: На пути к SObjectizer-5.6 от eao197

До сих пор исходники SObjectizer-а жили в Subversion репозитории на SourceForge с экспериментальным зеркалом на GitHub-е. Для SObjectizer-5.6 это уже будет не так.

Во-первых, скорость работы с Svn на SF.net в последнее время стала недостаточно хорошей. И сам Svn-репозиторий на SF.net время от времени оказывается недоступным.

Во-вторых, хотелось бы иметь более простую интеграцию с сервисами, вроде TravisCI, без процедуры зеркалирования куда-то Svn-репозитория.

На четвёртый день Зоркий Глаз заметил…

В качестве основного варианта пока рассматривается разработка SO-5.6 непосредственно на GitHub-е (с именем вида https://github.com/Stiffstream/sobjectizer-5.6). Но кое-кто из разработчиков SObjectizer-а (например, eao197) не любит ни git, ни GitHub.

Поэтому есть альтернативный вариант – Mercurial-репозиторий на BitBucket-е (с именем вида http://bitbucket.org/sobjectizerteam/sobjectizer-5.6). С зеркалом на GitHub. Благо Hg зеркалируется в git гораздо проще.

Поехали.

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

На четвёртый день Зоркий Глаз заметил…

GitHub-зеркало и интеграция с Travis-ом уже года три как в полный рост.

Поехали.

Куда именно? GitHub, GitLab, BitBucket?

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

GitHub-зеркало и интеграция с Travis-ом уже года три как в полный рост.

Ну вот я и говорю — на четвёртый день Зоркий Глаз заметил, что с SF пора бы и съезжать.

Поехали.

Куда именно?

Флеймить про git vs. hg, конечно же. Это в смысле «о, сейчас начнётся».

GitHub, GitLab, BitBucket?

Я не пользуюсь SO5 (хотя и игрался в своё время), поэтому моё мнение здесь бесполезно и имеет нулевую ценность. Это я так, вр.и.о. шута.

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 3)
Ответ на: комментарий от intelfx

Ну вот я и говорю — на четвёртый день Зоркий Глаз заметил, что с SF пора бы и съезжать.

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

Это в смысле «о, сейчас начнётся».

А, понятно.

Тем не менее, если абстрагироваться от конкретно SO-5, вам лично плюсовые проекты откуда проще забирать или где вам с чужими плюсовыми проектами проще иметь дело?

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

Совсем забыл сюда ответить.

Тем не менее, если абстрагироваться от конкретно SO-5, вам лично плюсовые проекты откуда проще забирать или где вам с чужими плюсовыми проектами проще иметь дело?

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

А вот работать с чужими проектами проще на GitHub или GitLab. На GitHub больше всего людей и проектов, поэтому привыкаешь именно к его тулзам и UI (а GitLab очень похож). Во-вторых, у GitHub в последнее время как-то существенно допилили review-фичи (в сравнении с вышеназванными аналогами; до standalone review-решений всё это, разумеется, не дотягивает). В-третьих, удобно ссылаться на PR и issues (но это так себе аргумент, у кого где большинство проектов, к тому хостингу и тяготеют). Наконец, удобно, когда вся FOSS разработка в одном месте — можно ссылаться на activity feed в резюме :)

Но на самом деле это всё пишется с точки зрения этакого «drive-by участника», когда ты делаешь что-то постороннее и почему-то возникает необходимость быстро и не парясь заслать в до этого неизвестный тебе проект какой-то тривиальный патч пару строчек. Примерно вот об этом:

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

(src @Vit)

Я догадываюсь, что у SO-5 совсем другая аудитория.

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от intelfx

А вот работать с чужими проектами проще на GitHub или GitLab.

Большое спасибо за то, что нашли время ответить.

Ответы такого рода, действительно, помогают определится с выбором.

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

Проект одним человеком разрабатывается? Видно, что коммиты только от одного человека. Для одного человека, конечно, пофиг, где проект размещать. А если хочется, чтобы пользователи сами багфиксы присылали, то вряд ли, к проекту подключится кто-либо, даже если у него OSS лицензия, потому что он на Sourceforge. Никакой нормальный человек не будет с Sourceforge связываться в наше время. Скачать с него что-либо ещё куда не шло. К пул реквесты посылать, это время тратить зря. К тому-же у вас там SVN. Ещё одна мёртвая технология, которую теперь никто уже не знает.

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

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

На данный момент одним.

А если хочется, чтобы пользователи сами багфиксы присылали

Скорее хочется, чтобы пользователи создавали issue и feature request-ы. PR-ы, как показывает история, все равно приходится творчески перерабатывать.

Скачать с него что-либо ещё куда не шло.

Собственно, для этого SF и используется: там и tarball-ы, и архивы с бинарниками, и Wiki с документацией.

С неприятием SF все понятно. Цель в том, чтобы понять, что из альтернатив (в первую очередь GitHub, GitLab, BitBucket) вызывает наименьшее неприятие.

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

Vadim Lopatin (автор Cool Reader) недавно перенёс репозиторий своего проекта на GitHub. Ну и потихоньку ему начали капать Issue и PR’ы. С SourceForge действительно никто не хочет в наше время заморачиваться и проект там валялся заброшенным.

Собственно, для этого SF и используется: там и tarball-ы, и архивы с бинарниками, и Wiki с документацией.

Всё это имеется на GitHub’е, GitLab’е и даже больше. Ну и скачивать с GitHub’а вообще нет проблем, а на SourceForge вечно какие-то «пожалуйста подождите и посмотрите рекламу».

Цель в том, чтобы понять, что из альтернатив (в первую очередь GitHub, GitLab, BitBucket) вызывает наименьшее неприятие.

Даже когда вы выберете что-то основное (имхо лучше GitHub, потому что там есть аудитория), можно просто сделать зеркала своего репозитория на все эти ресурсы + оставить Git-зеркало на SourceForge на всякий случай. Потом настроить свой локальный Git-репозиторий таким образом, чтобы при выполнении команды git push происходила публикация изменений сразу на 3-4 ресурса. Очень удобно.

EXL ★★★★★ ()
Последнее исправление: EXL (всего исправлений: 1)
Ответ на: комментарий от EXL

Всё это имеется на GitHub’е

Несколько лет назад мы уже рассматривали возможность переезда на GitHub, но тогда там убрали возможность выкладывать свои собственные архивы. Для этого нужно было выстраивать интеграцию со сторонними сервисами, вроде JFrog-а. Тогда как на SF никаких проблем с дистрибуцией zip-ов с бинарниками внутри не было.

имхо лучше GitHub, потому что там есть аудитория

OK, спасибо.

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

но тогда там убрали возможность выкладывать свои собственные архивы

Вероятно всего это был процесс миграции с GitHub Downloads на GitHub Releases.

EXL ★★★★★ ()

Рассказ об использовании SObjectizer-а в "дикой природе"

Статья на Хабре про опыт использования SObjectizer-а для управления оборудованием сцены: «Если проект «Театр» используй акторов…»

Мы сами к этому проекту не имеем никакого отношения. Знали только, что SObjectizer используется. Но как и где — не знали.

eao197 ★★★★★ ()

Желающие повлиять на разработку SObjectizer-5.6 могут сказать свое фи помочь высказав свое мнение по одному довольно важному поводу. Высказаться можно либо в Google-группе, либо на GitHub-е. Либо прямо здесь, в этой теме.

eao197 ★★★★★ ()

На случай если это вдруг кому-то интересно...

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

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

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

А вот переделка механизма синхронного взаимодействия выглядит куда более реальной. Суть этого изменения описана в свежем посте в Google-группе: https://groups.google.com/d/msg/sobjectizer/NLUWxUNinbg/-mjclYjGBwAJ Кому интересно, милости прошу ознакомиться. А если будет еще и какой-то фидбек, то будет вообще хорошо.

Пару слов о предполагаемых сроках релиза. Судя по тому, что в феврале удалось сделать лишь половину задуманного, а так же прикидывая объем документации, который предстоит перелопатить после завершения работы над кодом... Раньше конца марта ожидать выхода версии 5.6 не приходится.

eao197 ★★★★★ ()

В лепёшку расшибутся, лишь бы Раст не учить.

Pacmu3ka ()

не понимаю срача на тему нужен/ненужен, если уже есть и даже неплохо, судя по новостям, развивается.

Не CAFом единым же.

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

не понимаю срача на тему нужен/ненужен

Так это же LOR.

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