Здравствуйте, eao197, Вы писали:


Интересные вещи можно найти в грядущей библиотеке PPL от Microsoft (которая станет частью следующей версии MSVC):
Parsing a File with Agents

HRESULT LogChunkFileParser::ParseFile() {
  unbounded_buffer<AgentMessage> msgBuffer = 
    new unbounded_buffer<AgentMessage>();  
  agent_task* pParserAgent = agent_task::start([&] {
    AgentMessage msg;
    while((msg = receive(msgBuffer))->type != EXIT) {
      Parse(msg->pCurrentLine);
      delete msg->pCurrentLine;
    }
  });
  HRESULT hr = reader->OpenFile(pFileName);
  if (SUCCEEDED(hr)){
    while(!reader->EndOfFile()) {
      WCHAR* wszLine = new WCHAR[MAX_LINE];
      hr = reader->ReadLine(wszLine, MAX_LINE);
      if (SUCCEEDED(hr)) {
         send(msgBuffer, AgentMessage(wszLine));
      }
    }
    send(msgBuffer, AgentMessage(EXIT));
    hr = agent_task::wait_for_completion(pParserAgent);
  }
  return hr;
};

Полная версия тут:
http://msdn.microsoft.com/en-us/magazine/cc817396.aspx


И здесь ещё видео Parallel Computing Platform: Asynchronous Agents for Native Code
http://channel9.msdn.com/posts/Charles/Parallel-Computing-Platform-Asynchronous-Agents-for-Native-Code/
Это тоже о PPL.


Наводит на мысли. Вообще это первый прецедент промышленной Агентно-орентированной библиотеки для нативного кода (не считая SObjectizer). Да и для управляемого кода не так много промышленных библиотек, я не знаю получили ли какое-то промышленное распространение библиотеки типа .NET Agents или как она там называлась... не помню, или Scala Agents.

Здравствуйте, remark, Вы писали:

R>Наводит на мысли. Вообще это первый прецедент промышленной Агентно-орентированной библиотеки для нативного кода (не считая SObjectizer).

Ну что тут сказать... Радует, что выбранное нами когда-то направление сейчас доказывает свою состоятельность в виде этой разработки MS. С другой стороны, агентному подходу уже сто лет в обед и, вероятно, первая серьезная система для агентного программирования -- это язык Scheme (см. http://en.wikipedia.org/wiki/Scheme_progamming_language и http://en.wikipedia.org/wiki/Actor_model).

А вообще, термин "агент" становится слишком перегруженным. Есть FIPA-агенты, которые очень крупные (агент -- это приложение) и используют специальные языки для взаимодействия. Поскольку агенты в SObjectizer гораздо мельче, поэтому я предпочитаю говорить о работе в SObjectizer как о микроагентном программировании. Но все же агенты в SObjectizer оказываются более крупными (с состояниями и пр.), чем агенты в PPL. В этой связи агентов из PPL можно обзывать наноагентами

Так же хочется сказать, что появление C++0x может открыть перед SObjectizer5 новые возможности. В частности lambda-функции. Нужно будет посмотреть. Имхо, вполне можно проектировать SO5 с расчетом именно на C++0x.

R>Да и для управляемого кода не так много промышленных библиотек, я не знаю получили ли какое-то промышленное распространение библиотеки типа .NET Agents или как она там называлась... не помню, или Scala Agents.

Ну перспективы Scala как промышленного языка программирования у меня уже который год вызывает сомнения.

Здравствуйте, eao197, Вы писали:

E>Так же хочется сказать, что появление C++0x может открыть перед SObjectizer5 новые возможности. В частности lambda-функции. Нужно будет посмотреть. Имхо, вполне можно проектировать SO5 с расчетом именно на C++0x.

Вообще я хотел предложить такой вариант. Но надо, конечно, учитывать, что несмотря на то, что основные поставщики компиляторов скорее всего выпустят первые С++0х реализации через несколько месяцев после официального выхода стандарта, тем не менее более-менее стабильные реализации скорее всего появятся только через несколько лет (особенно это касается MSVC и ICC, gcc скорее всего сможет сделать это раньше). Плюс к этому первая волна С++0х докатится не только до ранних адоптеров тоже скорее всего года через 2-3.

Хотя, конечно, полезных вещей там много — лямбды, вариадик-шаблоны, многопоточность и т.д.


R>>Да и для управляемого кода не так много промышленных библиотек, я не знаю получили ли какое-то промышленное распространение библиотеки типа .NET Agents или как она там называлась... не помню, или Scala Agents.

E>Ну перспективы Scala как промышленного языка программирования у меня уже который год вызывает сомнения.

Именно!
Не смотря на то, что модель старая и хорошая, что сейчас может использовать обычный программист, какие есть известные библиотеки для нативного кода (не считая SObjectizer, который всё же больше рассчитан на русскоязычных пользователей)?

Здравствуйте, remark, Вы писали:

E>>Так же хочется сказать, что появление C++0x может открыть перед SObjectizer5 новые возможности. В частности lambda-функции. Нужно будет посмотреть. Имхо, вполне можно проектировать SO5 с расчетом именно на C++0x.

R>Вообще я хотел предложить такой вариант. Но надо, конечно, учитывать, что несмотря на то, что основные поставщики компиляторов скорее всего выпустят первые С++0х реализации через несколько месяцев после официального выхода стандарта, тем не менее более-менее стабильные реализации скорее всего появятся только через несколько лет (особенно это касается MSVC и ICC, gcc скорее всего сможет сделать это раньше). Плюс к этому первая волна С++0х докатится не только до ранних адоптеров тоже скорее всего года через 2-3.

Все это не так страшно. Разработка SO5 стартует все равно не раньше 2009 и займет изрядное время даже если какой-нибудь человек будет ею заниматься в режиме full-time. Даже мы не сможем сразу же использовать SO5 в production-системах -- потребуются обкатка первых версий SO5 на каких-то менее критичных проектах. В таких условиях можно будет просто взять какой-то один компилятор и какую-то одну ОС для предварительных работ над SO5. А когда появится достаточное количество нормально поддерживающих C++0x компиляторов, можно будет серьезно взятся за кроссплатформенность.

R>Хотя, конечно, полезных вещей там много — лямбды, вариадик-шаблоны, многопоточность и т.д.

Пока меня больше всего интересуют именно лямбды. Для многопоточности, вероятно, придется пользоваться какими-то библиотеками вроде ACE или Poco.

R>Не смотря на то, что модель старая и хорошая, что сейчас может использовать обычный программист, какие есть известные библиотеки для нативного кода (не считая SObjectizer, который всё же больше рассчитан на русскоязычных пользователей)?

Если чесно, то не знаю. У меня для работы есть SObjectizer И, по моему убеждению, задача состоит в том, чтобы сделать из SObjectizer что-то типа Erlang для C++.

Здравствуйте, eao197, Вы писали:

E>Все это не так страшно. Разработка SO5 стартует все равно не раньше 2009 и займет изрядное время даже если какой-нибудь человек будет ею заниматься в режиме full-time. Даже мы не сможем сразу же использовать SO5 в production-системах -- потребуются обкатка первых версий SO5 на каких-то менее критичных проектах. В таких условиях можно будет просто взять какой-то один компилятор и какую-то одну ОС для предварительных работ над SO5. А когда появится достаточное количество нормально поддерживающих C++0x компиляторов, можно будет серьезно взятся за кроссплатформенность.


Ну если так, то я думаю, что С++0х — это сильный козырь в рукаве. После выхода С++0х будет значительный недостаток "С++0х" библиотек для второй волны адоптеров. Т.е. вроде как и реализации С++0х достаточно окрепли и много всего вкусного и попробовать хочется, а нечего особо.
А старым библиотекам переходить на С++0х не особо. И переписывать много и обратную совместимость поддерживать надо.


R>>Хотя, конечно, полезных вещей там много — лямбды, вариадик-шаблоны, многопоточность и т.д.

E>Пока меня больше всего интересуют именно лямбды. Для многопоточности, вероятно, придется пользоваться какими-то библиотеками вроде ACE или Poco.


А для чего ты думаешь применять лямбды? Вроде как для функций обработки событий не особо кошерно получается...


R>>Не смотря на то, что модель старая и хорошая, что сейчас может использовать обычный программист, какие есть известные библиотеки для нативного кода (не считая SObjectizer, который всё же больше рассчитан на русскоязычных пользователей)?

E>Если чесно, то не знаю. У меня для работы есть SObjectizer И, по моему убеждению, задача состоит в том, чтобы сделать из SObjectizer что-то типа Erlang для C++.

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

Здравствуйте, remark, Вы писали:

R>Ну если так, то я думаю, что С++0х — это сильный козырь в рукаве. После выхода С++0х будет значительный недостаток "С++0х" библиотек для второй волны адоптеров. Т.е. вроде как и реализации С++0х достаточно окрепли и много всего вкусного и попробовать хочется, а нечего особо.
R>А старым библиотекам переходить на С++0х не особо. И переписывать много и обратную совместимость поддерживать надо.

Тут у меня какое-то непонимание. Разве C++0x -- это совсем другой язык? Какая-то совместимость же у C++0x с C++03 будет. Поэтому со временем просто возникнет момент, когда имеющийся C++ код будет адаптирован под новые версии компиляторов и все. Без доработки напильником, конечно, не обойдется. Но, надеюсь, слишком суровой она не будет.

R>А для чего ты думаешь применять лямбды? Вроде как для функций обработки событий не особо кошерно получается...

Как раз для обработки событий. Сейчас время от времени приходится создавать агентов, которые имеют всего одно состояние и одно-два-три события. Для них получается, что объем "обвязочного" кода, необходимого для SObjectizer, сравним или даже больше объема самих событий. Яркий пример: регистрируется какой-то агент (входящий коммуникационный канал), который может отослать сообщение об ошибки. По этому сообщению нужно остановить работу приложения. Для этого пишется маленький агентик, с одним событием -- реакцией на это сообщение. Этот мелкий агент регистрируется вместе с главным агентом кооперации.

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

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

R>>>Не смотря на то, что модель старая и хорошая, что сейчас может использовать обычный программист, какие есть известные библиотеки для нативного кода (не считая SObjectizer, который всё же больше рассчитан на русскоязычных пользователей)?

E>>Если чесно, то не знаю. У меня для работы есть SObjectizer И, по моему убеждению, задача состоит в том, чтобы сделать из SObjectizer что-то типа Erlang для C++.

R>Да, вакансия-то пока открыта

На то и расчет!

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

Не я не думаю, что разработка server-side на C++ -- это очень уж большая ниша. Больно уж много серьезных конкурентов: Java и .NET с мегабаксами от Sun и MS; Erlang, который сейчас super hot & sexy (на волне интереса к ФП, да и вообще); динамические языки вроде Ruby/Python/PHP, которые нашли себе серьезную нишу в области Web.

Но то, что для C++ место найдется -- я твердо уверен. Так что есть надежда, что место под солнцем мы себе найдем.

Здравствуйте, eao197, Вы писали:

R>>Не смотря на то, что модель старая и хорошая, что сейчас может использовать обычный программист, какие есть известные библиотеки для нативного кода (не считая SObjectizer, который всё же больше рассчитан на русскоязычных пользователей)?

E>Если чесно, то не знаю. У меня для работы есть SObjectizer И, по моему убеждению, задача состоит в том, чтобы сделать из SObjectizer что-то типа Erlang для C++.

В качестве иллюстрации мысли об актуального чего-то вроде Erlang для C++. Вот здесь

Автор: Курилка
Дата: 01.10.08

Курилка дал ссылку на презентацию об использовании Erlang при разработки новой версии службы Delicious в Yahoo. И хоть в самом начале сказано, что по большей части разработка была выполнена на C++, презентация дает читателю понять, что Erlang -- рулез форева (шутка). Так вот, в качестве преимуществ Erlang-а приводятся (стр.31):

• Extremely good at fault-tolerant distributed applications.
• Ideal for messaging, communications and logging.
• Long running jobs with heavy monitoring requirements.
• Agile development process
• Many different interfaces
• RPC baked in for free

Пункты про Agile development и Many interfaces можно не рассматривать, т.к. у C++ с этим все нормально. Остаются fault-tolerance, message communication, monitoring и RPC. Хотя RPC вряд ли имеет смысл сочетать с messaging.

Теперь смотрим на проблемы Erlang-а (стр.32):

• There are documentation gaps.
• Hasn’t achieved critical mass yet.
• The community is thin.

и (стр.29):

• Erlang is very different.
• Engineers are usually stubborn.
• Not enough critical mass at Yahoo to be unquestionable.
• Tension was already high, adding a new language into the mix added uncertainty.

То получается, что внедрение Erlang-а в какой-нибудь существующий C++ проект будет сопровождаться необходимостью изучения совершенно нового подхода к программированию и, для многих, совершенно другого языка. Который плюс ко всему еще и динамически типизирован (что не многие любят). И который может быть N+1 языком в разработке, при том, что N уже превышает границы разумного

В то же время, если дать C++ разработчикам инструмент, который предоставляет хотя бы message communication и monitoring (а еще лучше построенные на их основе средства для fault-tolerance), то C++ разработчикам придется познакомиться только с новым подходом к разработке ПО. Не нужно будет учить новый язык. В их распоряжении останется статическая типизация. Не нужно будет внедрять в разработку новый язык и делать для него интеграцию с уже имеющимся кодом.

Конечно, у Erlang-а не отнимешь, например, горячую замену кода. Но, с другой стороны, Erlang хорош для распределенных систем, а это еще далеко не все, где C++ уже применяется и где еще может (и найдет) свое применение.

Вот как-то так. Блин, может пора уже себе блог заводить? А то таким тирадам вряд ли место в форуме...

Здравствуйте, eao197, Вы писали:

E>И хоть в самом начале сказано, что по большей части разработка была выполнена на C++, презентация дает читателю понять, что Erlang -- рулез форева (шутка). Так вот, в качестве преимуществ Erlang-а приводятся (стр.31):

Насколько я понимаю, в Ерланге нет вообще ничего интересного, кроме полноценно реализованной модели актеров. Всей своей популярности он обязан только ей. Без неё это достаточно примитивный, тормозный, совсем не примечательный язык.

Просто так удачно получилось, что на момент появления широко доступных параллельных систем (многоядерных cpu) он фактически один имел практически пригодную реализацию адекватной модели параллельных вычислений. После того, как до людей начало доходить, что ручное создание потоков с ручной синхронизацией — это неадектватное решение, интерес к нему подскочил, и вот уже крупные компании (Yahoo, Amazon) серъезно вкладываются в Erlang-разработку. Я уже от многих людей слышал, даже от сисадмина, далекого от программирования — типа «erlang это такой язык с крутой параллельностью». Сейчас какой-то hype пошел насчет ерланга.

А ведь в нем как в _языке_ ничего нет для параллельности, более того, другой язык + actors легко может быть более удобным, более быстрым и т.д. имея точно такую же «крутую параллельность». Любая система, реализующая эмуляцию actors на многоядерном процессоре, автоматически получит почти все преимущества Erlang.

Копировать Erlang смысла точно нет — что там копировать? Зато я вот уже при разработке на Objective-C и .Net столкнулся с необходимостью такой выч.машины, и скоро видимо в C++ захочется.

Здравствуйте, Кодёнок, Вы писали:

E>>И хоть в самом начале сказано, что по большей части разработка была выполнена на C++, презентация дает читателю понять, что Erlang -- рулез форева (шутка). Так вот, в качестве преимуществ Erlang-а приводятся (стр.31):

Кё>Насколько я понимаю, в Ерланге нет вообще ничего интересного, кроме полноценно реализованной модели актеров. Всей своей популярности он обязан только ей. Без неё это достаточно примитивный, тормозный, совсем не примечательный язык.

Вот уж не думал, что мне придется выступать в качестве адвоката Erlang-а, да еще в обсуждении разработки, которая (по моим соображениям) должна быть конкурентом Erlang-a

Главное достоинство Erlang-а в том, что он очень хорошо подогнан под реализацию идей его создателей (Джо Армстронга со товарищи) о том, как должно разрабатываться ПО с высокими требования к надежности, отказоустойчивости о доступности.

Множество мелких процессов и обмен сообщениями -- это средство для обеспечения оказоустойчивости. Падение процесса -- это всего лишь падение одного процесса. Shit happens и с этим нужно считаться. Erlang считается с этим посредством мелких процессов, не имеющих разделяемых данных между собой. Обмен сообщениями -- это необходимая (при этом простая и, одновременно, мощная) форма взаимодействия процессов.

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

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

В эту же сторону и динамическая типизация. Замена кода в приложении с динамической типизацией (будь то Erlang, Python или Ruby) выполняется гораздо проще, чем в приложениях со статической типизацией.

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

Кё>Просто так удачно получилось, что на момент появления широко доступных параллельных систем (многоядерных cpu) он фактически один имел практически пригодную реализацию адекватной модели параллельных вычислений. После того, как до людей начало доходить, что ручное создание потоков с ручной синхронизацией — это неадектватное решение, интерес к нему подскочил, и вот уже крупные компании (Yahoo, Amazon) серъезно вкладываются в Erlang-разработку. Я уже от многих людей слышал, даже от сисадмина, далекого от программирования — типа «erlang это такой язык с крутой параллельностью». Сейчас какой-то hype пошел насчет ерланга.

На самом деле вызывает очень большое уважение то, как разработчики Erlang-а на протяжении больше чем 20 лет (разработка Erlang, если не ошибаюсь, началась в 1986) не изменяли своим идеям и не забросили свои наработки. Так что имеющийся сейчас hype и, может быть, некоторый over use, ими вполне заслужен -- они его долго ждали.

Что до вкладывания денег в Erlang разработки, так здесь, может быть, срабатывает тот же фактор, что и для RubyOnRails. На какой-то момент стало понятно, что существующие подходы к созданию определенного класса Web-приложений (для RoR -- это "бюджетные", мелкие сайты) не годятся, программистам нужно было что-то другое, заточенное под их конкретные нужды. Вот RoR и выстрелил. Erlang, насколько я понимаю, сейчас пытаются применять на другой стороне спектра Web-приложений -- больших, сильно нагруженных, с высокими требованиями к надежности и маштабируемости. Видимо, Ынтырпрайзный Java настолько задолбал многих, что люди пробуют новые подходы. И Erlang, который уже зарекомендовал себя в телекоме с высочайшими требованиями к отказоусточивости, надежности и масштабировании, выглядит вполне обоснованным выбором.

Нужно еще добавить сюда возросший в последнее время интерес к функциональному программированию. Мол очередной кризис в производстве ПО, существующие подходы (то бишь ООП) не катят, срочно нужна новая silver bullet. Да тут еще и multicore массовый на голову свалился, а отцы-основатели ФП говорят, что функциональный код изначально распаралелливается, и бла-бла-бла... И тут оказывается (сюрприз, сюрприз!), что Erlang, пожалуй, один из самых успешных функциональных языков. И что на Erlang-е написано чуть ли не больше, чем на всех остальных функиональных языках вместе взятых (один только объем Erlang-овского кода для AXD301 чего стоит -- 1.2 миллиона строк кода). Вот и появился hype.

Кё>А ведь в нем как в _языке_ ничего нет для параллельности, более того, другой язык + actors легко может быть более удобным, более быстрым и т.д. имея точно такую же «крутую параллельность». Любая система, реализующая эмуляцию actors на многоядерном процессоре, автоматически получит почти все преимущества Erlang.

Мне кажется, что Erlang вообще не задумывался как язык для обеспечения параллельности в смысле HPC или оптимальной загрузки многоядерных процессов. Архитектура его приложений, состоящих из тысяч (десятков или сотен тысяч) процессов, предназначена совсем для других целей -- надежность и отказоустойчивость любой ценой. И поэтому существуют обоснованные, на мой взгляд, сомнения, что системы на базе статически-типизированных языков (вроде C++/Eiffel или даже управляемых JVM/.NET) способны предоставить разработчикам такие же возможности по разбиению приложения на тысячи мелких процессов и горячему обновлению кода.

Кё>Копировать Erlang смысла точно нет — что там копировать?

Мне, в первую очередь, хочется позаимствовать оттуда идею контроля процессов друг за другом, и процессов супервизоров, осуществляющих контроль и перезапуск упавших процессов.

А вообще я считаю, что Erlang получился очень хорошим языком, заточенным под конкретные нужды -- server-side с отказоустойчивостью и горячей заменой кода. В этом как его достоинство, так и его проблема. А то, что для Erlang-а проблема -- это возможность для SObjectizer и аналогичных фреймворков:
— в C++ нельзя делать приложения, состоящие из десятков тысяч процессов. Зато можно делать приложения из десятков, сотен тысяч, а то и миллионов агентов;
— в C++ растрел памяти может привести к краху всего приложения, в Erlang-е это невозможно. Но, если C++ приложение написано нормально, то может оказаться вполне достаточным поддержки рестарта проблемных агентов (например, выпускающих наружу свои исключения);
— в C++ можно достичь очень высокой скорости работы, чего в Erlang не будет в принципе (разве что за счет переписывания каких-то кусков на C/C++);
— в C++ агентно-ориентированный фреймворк можно внедрить в уже существующее C++ приложение. При этом не потребуется переучивание разработчиков на новый язык и не потребуется изменение архитектуры приложения для встраивания в него интерпритатора Erlang-а;
— в C++ агентно-ориентированные фреймворки могут применяться для самого широкого спектра задач: начиная от мелких утилит, обслуживающих какой-нибудь подключеный к компьютеру девайс (SmartCard-ридер или GSM-модем), и заканчивая большими, распределенными телеком- или банковскими системами.

Так что копировать весь Erlang действительно нет смысла. А вот учесть его опыт и сильные стороны в C++ных разработках, имхо, необходимо.

Здравствуйте, eao197, Вы писали:

E>Так что по-отдельности, может быть, в Erlang-е и нет ничего выдающегося, зато как удачно выполненая компиляция разных идей, направленных на достижение вполне конкретных целей -- разработки отказоустойчивого ПО для телекома -- он выглядит весьма неплохо.

Да в общем-то, я полностью согласен. Erlang — удачная (на данный момент), практически полезная штука. Просто что-то во мне протестует, когда все эти успехи приписываются ерлангу. Они должны приписываться модели актеров. Это теоретическая разработка для исследования параллельных вычислений, созданная в 70-х годах, которая сейчас невероятно «выстрелила» в лице ерланга.

Но ерланг тут ни при чем. Люди должны говорить «надо сделать такую же параллельность, как на актерах», «надо обеспечить такую же надежность, как у актеров», тогда будет порядок. Увлечение ерлангом мне напоминает жадное хватание ржавой воды из-под крана, когда стоит подождать — и пойдет чистая. Не надо целиться в Erlang как в цель — надо перенять опыт и пойти дальше. Это не более чем первая удачная реализация, за которой будут и другие (теоретические поделки типа Act1 в расчет не берем).

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

Благодоря настойчивости и инициативе remark-a появилась Google-группа SObjectizer. Целью которой как раз является обсуждение вопросов разработка агентных систем вообще и следующей версии SObjectizer в частности.

Приглашаю всех, кому интересна какая-то из этих тем, присоединится к нашей группе (ну или просто заглянуть пару раз на огонек)

По поводу SObjectizer-5. Судя по тому, что SObjectizer-4 не вызвал большого интереса, что-то в его дизайне и воплощении оказалось неудачным. Поэтому я серьезно намерен пересмотреть идеи и архитектуру So5 так, чтобы он был более привлекательным для потенциальных пользователей. В связи с этим я приглашаю всех, кто хотел бы иметь в своем распоряжении фреймворк (в первую очередь C++ фреймворк) для agent-, concurrent- и, может быть, parallel-программирования, высказать свои пожелания, замечания и предложения. Либо здесь, либо в упомянутой выше SObjectizer.

Здравствуйте, Кодёнок, Вы писали:

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

Кё>Скажи, решена ли проблема контроля загрузки, и как?

Если тебе еще интересно, то некоторые идеи об организации контроля перегрузки агентов в SO5 обсуждаются в Google-группе: здесь и здесь.

А так же есть одна идея о контроле загрузки в SO4: здесь

Здравствуйте, alsemm, Вы писали:

A>Вопрос: проектом кто-нибудь пользуется, кроме разаботчиков?

Вот, сегодня нашел success story (совершенно независимый от меня ): Архитектура высокопроизводительной системы многоагентного моделирования. SObjectizer был использован для разработки фреймворка для многоагентного моделирования под названием ASF.