Another idea is to generate a "make_ref()" when you subscribe, and then you
can uniquely match on this reference on await, without requiring explicit
patterns.
However, even if the above is not possible and the await(pattern) is the
only solution, I don't think this is an approach we want to generally
encourage. As mentioned, there are assumptions that are true under testing,
and some corner cases, but not everywhere. :)
On Mon, Jan 24, 2022 at 6:30 PM Ben Wilson <benwilson...@gmail.com> wrote:
> For that purpose, I feel like:
>
> {:ok, %{pattern: [match, here]}} = Foo.await(item)
>
> would work right? Can you help me understand why the patterns themselves
> need to be passed to your `await` function?
>
> On Monday, January 24, 2022 at 12:09:56 PM UTC-5 mateus...@swmansion.com
> wrote:
>
>> 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 <
>>> andrzej.p...@swmansion.com> 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 hunter...@gmail.com
>>>> 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
>>>>> andrzej.p...@swmansion.com 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 elixir-lang-co...@googlegroups.com.
>>>> 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 elixir-lang-core+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/elixir-lang-core/7c574242-92da-4577-bbf3-88119153e966n%40googlegroups.com
> <https://groups.google.com/d/msgid/elixir-lang-core/7c574242-92da-4577-bbf3-88119153e966n%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 elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4LnFjNOsMqrJF%3D-pc1igj_yp25%3DWnzggB5LqNB2robE5Q%40mail.gmail.com.
