You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, I think slurry is good for my use case, but I cannot tell for sure, because there are not enough examples of using the various parts of the library in combination.
I would particularly like to know:
the best way to have a pipeline take input from a Trio memory channel
the best way to have a pipeline tap output into a Trio memory channel
how to enable/disable sections of a pipeline on the fly
The text was updated successfully, but these errors were encountered:
Hi! Thanks for taking a look at slurry. I agree that there isn't enough examples. I will keep this issue open, as a reminder to expand the documentation in this regard.
In the meantime, I can provide you with these simple examples:
A pipeline takes any async iterable as input. Since a trio memory channel is an async iterable, it can be used as an input directly.
When feeding an output to a memory channel, create a new tap, iterate it and use memorychannel.send() to send it along. Keep in mind also, that a tap is actually a trio MemorySendChannel, underneath the hood, and can be treated as such, meaning instead of iterating it, you can call receive on it, if you like that pattern better.
asyncwithPipeline.create(
Map(lambdax: x+1, receive)
) aspipeline, pipeline.tap() astap:
asyncforitemintap:
awaitmymemorychannel.send(item)
### This is equivalent to -asyncwithPipeline.create(
Map(lambdax: x+1, receive)
) aspipeline, pipeline.tap() astap:
whileTrue:
awaitmymemorychannel.send(awaittap.receive())
There is no direct way to enable or disable subsections of a pipeline. However there is a possible solution, which is to rewire the pipeline dynamically at runtime, using the pipeline.extend() method. You have to be careful to extend the pipeline, while the previous configuration is still running and only discard the old 'extension' when you are receiving items on the new one. This is because the way the pipeline is designed right now, if there is a time when an item is ready to be sent, but noone is listening, slurry will close the pipeline down.
Hi, I think slurry is good for my use case, but I cannot tell for sure, because there are not enough examples of using the various parts of the library in combination.
I would particularly like to know:
The text was updated successfully, but these errors were encountered: