Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
Dominik Charousset
@Neverlord
Since the sensors trigger at different rates, the most simple solution would be having something like map<strong_actor_ptr, value_type> and run the algorithm whenever you have three entries after receiving something (and override the entry for the sender otherwise).
newjames1988
@newjames1988
simply waiting for three messages or by looking at the sender for each message (this way, a sensor that triggers twice for whatever reason could 'override' its previous input and wouldn't be mistaken for the input for another sensor). I will try to use this .
thanks for reply
Dylan Baros
@dylan-baros
Good morning. Is there anyone here who could assist with a windows install? I run cmake .. in the build folder and the project files are all built in the root directory. I then go to the root directory and run cmake --build . and everything seems to build but If I try to run any of the examples .exe files they can't find any of the dlls.
Dominik Charousset
@Neverlord
I suppose you figured it out yourself? actor-framework/actor-framework#1354 :)
If you don't want to deal with shared libraries in the first place and prefer statically linked binaries, you can set --disable-shared-libs (configure script) or BUILD_SHARED_LIBS=OFF (CMake).
Dylan Baros
@dylan-baros
@Neverlord yes thanks. I have never played with windows libraries before but figured out.
Marco Leclerc
@ke9
Hi all, need some help/clarification regarding message_priority before I fill an issue in github. Let's say I send a bunch of high priority messages to an actor, and then a normal priority message... is it by design that a normal priority message will be processed before all high priority messages already in the actor's mailbox? From the documentation: "Urgent messages are put into a different queue of the receiver’s mailbox", I would expect that all queued high priority messages be processed before any new messages are sent to an actor. It used to work in the past (don't remember how long ago), some of our unit tests are failing now with CAF 0.18.5 . thanks for any help/hints !
Dominik Charousset
@Neverlord
@ke9 Actors draw from both queues. They first check the high-priority queue and consume messages up to a maximum. Then they look into the default queue, again consuming up to a maximum of messages. Rince and repeat. Actors will consume more messages from their high-priority queue overall, but the reasoning here is to avoid scenarios where an actor would make no progress at all on its regular messages for a long time if there's a burst of high-priority messages coming in.
Marco Leclerc
@ke9

@Neverlord Hi thanks for the clarification, makes sense to give actor the chance to process all messages, we do the same at a higher level. We will adapt our design accordingly. Would be interesting to document this behavior a little bit in the user manual. On my test (windows box, x64 release) , I send a bunch of high priority messages, then a bunch of normal priority messages and the actor eventually processes 9 high priority messages for 3 normal priority messages (3 to 1 ratio), until the test finishes.
caf::message_priority::high : 1444419
caf::message_priority::normal : 3
caf::message_priority::high : 9
caf::message_priority::normal : 3
caf::message_priority::high : 9
caf::message_priority::normal : 3
caf::message_priority::high : 9
caf::message_priority::normal : 3

Have a nice day!

Dominik Charousset
@Neverlord
Yeah, the docs should definitely mention that! Have nice day as well. 🙂
Dylan Baros
@dylan-baros

I am having an issue where my project builds on linux but does not build on Windows with cmake. Here is the error:

[main] Building folder: POC
[build] Starting build
[proc] Executing command: C:\src\vcpkg\downloads\tools\cmake-3.24.0-windows\cmake-3.24.0-windows-i386\bin\cmake.EXE --build c:/Users/dbaros/Documents/POC_example/POC/build --config Debug --target ALL_BUILD -j 6 --
[build] MSBuild version 17.3.1+2badb37d1 for .NET Framework
[build] duck_classes.vcxproj -> C:\Users\dbaros\Documents\POC_example\POC\build\source\DuckClasses\Debug\duck_classes.lib
[build] libcaf_core.vcxproj -> C:\Users\dbaros\Documents\POC_example\POC\build_deps\caf-build\libcaf_core\Debug\caf_core.lib
[build] main.cpp
[build] C:\Users\dbaros\Documents\POC_example\POC\build_deps\caf-src\libcaf_core\caf/mixin/sender.hpp(73,19): error C2338: static_assert failed: 'at least one type has no ID, did you forgot to announce it via CAF_ADD_TYPE_ID?' [C:\Users\dbaros\Documents\POC_example\POC\build\source\DuckParty\DuckParty.exe.vcxproj]
[build] C:\Users\dbaros\Documents\POC_example\POC\source\DuckParty/DuckActor.h(32): message : see reference to function template instantiation 'void caf::mixin::sender<B,D>::send<caf::message_priority::normal,DisplayActor,const display_behavior&,std::chrono::time_point<std::chrono::system_clock,std::chrono::duration<std::chrono::system_clock::rep,std::chrono::system_clock::period>>&,std::string&>(const Dest &,const display_behavior &,std::chrono::time_point<std::chrono::system_clock,std::chrono::duration<std::chrono::system_clock::rep,std::chrono::system_clock::period>> &,std::string &)' being compiled [C:\Users\dbaros\Documents\POC_example\POC\build\source\DuckParty\DuckParty.exe.vcxproj]
[build] with
[build] [
[build] B=caf::scheduled_actor,
[build] D=caf::typed_event_based_actor<caf::result<void> (do_duck_behavior)>,
[build] Dest=DisplayActor
[build] ]
[build] C:\Users\dbaros\Documents\POC_example\POC\source\DuckParty/DuckActor.h(32): message : see reference to function template instantiation 'void caf::mixin::sender<B,D>::send<caf::message_priority::normal,DisplayActor,const display_behavior&,std::chrono::time_point<std::chrono::system_clock,std::chrono::duration<std::chrono::system_clock::rep,std::chrono::system_clock::period>>&,std::string&>(const Dest &,const display_behavior &,std::chrono::time_point<std::chrono::system_clock,std::chrono::duration<std::chrono::system_clock::rep,std::chrono::system_clock::period>> &,std::string &)' being compiled [C:\Users\dbaros\Documents\POC_example\POC\build\source\DuckParty\DuckParty.exe.vcxproj]
[build] with
[build] [
[build] B=caf::scheduled_actor,
[build] D=caf::typed_event_based_actor<caf::result<void> (do_duck_behavior)>,
[build] Dest=DisplayActor
[build] ]
[proc] The command: C:\src\vcpkg\downloads\tools\cmake-3.24.0-windows\cmake-3.24.0-windows-i386\bin\cmake.EXE --build c:/Users/dbaros/Documents/POC_example/POC/build --config Debug --target ALL_BUILD -j 6 -- exited with code: 1 and signal: null
[build] Build finished with exit code 1

Any help would be appreciated
I give the types IDs and it works on linux.
Dominik Charousset
@Neverlord

There's not enough context to tell what's going wrong on MSVC. The static assert usually triggers when forgetting some includes, but that wouldn't explain why it worked for you on Linux.

Btw, if you're evaluating CAF on Windows: there's a performance issue that's been fixed recently actor-framework/actor-framework#1343.

Dylan Baros
@dylan-baros
@Neverlord thanks. So this is likely an include issue? Is there a difference between how the includes are handled on linux and windows?
Dominik Charousset
@Neverlord
It usually is a matter of not having the type ID block visible, but hard to tell without code.
Dylan Baros
@dylan-baros
I inherited this code so pardon my ignorance, but here is what they did, They used CAF_ADD_ATOM:
CAF_BEGIN_TYPE_ID_BLOCK(duck_msg_types, caf::first_custom_type_id)
CAF_ADD_ATOM(duck_msg_types, do_duck_behavior)
CAF_ADD_ATOM(duck_msg_types, display_behavior)
CAF_END_TYPE_ID_BLOCK(duck_msg_types)
Dylan Baros
@dylan-baros
@Neverlord I did not realize that you actually have seen this code before. I work at National Instruments where you have provided some support for a CAF based project. I posted my repo and question on stackoverflow and if you get a chance to look at it I would appreciate it. https://stackoverflow.com/questions/73901792/cant-compile-code-using-the-c-actor-framework-on-windows-using-cmake-works-o
patszt
@patszt

What is the proper syntax to pass std::vector<std::string> CLI arguments in 0.18.6?

--some-list-option=[\"a\"]

seems to work, but when i try to add the second entry
--some-list-option=[\"a\", \"b\"]
it fails with pec::invalid_argument.

This syntax is used in test/config_option_set.cpp

Used to work with just --some-list-option=a,b in 0.17.6
Dominik Charousset
@Neverlord
@dylan-baros I'll take a look over the weekend.
@patszt On the shell, you often have the problem that the shell is eating up the quotes. Did you try passing something like my_app '--my-list=["a", "b"]'?
1 reply
(note the single quotes around the whole --my-list argument)
Alexander Gagarin
@uentity
@Neverlord what's the expected timeframe for CAF 0.19 release?
Dominik Charousset
@Neverlord
@uentity working on the last major feature as we speak. :)
Plan is to release the first RC end of october.
Alexander Gagarin
@uentity
nice )
Dominik Charousset
@Neverlord
If you wanna keep track: https://github.com/actor-framework/actor-framework/milestone/18. #1347 is the last "big" feature.
Alexander Gagarin
@uentity
thanks for info!
Dominik Charousset
@Neverlord
Don't mention it. Sorry for the delay, originally, we've targeted mid-2022 for 0.19. But, you know how it is.. ;)
Alexander Gagarin
@uentity
@Neverlord perfectly know ) and you did amazing amount of work
Dominik Charousset
@Neverlord
Much appreciated, but it's not just me. 🙂
Even if most commits come from me at the moment, it wouldn't happen without discussions, feedback and testing from others that happens "behind the scenes".
Alexander Gagarin
@uentity
of cause, credits to all the team ) I see a lot of new API and useful features like websockets, etc. Fingers crossed it will be documented or described in articles =)
Dominik Charousset
@Neverlord
Yeah, the best feature is worth nothing without documentation. 😄
patszt
@patszt

@dylan-baros I'll take a look over the weekend.
@patszt On the shell, you often have the problem that the shell is eating up the quotes. Did you try passing something like my_app '--my-list=["a", "b"]'?

This works :) Thanks

Dominik Charousset
@Neverlord
👍
patszt
@patszt
void foo(typed_actor parent) {  
  auto spawned = parent->spawn(new_actor);
  parent->request(std::move(spawned), int{5}).then([]{});
}
is such function legal? It seems to me that the spawned actor may die and "then" will never be called. Is the lifetime somehow preserved here or are my worries justified?
Dominik Charousset
@Neverlord
The spawned actor won't terminate as long as there are still references to it. And it has a reference as long as it has messages in its mailbox. So this is fine.
patszt
@patszt
What if the request returns a not delivered promise? So we create a response_promise in the only message the spawned received. The response_promise is part of spawned state and we return it to response handle. Is the ref_count now 2? What happens to the response_handle once we exit this scope?
Dominik Charousset
@Neverlord
I don't understand what you are trying to say with "not delivered promise". The promises are actor-local and must not be visible outside of an actor. If an actor terminates before it fulfills a promise, it'll trigger a broken promise error message.
patszt
@patszt
Okay so the promise cannot be returned from the message handler?
But generally the request to spawned is supposed to create response_promise -> request to other actors- > deliver the promise once all actors respond to previous requests
Dominik Charousset
@Neverlord
The promises are a way to allow actors to respond at some later time to an input message. You can "return" a promise, but this only tells CAF to suppress the response message as the actor eventually sends one later.
patszt
@patszt
And it seems that by the end of foo function scope there is nothing to keep spawned alive. Is my assumption correct? I know that capturing spawned in the "then" clause should guard against it
Dominik Charousset
@Neverlord
Well, if you send a message, this message has a reference to its sender. So if your actor sends the message immediately, it'll live long enough to get the response message.
Did you look at https://github.com/actor-framework/actor-framework/blob/master/examples/message_passing/promises.cpp already? You could also spawn the worker in server_impl, which sound like a good approximation what you're trying to do?
Dominik Lohmann
@dominiklohmann

IIUC @patszt's problem correctly then the problem actually occurs when you return the response handle from his example function, because the response handle does not keep a strong reference to the destination actor. We ran into this when upgrading from CAF 0.17 to CAF 0.18 (yes we're finally getting to it), and were wondering if this was a change in behavior. The behavior we see is that a .then(...) on the response handle returned from this function was always replied to with a caf::sec::broken_promise. The requested handler of the destination actor always created a response promise.

Do you know if it's feasible to backport the CAF 0.18 response promise to CAF 0.17 to make this part of the transition easier?

Dominik Charousset
@Neverlord

What is the "destination actor" in your case? Let's say we have a communication pattern like A -> B -> C. A sends a request to B. B sends another request to C, holding onto a response promise. C responds normally.

B has a response promise, which holds a strong_actor_ptr back to A (https://github.com/actor-framework/actor-framework/blob/master/libcaf_core/caf/response_promise.hpp#L201). C has a message in its mailbox, so CAF should hold an implicit reference to it at least until it has responded. That's how I understand it. Where are my assumptions wrong?

Dominik Lohmann
@dominiklohmann
Consider this:
auto foo(event_based_actor* a) {
  auto b = a->spawn(B);
  return a->request(b,...); // uses a response promise
}

auto bar(event_based_actor* a) {
  foo(a).then(...); // always receives sec::broken_promise
}
This is essentially what we've encountered with CAF 0.18, and that same code worked fine in CAF 0.17, so we were wondering if anything changed in that regard.
Dominik Charousset
@Neverlord
So, A and C are long-lived and B only exists for the request? Let me see if I can reproduce B terminating in this case. This shouldn't fail with broken_promise from my understanding, because the message in C should keep B alive (first the request message in the mailbox of C itself and then of course the response message in B).
Dominik Lohmann
@dominiklohmann
There is no C in this at all, at least not in our example. It's just A and a short-lived B, where the response handle to the request to B outlives B and B uses a response promise for the request, and that causes us to receive a broken promise error in A when calling .then on the response handle.