> Can you help me understand why the patterns themselves need to be passed
to your `await` function?
Because that way you can't `await` for a particular pattern ;) For example,
we have a concept of playback states. One could need to wait until the
playback state changes, so they could do
`await(pipeline, playback_state)`
and they would have the new playback state under the `playback_state`
variable. But if they wanted to wait for a particular playback state, like
`:playing`, they could do
`await(pipeline, :playing)`
I feel that would be a flexible way of handling scenarios when one needs to
wait for a particular event. Anyway, I see two separate issues here
- The concept of waiting for a particular message by wrapping a receive
block - like `Task.await`, `GenServer.call`
- Unpacking variables from a pattern passed to a macro - which is the
problematic part here and as far as I understand it's not the Elixir way -
in that case, we'll figure out something else, as it's definitely not worth
going against the standards ;)
poniedziałek, 24 stycznia 2022 o 18:47:47 UTC+1 José Valim napisał(a):
> 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 <benwil...@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-co...@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/03051bbf-ef21-4f27-96f3-6232b146df39n%40googlegroups.com.
