[L2Ork-dev] test out [unpost] please

[Albert Graef]

This is a very cool and interesting object which certainly has its uses
beyond regression tests -- effectively we have an exception handling
construct there. As I'm currently testing Ico's branch anyway, I gave the
unpost help patch a whirl -- I just threw a couple of different messages at
the `unpost error` object on the right and observed the results; I didn't
notice any bugs with these:


[image: image.png]

Jonathan, maybe it would be useful to offer another argument value (maybe
named `nop` or `post`) so that you could quickly disable the rerouting,
without having to remove the unpost object? Just an idea.

Here are some other ideas for further exploration, i.e., things that might
be useful in conjunction with `unpost`, at least for the
computer-science-minded Purr Data users:

- Implement a `raise` object which, when triggered, raises an error (using
creation arguments as the error message, or the input message if it's not
just `bang`).

- Implement an `expect` object which compares the input message with its
creation arguments and raises an error condition if they do *not* match.

I'm not sure, maybe there's something like that in the library already? If
not, I'm not sure whether these can be done
as abstractions, but it should be fairly easy to implement them using
pd-lua.

Albert


On Sun, Jul 5, 2020 at 8:06 PM Jonathan Wilkes <jon.w.wilkes at gmail.com>
wrote:

> Hi all,
>
> I'm relying a lot on [unpost] in the regression tests, so I'd like
> people to test out [unpost] to see if it has any bugs.
>
> You send it an input and it forward it to its right outlet.
>
> Now if anything downstream from its right outlet triggers an error,
> [unpost] will catch it and send it as a symbol to the left outlet.
>
> This way I can check for things like the existence of methods, and
> route a more meaningfully structured message to the testing
> infrastructure for the regression tests.
>
> The object was originally implemented by matju for desiredata. I
> changed the outlet ordering (I like it better that the first thing
> guaranteed to be output is from the right outlet). I also fixed a
> crasher with recursion and another issue that made it too easy for the
> user to get stuck in a confusing situation where [unpost] could still
> capture all the output. Finally, I gave it an "error" argument in case
> the user wants only to intercept error messages.
>
> Best,
> Jonathan
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev



-- 
Dr. Albert Gr"af
Computer Music Research Group, JGU Mainz, Germany
Email: aggraef at gmail.com, web: https://agraef.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20200705/a24b5ea3/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 28989 bytes
Desc: not available
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20200705/a24b5ea3/attachment-0001.png>