<div dir="ltr"><div>Hi Jonathan,</div><div><br></div><div> I've looked at [select] in current vanilla again, and it does not accept a plain `bang` (without `symbol`) on the first inlet, nor on the second one. I think that this was the inconsistency supposed to be fixed there in #299, right? Then there's no incompatibility of that change with vanilla at all, quite the contrary -- the fix is supposed to *restore* vanilla compatibility. If someone really uses that undocumented behavior in a patch, then that patch won't work with vanilla either.</div><div><br></div><div> So I don't see *any* reason whatsoever to bump the major version number for this change. (And there's no need for -legacy either.) I'm really unhappy about that unwarranted version change, can it please be reverted? Thanks.<br></div><div><br></div><div>While we're at it, there's yet another problem: I doubt that rev. 779f31dc entirely fixes the issue reported in #299. I'm running a revision of purr-data here that should already have that commit, but while the second inlet refuses a plain bang (as it should), the first inlet still happily accepts it and bangs the first outlet (which it shouldn't, it should print an error instead). I'll try the latest source asap to make sure, but it seems that there's still an incompatibility with vanilla lurking there. We should really take a very close look at the source of vanilla's [select] and make sure that we fix up our method definitions so that they match up *exactly* with vanilla.</div><div><br></div><div>I'll post any further comments in the original bug report (#299). Sorry, I really should have reviewed Zack's contribution earlier, but I simply didn't have the time. Unfortunately, I'll be very short on time until mid July when our summer semester ends, but I'll do my best to help getting this sorted out.<br></div><div><br></div><div>Albert<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 27, 2020 at 10:56 PM Jonathan Wilkes <<a href="mailto:jon.w.wilkes@gmail.com">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">On Wed, May 27, 2020 at 3:34 PM Albert Graef <<a href="mailto:aggraef@gmail.com" target="_blank">aggraef@gmail.com</a>> wrote:<br>
><br>
> Would it be difficult to retain the old behavior with -legacy? That's how we usually deal with compatibility issues like this, don't we?<br>
<br>
I was going to mention that, except that it appears Ico is the main user of this<br>
feature. So shifting to legacy mode would fix [select] for him while breaking<br>
all his GOP interfaces!<br>
<br>
><br>
> Also, I don't think that this warrants a major release bump. We didn't do that either, e.g., with the bendin fix, which IMHO is a similar case.<br>
<br>
Somehow I missed that one.<br>
<br>
On this one we have one reported case from Ico. As I understand it,<br>
removing a public method like<br>
this is a breaking change and thus warrants the version bump.<br>
<br>
We should probably all figure out a consistent approach. But for this<br>
particular version bump there aren't<br>
any practical consequences, are there? I mean there's no automated<br>
tooling wrapped around Purr Data<br>
that is going to break one million in-dash entertainment systems or anything...<br>
<br>
-Jonathan<br>
<br>
><br>
> Albert<br>
><br>
><br>
> On Wed, May 27, 2020 at 8:27 PM Jonathan Wilkes <<a href="mailto:jon.w.wilkes@gmail.com" target="_blank">jon.w.wilkes@gmail.com</a>> wrote:<br>
>><br>
>> On Wed, May 27, 2020 at 1:41 PM Ivica Bukvic <<a href="mailto:ico@vt.edu" target="_blank">ico@vt.edu</a>> wrote:<br>
>> ><br>
>> > Thank you, Jonathan. I'm curious as to the reason for removing bang from the selected object? I imagine this may break a number of older patches. Is this something that maintains parity with the vanilla?<br>
>><br>
>> It was because the change introduced an ambiguity where argument<br>
>> "bang" could match<br>
>> both a "bang" message and "symbol bang" message. Since [route] already<br>
>> handles bang<br>
>> unambiguously and since the feature was never documented it seemed<br>
>> safe to remove it.<br>
>><br>
>> I could make a branch of code in the select class to support that<br>
>> feature and couple it with a<br>
>> certain compatibility level. But that would require the user to a)<br>
>> know ahead of time which<br>
>> version number will unlock that branch and b) manually send a message<br>
>> to Pd to turn<br>
>> on that particular compatibility level.<br>
>><br>
>> I started an issue related to the problems with the compatibility method:<br>
>><br>
>> <a href="https://git.purrdata.net/jwilkes/purr-data/-/issues/636" rel="noreferrer" target="_blank">https://git.purrdata.net/jwilkes/purr-data/-/issues/636</a><br>
>><br>
>> -Jonathan<br>
>><br>
>> ><br>
>> > Best,<br>
>> ><br>
>> > Ico<br>
>> ><br>
>> > --<br>
>> > Ivica Ico Bukvic, D.M.A.<br>
>> > Director, Creativity + Innovation<br>
>> > Institute for Creativity, Arts, and Technology<br>
>> ><br>
>> > Virginia Tech<br>
>> > Creative Technologies in Music<br>
>> > School of Performing Arts – 0141<br>
>> > Blacksburg, VA 24061<br>
>> > (540) 231-6139<br>
>> > <a href="mailto:ico@vt.edu" target="_blank">ico@vt.edu</a><br>
>> ><br>
>> > <a href="http://www.icat.vt.edu" rel="noreferrer" target="_blank">www.icat.vt.edu</a><br>
>> > <a href="http://www.performingarts.vt.edu" rel="noreferrer" target="_blank">www.performingarts.vt.edu</a><br>
>> > <a href="http://l2ork.icat.vt.edu" rel="noreferrer" target="_blank">l2ork.icat.vt.edu</a><br>
>> > <a href="http://ico.bukvic.net" rel="noreferrer" target="_blank">ico.bukvic.net</a><br>
>> ><br>
>> > On Wed, May 27, 2020, 12:52 Jonathan Wilkes <<a href="mailto:jon.w.wilkes@gmail.com" target="_blank">jon.w.wilkes@gmail.com</a>> wrote:<br>
>> >><br>
>> >> Hi all,<br>
>> >><br>
>> >> We're gearing up for the official coding period to begin for Purr Data<br>
>> >> GSoC. Exciting!<br>
>> >><br>
>> >> A few orders of business:<br>
>> >><br>
>> >> 1. I've got a 3.0.0 version coming up. Since it removes "bang" method<br>
>> >> from [select] (thanks Zack) I incremented the major version to signify<br>
>> >> a breaking change.<br>
>> >><br>
>> >> 2. I'd like to update the nw.js toolkit to the most recent version for<br>
>> >> the next version 3.0.1. Is anyone willing to help test and report<br>
>> >> bugs? Unfortunately we have no regression test for the front-end so it<br>
>> >> will probably require some time and effort to do this right.<br>
>> >><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><br>
>> ><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><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><br>
><br>
><br>
><br>
> --<br>
> 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/" rel="noreferrer" target="_blank">https://agraef.github.io/</a><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><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" class="gmail_signature"><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>