[L2Ork-dev] test out [unpost] please

[Jonathan Wilkes]

On Sun, Jul 5, 2020 at 3:11 PM Albert Graef <aggraef at gmail.com> wrote:

> 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.
>

That's an interesting idea.

What if we had an object named "pass" that simply passes messages through?

[pass clip -1 1]

Would just create the xlets based on the object named in the args, then
simply route messages through the connections.


>
> 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`).
>

You get one of the side-effects of this with [print] since it offers a link
back to the relevant object. But of course it
doesn't print out red.

Related-- there's a feature branch for desiredata's [trace] object I have
ported from desiredata as well.
You put it at the bottom of an object chain and it will trace back through
the stack calls that ended up at its
outlet. The guts can be used to do a stack trace for errors as well.


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

Yeah, I feel like without proper expression support in the syntax that's
difficult to implement. Same for "try/catch"--
technically we can already do it using [classinfo] and friends, but it's so
clunky that even I don't do that and I wrote
those classes.


>
> 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.
>

Speaking of pd-lua-- I've got a little-scripting-language based on FUDI
syntax. It currently has loops and branches. It
can suspend and resume state at will so that the user can deterministically
choose the number of operations to compute
per incoming message.

I was putting a Pratt parser on it when I last suspended operation on that
feature-branch.

-Jonathan


>
> 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/
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20200705/7c241126/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/7c241126/attachment-0001.png>