Что-то мне кажется там ни в лямбда проблемы. Аноним прав там текст похож на «как нарисовать сову». Вообще писать годные доки - та еще наука.

Аноним прав там текст похож на «как нарисовать сову»

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

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

Боюсь, здесь такая же дилемма, как при обучении современному C++. Некоторые считают, что лучше показывать динамические массивы новичкам вот так:

int * data = new int[capacity];
...
delete[] data;

std::vector<int> data(capacity);
...

std::unique_ptr<int[]> data(new int[capacity]);
...

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

Нет, это глупость. Всему место на своем месте. Оке, инструмент большой, серьезный и очень может быть что не для хелоуВорлд. Но мне, например, хватило дня, чтобы осилить Spirit (boost). И не скажу что это мелкая херовиннка. Там просто дока написана хорошо. И как ни странно начинается с простейшего калькулятора. А паче вскипятить триф тоже не 2 строчки поделка, протобуфер тоже не маленький.однако в них быстро включаешь.

Нет, это глупость. Всему место на своем месте.

Не понял, к чему это было сказано.

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

Вот для вас лично вариант примера, предложенный здесь, понятен?

Я кста понял чего не хватает и в чем претензии, кроме мешанины кода. Схем там не хватает. Даже в доке по CAF есть схемки и таблицы, которые некоторые моменты просто очевиднее длают.

Вот для вас лично вариант примера,

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

Схем там не хватает.

Где, например, вам бы хотелось видеть пояснение в виде схемы в описании SO-5?

И еще интересно: такого рода презентация лучше рассказывает о SObjectizer-е, чем Basics в Wiki или нет?

Как надо писать? Критикуя - предлагай!

Есть мысль к релизу очередной версии подготовить в Wiki еще один раздел, который бы предшествовал секции Basic. Что-то в духе «A Brief Introduction for Old-Schoolers» где самые основные вещи показывались бы буквально на пальцах, в рамках простого примера. Но не HelloWorld и не PingPong-а, а чего-нибудь более интересного.

Есть одна мысль на счет примера, но есть и подозрение, что пример опять получится простым только для тех, кто с SO-5 уже знаком. Все-таки четыре типа агентов, плюс диспетчер с активными объектами... В общем, функция main там выглядит вот так:

int main()
{
	so_5::wrapped_env_t sobj;

	auto coop = sobj.environment().create_coop( "data_example" );

	coop->make_agent< data_printer >();
	coop->make_agent< alarm_checker >();

	auto calibrator = coop->make_agent< data_calibrator >();

	auto ao_disp = so_5::disp::active_obj::create_private_disp(
			sobj.environment() );

	coop->make_agent_with_binder< raw_data_reader >(
			ao_disp->binder(),
			0, calibrator->so_direct_mbox() );

	coop->make_agent_with_binder< raw_data_reader >(
			ao_disp->binder(),
			1, calibrator->so_direct_mbox() );

	coop->make_agent_with_binder< raw_data_reader >(
			ao_disp->binder(),
			2, calibrator->so_direct_mbox() );

	sobj.environment().register_coop( std::move(coop) );

	std::this_thread::sleep_for( std::chrono::seconds(5) );
}

Три из четырех типов агентов очень простые, что-то вроде:

class alarm_checker : public so_5::agent_t
{
public :
	alarm_checker( context_t ctx )
		:	so_5::agent_t{ ctx }
	{
		so_subscribe( ctx.environment().create_mbox( "data" ) )
			.event( &alarm_checker::check_data_event );
	}

private :
	void check_data_event( const data_sample & s )
	{
		if( s.m_value > 11.5f )
			initiate_alarm( s.m_io_port, s.m_value );
	}
};

Самый сложный агент вот такой:

class raw_data_reader : public so_5::agent_t
{
	struct read_value : public so_5::signal_t {};

public :
	raw_data_reader( context_t ctx, int io_port, so_5::mbox_t calibrator )
		:	so_5::agent_t{ ctx + limit_then_drop< read_value >(1) }
		,	m_io_port{ io_port }
		,	m_calibrator{ std::move(calibrator) }
	{
		so_subscribe_self().event< read_value >(
				&raw_data_reader::read_value_event );
	}

	virtual void so_evt_start() override
	{
		m_read_value_timer = so_5::send_periodic< read_value >( *this,
				std::chrono::milliseconds::zero(),
				std::chrono::milliseconds( 100 ) );
	}

private :
	so_5::timer_id_t m_read_value_timer;
	const int m_io_port;
	const so_5::mbox_t m_calibrator;

	void read_value_event()
	{
		const auto v = read_raw_value( m_io_port );
		so_5::send< raw_data_sample >( m_calibrator, m_io_port, v );
	}
};

Собственно, вопрос: пойдет ли такая сложность? Или это перебор и нужно что-то попроще?

«A Brief Introduction for Old-Schoolers»

Причем тут вообще олдскулерс?

Ты вот видел доку по спириту? тот что из буста? Вот представь, что было бы, еслиб дока была в духе:

Вот значит у нас так парсится double_

// the following parses "1.0 2.0" into a pair of double
std::string input("1.0 2.0");
std::string::iterator strbegin = input.begin();
std::pair<double, double> p;
qi::phrase_parse(strbegin, input.end(),
    qi::double_ >> qi::double_,       // parser grammar 
    qi::space,                        // delimiter grammar
    p);                               // attribute to fill while parsing

А вот так значит мы парсим протокол http, попутно выполняя JS и проверяя на наличие багов в его коде

...трешЪ, адЪ, содомия

ну и ктоб им пользовался вообще?

Причем тут вообще олдскулерс?

При том, что рядом будет такая же секция, но для тех, у кого глаза не текут при виде C++ных лямбд и где этот же пример записывается в другом ключе.

Ты вот видел доку по спириту?

Не понимаю, какое отношение имеет документация к Boost.Spirit к попытке сделать документацию к SO-5 более понятной для новичков. Тот же пример с парсингом вещественных значений он где дан? Он дан здесь. А до этого идет очень немало вводного текста, рассказывающего базовые вещи. Но при этом ориентированного на людей, которые про парсинг и грамматики хотя бы представление имеют. И знают, когда нужны генераторы парсеров.

С SO-5 ситуация несколько иная. Далеко не многие в мире C++ знают про Actor Model вообще. Многие не знают, про то, что многопоточные приложения можно писать с использованием асинхронного обмена сообщениями. И т.д. и т.п. Хотя на форумах, как обычно, тусуются эксперты, которые знают вообще все. Забывая, однако, что они не большинство.

Документация к SO-5 в Wiki писалась по такому принципу: в Basic дается описание самых базовых вещей. Мол есть то-то и то-то, используется так-то и так-то. Далее есть набор секций so-5.5 By Example, в каждой из которых на примере разбирается как, зачем и почему используется та или иная фича. Далее есть набор секций so-5.5 In Depth, где отдельная фича рассматривается более подробно.

Т.е. идея была такая — смотришь в Basic, получаешь общее представление, просматриваешь несколько секций By Example, понимаешь как этим пользоваться. В In Depth заглядываешь когда нужно разобраться более детально.

Судя по всему, такой подход не сработал. Отсюда вопрос: как это исправить?

Возможный вариант: дополнительная секция Introduction for..., которая на небольшом примере покажет для чего SO-5 и как его использование может выглядеть.

Но нужно понять, этот вариант может сработать или нет. Если нет, то почему?

Вышла версия 5.5.13

SObjectizer обновился до версии 5.5.13. Подробности релиза можно узнать здесь. Сорри, что не выкладываю краткого описания изменений. Надеюсь, что тем, кто проектом интересуется, не составит труда пройти по ссылке и прочесть нормальное описание релиза.

охтыж. А я думал оно header-only.

А я думал оно header-only.

Это настолько критично?

да нет в принципе. Зашел, почитал тему, думал - дай гляну жастфофан, а тут собирать надо, да еще и зависимостями, брр...

Какие зависимости? Если возьмете готовый zip, то там внутри уже все есть.

v.5.5.14, overload control через mchain и планы на ближайшее время...

За последнее время:

• состоялся релиз версии 5.5.14, в которой произведена унификация форматов разных типов обработчиков сообщений;
• подготовлен пример, показывающий, как механизм mchain может использоваться в механизмах overload control для агентов;
• более-менее обозначились планы на ближайшее будущее:
  • подготовка презентации об опыте использования SObjectizer-а и извлеченных из этого опыта уроках;
  • эксперименты по интеграции SObjectizer-а в GUI-приложения посредством использования механизма mchain-ов;
  • подготовка еще одной, может быть двух, презентаций для серии Deep Dive into SObjectizer-5.5. По крайней мере нужно рассказать подробнее о диспетчерах. Ну и об mchain-ах, если получится;
  • проработка двух больших фич для следующих версий SO-5: возможность представления агентов в виде иерархических конечных автоматов (с историческими состояниями, с реакциями на вход-выход и т.д.) и возможность использования в диспетчерах преаллоцированных буферов в качестве очередей сообщений (при этом экземпляр сообщения не создается динамически, как сейчас, а конструируется in-place в буфере диспетчера). Имхо, фичи очень важные, особенно для определенных классов задач. Но пока понятные лишь в общих чертах. Так что здесь еще над чем подумать.

Собственно говоря, если у кого-то есть вопросы/замечания/предложения, то сейчас удобный момент для того, чтобы уделить этому какое-то время. Так, если вам что-то не нравится в SO-5 или чего-то сильно не хватает и вы найдете возможность об этом сказать, то ваши пожелания вполне могут быть учтены в ближайших релизах SObjectizer-а.

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

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

Пока получается как-то вот так: пример из первого работающего варианта. Конечный автомат, который там реализуется, приблизительно вот такой

В SO-5.5.15 будет возможность задавать ограничение по времени пребывания агента в конкретном состоянии. А так же отменять это ограничения. Но не станет ли поведение связки методов time_limit/drop_time_limit неприятным сюрпризом для пользователей? Интересны любые мнения.

Пока получается как-то вот так: пример из первого работающего варианта. Конечный автомат, который там реализуется, приблизительно вот такой

В продолжение темы: маленькая демонстрация еще одной прикольной штуки, которая есть в продвинутых конечных автоматах — состояния с историей.