Hi there, we're preparing a message-based API as well, so one can use `receive` or `handle_info` when needed. However, we expect that functionality to be used mostly in elixir scripts/livebooks, where `await` is going to cover the majority of cases, saving us from having `receive` blocks everywhere. It can be also compared to `Task.await`, which has similar problems to what you described, yet it proves useful in particular situations. Another point is that extracting variables from a match can be used in many other scenarios and currently it requires hundreds of lines of code to implement properly AFAIK :P
Regards, Mateusz poniedziałek, 24 stycznia 2022 o 14:56:55 UTC+1 José Valim napisał(a): > Honestly, I am not sure if it is worth encapsulating the event as you > propose compared to a receive. For example, what happens if you want to > receive at least one message from two distinct pipelines? What happens if > you are inside a GenServer, where any receive pattern can be harmful and > handle_info should be preferred? > > The main reason "assert_receive" exists is not because of the convenience, > but rather the improved error message. And those scenarios are less common > too (at least you are not running a test inside a GenServer). > > On Mon, Jan 24, 2022 at 2:50 PM Andrzej Podobiński < > [email protected]> wrote: > >> Hi, >> thanks for your interest! I'm working on a specific pipeline in the >> Membrane framework. The API of this pipeline allows the user to subscribe >> for events that this pipeline emits, and then synchronously wait for these >> events. The idea is to provide a macro that wraps the receive block to make >> waiting for the event nicer to the user - just like assert_receive. >> >> https://github.com/membraneframework/membrane_core/blob/remote-controlled-pipeline/lib/membrane/remote_controlled/pipeline.ex#L55 >> ps. I'm aware that the current implementation of "await" I've linked >> won't work because of e.g. lack of macro expansion. >> niedziela, 23 stycznia 2022 o 18:58:14 UTC+1 [email protected] >> napisał(a): >> >>> Hi, >>> >>> I'm wondering what sort of code you're trying to write where a receive >>> ... after block wouldn't work well in this situation. Furthermore what do >>> we do in the error case if the receive times out? For ExUnit this is quite >>> simple: the test fails, but in your application code this doesn't mean >>> anything. If you get to the point that you're specifying control from with >>> this new macro then you've just recreated receive with more steps. Could >>> you provide some code samples for what you're trying to achieve? >>> >>> Best, >>> Theron >>> On Thursday, January 20, 2022 at 9:22:43 AM UTC-6 >>> [email protected] wrote: >>> >>>> Lastly, I was trying to implement a macro with similar functionality as >>>> assert_receive from ExUnit. The purpose of this macro was to allow the >>>> user >>>> to wait synchronously for a message specified by a pattern. The given >>>> pattern may contain variables that the user is interested to extract from >>>> the arrived message (exactly as in ExUnit.assert_receive). I've noticed >>>> that there is a significant amount of code that expands the given pattern >>>> and then collects the variables from it etc. in order to properly extract >>>> variables from the pattern. I have a feeling that it is not a valid >>>> solution to use an ExUnit.assert_receive in the production code, so maybe >>>> it would be possible to add the function of similar functionality to the >>>> Process module. Something like Process.await_message(). Another possibly >>>> better solution could be adding some functionality to the Macro module >>>> that >>>> would cover expanding the macro and collecting variables etc. ( >>>> https://github.com/elixir-lang/elixir/blob/a64d42f5d3cb6c32752af9d3312897e8cd5bb7ec/lib/ex_unit/lib/ex_unit/assertions.ex#L467 >>>> ) >>>> >>>> -- >> You received this message because you are subscribed to the Google Groups >> "elixir-lang-core" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/elixir-lang-core/86836f06-f926-42de-aed0-9576d836b61cn%40googlegroups.com >> >> <https://groups.google.com/d/msgid/elixir-lang-core/86836f06-f926-42de-aed0-9576d836b61cn%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/670740e7-aa51-41d8-af2d-4090f47802e4n%40googlegroups.com.
