<div dir="ltr"><div dir="ltr">On Sun, Jul 5, 2020 at 3:11 PM Albert Graef <<a href="mailto:aggraef@gmail.com">aggraef@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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:</div><div><div><br></div><div><br></div><div><img src="cid:ii_kc9fxous1" alt="image.png" style="margin-right: 0px;" width="476" height="231"><br></div><div><br></div><div>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.<br></div></div></div></blockquote><div><br></div><div>That's an interesting idea.</div><div><br></div><div>What if we had an object named "pass" that simply passes messages through?</div><div><br></div><div>[pass clip -1 1]</div><div><br></div><div>Would just create the xlets based on the object named in the args, then simply route messages through the connections.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><br></div><div> 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:</div></div><div><br></div><div>- 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`).</div></div></blockquote><div><br></div><div>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 <br></div><div>doesn't print out red.</div><div><br></div><div>Related-- there's a feature branch for desiredata's [trace] object I have ported from desiredata as well. <br></div><div>You put it at the bottom of an object chain and it will trace back through the stack calls that ended up at its <br></div><div>outlet. The guts can be used to do a stack trace for errors as well.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>- Implement an `expect` object which compares the input message with its creation arguments and raises an error condition if they do *not* match.</div></div></blockquote><div><br></div><div>Yeah, I feel like without proper expression support in the syntax that's difficult to implement. Same for "try/catch"-- <br></div><div>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 <br></div><div>those classes.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>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<br></div><div> as abstractions, but it should be fairly easy to implement them using pd-lua.</div></div></blockquote></div><div class="gmail_quote"><br></div><div class="gmail_quote">Speaking of pd-lua-- I've got a little-scripting-language based on FUDI syntax. It currently has loops and branches. It <br></div><div class="gmail_quote">can suspend and resume state at will so that the user can deterministically choose the number of operations to compute <br></div><div class="gmail_quote">per incoming message.</div><div class="gmail_quote"><br></div><div class="gmail_quote">I was putting a Pratt parser on it when I last suspended operation on that feature-branch.</div><div class="gmail_quote"><br></div><div class="gmail_quote">-Jonathan<br></div><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Albert</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jul 5, 2020 at 8:06 PM Jonathan Wilkes <<a href="mailto:jon.w.wilkes@gmail.com" target="_blank">jon.w.wilkes@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<br>
<br>
I'm relying a lot on [unpost] in the regression tests, so I'd like<br>
people to test out [unpost] to see if it has any bugs.<br>
<br>
You send it an input and it forward it to its right outlet.<br>
<br>
Now if anything downstream from its right outlet triggers an error,<br>
[unpost] will catch it and send it as a symbol to the left outlet.<br>
<br>
This way I can check for things like the existence of methods, and<br>
route a more meaningfully structured message to the testing<br>
infrastructure for the regression tests.<br>
<br>
The object was originally implemented by matju for desiredata. I<br>
changed the outlet ordering (I like it better that the first thing<br>
guaranteed to be output is from the right outlet). I also fixed a<br>
crasher with recursion and another issue that made it too easy for the<br>
user to get stuck in a confusing situation where [unpost] could still<br>
capture all the output. Finally, I gave it an "error" argument in case<br>
the user wants only to intercept error messages.<br>
<br>
Best,<br>
Jonathan<br>
_______________________________________________<br>
L2Ork-dev mailing list<br>
<a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
<a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a></blockquote></div><br clear="all"><br>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Dr. Albert Gr"af<br>Computer Music Research Group, JGU Mainz, Germany<br>Email: <a href="mailto:aggraef@gmail.com" target="_blank">aggraef@gmail.com</a>, web: <a href="https://agraef.github.io/" target="_blank">https://agraef.github.io/</a></div></div></div></div></div></div>
_______________________________________________<br>
L2Ork-dev mailing list<br>
<a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
<a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a></blockquote></div></div>