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 [email protected]
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 <
>> [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/7c574242-92da-4577-bbf3-88119153e966n%40googlegroups.com.
