Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 07:43
  • May 15 19:10
  • May 14 18:45
    jhigginbotham64 starred actor-framework/actor-framework
  • May 13 08:57

    Neverlord on neverlord

    Merge branch 'topic/neverlord/m… (compare)

  • May 13 08:45

    Neverlord on neverlord

    Merge branch 'topic/neverlord/m… (compare)

  • May 13 08:16
    Neverlord labeled #1348
  • May 13 08:16
    Neverlord opened #1348
  • May 13 08:14

    Neverlord on neverlord

    Fix instance getters on the met… (compare)

  • May 13 07:40
  • May 12 17:35

    Neverlord on neverlord

    Set reuse-addr for Prometheus p… (compare)

  • May 12 15:29
    Neverlord commented #1343
  • May 12 15:05
    uentity commented #1343
  • May 11 18:50
    Neverlord commented #1343
  • May 11 17:45
    uentity commented #1343
  • May 11 11:25
    Neverlord unlabeled #1347
  • May 11 11:25
    Neverlord labeled #1347
  • May 11 11:25
    Neverlord unlabeled #1346
  • May 11 11:25
    Neverlord labeled #1346
  • May 11 11:25
    Neverlord unlabeled #1345
  • May 11 11:25
    Neverlord labeled #1345
Farafonov Alexey
@farafonov-alexey

Isn't this code supposed to check whether the error is an exit_reason?

Yes. Thank you!

Dominik Charousset
@Neverlord
👍
Farafonov Alexey
@farafonov-alexey
Get this compile error. Couldn't find out what is wrong. I'm not using caf::byte btw.
[build] ...MSVC\14.28.29333\include\xmemory(701,82): error C2440: 'initializing': cannot convert from 'const caf::byte' to '_Objty'
[build]           with
[build]           [
[build]               _Objty=unsigned char
[build]           ]
Farafonov Alexey
@farafonov-alexey
Figured out the cause of error new_data_msg.buf has custom type byte_buffer, that is vector of caf::byte
Quang Huy Nguyen
@Qhuy1605_twitter

did you do ./configure --prefix=$PWD/build in the beginning?

Hi, i have tried but this error still occurs :(

Dominik Charousset
@Neverlord
Can you share what steps you've taken? Git checkout, configure arguments, etc. The CMake output looks weird, like something messed with the folders.
Dominik Charousset
@Neverlord
Maybe just deleting the build directory and doing a clean build would already help.
Quang Huy Nguyen
@Qhuy1605_twitter

Can you share what steps you've taken? Git checkout, configure arguments, etc. The CMake output looks weird, like something messed with the folders.

Hi Dominik, i just downloaded the source code from git, and ran ./configure without arguments (like the document on git).

Quang Huy Nguyen
@Qhuy1605_twitter
Nevermind, i have already fixed it. Thank you!
ferjif
@ferjif
Hey. I was searching on logging in caf but couldn't find any examples. not even in the examples folder of caf's github. can anyone help me on how to do it
Dominik Charousset
@Neverlord
You basically need to build CAF with logging enabled. Either by passing --log-level=... to the configure script or by setting CAF_LOG_LEVEL directly when using CMake. Maybe this article here is of some use: https://www.cafcademy.com/gems/indenting-trace-logs
Christian C.
@DrDeadbrain
Hey I have a question about Message Handling when using Group Communication. Do all group member have to handle all messages that are published inside the group? At the moment I'm only have returns for messages that I want to handle with the specific group member but I'm getting a lot of unexpected message errors that seem to terminate my members.
If I have to handle every message what is the best way to handle them without publishing a new message to the group?
Thanks in advance
Dominik Charousset
@Neverlord
Yes, all subscribers have to handle all messages on the group. If you respond to a group message, everyone in the groups receives the response. You can either add matching handlers to all subscribers or add a default handler to silently discard messages you didn't expect. But beware of the risk, since doing this can lead to very hard-to-debug errors down the road.
Christian C.
@DrDeadbrain
Alright. Thanks for your fast reply!
Cem Degirmenci
@sputnikcem_twitter
is it possible to do something like .add<std::map<int,std::vector<int>>>(port_list, "port-list,p", "portlist"); in the config?
I get some empty list but don't know if I do something wrong or if it is not possible at all
Cem Degirmenci
@sputnikcem_twitter
ah my mistake, we need curly braces for the map
in the configuration file
ferjif
@ferjif
Hey Guys
I recently updated my caf from 0.17.6 to 0.18.5
then realized that custom atoms cause core dump
i searched every where but nothing comes up
Noir
@josephnoir
The atom implementation changed with 0.18. The "Atoms" section in the manual explains how to use them: https://actor-framework.readthedocs.io/en/stable/MessageHandlers.html#atoms They are defined in the type id block of your application. (Don't forget to load it, e.g., like this).
Yifei Yang
@Yifei-yang7
Hey I also updated from 0.17.6 to 0.18.5, and found caf::message_view is not an api anymore, may I know its alternative?
Dominik Charousset
@Neverlord
@Yifei-yang7 there isn't an analog in the new implementation since the entire type_erased_tuple-API has been cut out.
Yifei Yang
@Yifei-yang7
got it, thx! Is it possible to remote_spawn actors with detached option? Is it achievable by adding it into make_massage()?
Yifei Yang
@Yifei-yang7
or is it possible to change the api of add_actor_type to let spawn_option in? cause I found add_actor_type specifies no_spawn_option internally
Dominik Charousset
@Neverlord
The message only wraps the constructor arguments. Doesn't seem like there's an API for that at the moment.
Feel free to make a feature request on GitHub. :)
Yifei Yang
@Yifei-yang7
Thanks! I will make one for that. :)
Dominik Charousset
@Neverlord
👍
Rich Henry
@phaistos
im having the same issue as @ferjif above, i core dump whenever i try to use an atom defined with the new API, im following the pattern in the documentation
Dominik Charousset
@Neverlord
Are you passing your type IDs to CAF_MAIN or call init_global_meta_objects?
Rich Henry
@phaistos
fixed, thanks a lot
i didnt see any discussion of that method, or the passing of arguments in the docs, but i didnt read them very closely either
and on closer inspection i see it
Dominik Lohmann
@dominiklohmann
If I have an actor behavior that takes a parameter by reference, would it theoretically be safe to store that reference elsewhere if I also manually keep a reference count to the current message as long as I keep the reference? How would I go about getting a strong reference to the current message from a "self" pointer?
Dominik Charousset
@Neverlord
self->current_mailbox_element()-> payload gives you the message in a handler. Keeping a reference/pointer into that message is only safe for read-only access because you otherwise break COW (changing a tuple with ref count > 1).
Dominik Lohmann
@dominiklohmann
It is for read-only access purposes, thanks! Not sure if you've seen my discussion comment regarding coroutines w/ CAF result (open to chat about it any time!), but I kind of need to extend the current message lifetime until the coroutine frame is destroyed because by-reference function parameters are only stored by-reference in the coroutine frame.
Dominik Charousset
@Neverlord
I've seen the notification, I'll get back to that if I can make the time. Are you still on 0.17? In that case it's a bit more complicated. Because in 0.17 CAF can fuse the content into the mailbox element itself. You could do something like self->current_mailbox_element()->move_content_to_message() to have something to hold onto.
But that of course invalidates the original reference.
Dominik Lohmann
@dominiklohmann
Yeah we sadly still are. The upgrade had to move back due to limited engineering resources. We still have some stuff serialized with the caf::binary_serializer, and the output of that changed between 0.17 and 0.18, so we're in the process of transitioning our database state in a forward-compatible way.
Invalidating the original reference is not a problem as I need to have a lifting function around every behavior callback anyways, I can move it in there. Thanks!
Dominik Charousset
@Neverlord
Depending on how long the migration goes, maybe you can skip 0.18 entirely and jump to 0.19. ;)
Good luck!
Dominik Lohmann
@dominiklohmann
Probably another 1-3 months, depending on customer needs :)
Dominik Lohmann
@dominiklohmann

Totally separate question:

self->set_down_handler(...);
auto handle = self->spawn<caf::monitored>(my_typed_actor, args...);
typed_actor<...>::behavior_type my_typed_actor(typed_actor<...>::pointer self, Args... args) {
  if (!validate(args...)) {
    self->quit(make_error(...));
    return typed_actor<...>::behavior_type::make_empty_behavior();
  }
  return {
    // ... 
  };
}

If the validation inside the my_typed_actor function fails the down handler will never be triggered, despite the actor shutting down correctly. Is this a bug, or are we simply abusing the API here?

Dominik Charousset
@Neverlord
I'd say it should trigger down messages. Do you have a minimal example that reproduces this?
Dominik Lohmann
@dominiklohmann
I'll open a PR with a unit test, assuming it still fails with 0.18 you can take it from there.
Dominik Charousset
@Neverlord
👍