[L2Ork-dev] Getting ready for GSoC coding to begin

Albert Graef aggraef at gmail.com
Thu May 28 02:00:11 EDT 2020


Hi Jonathan,

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.

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.

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.

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.

Albert


On Wed, May 27, 2020 at 10:56 PM Jonathan Wilkes <jon.w.wilkes at gmail.com>
wrote:

> On Wed, May 27, 2020 at 3:34 PM Albert Graef <aggraef at gmail.com> wrote:
> >
> > 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?
>
> I was going to mention that, except that it appears Ico is the main user
> of this
> feature. So shifting to legacy mode would fix [select] for him while
> breaking
> all his GOP interfaces!
>
> >
> > 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.
>
> Somehow I missed that one.
>
> On this one we have one reported case from Ico. As I understand it,
> removing a public method like
> this is a breaking change and thus warrants the version bump.
>
> We should probably all figure out a consistent approach. But for this
> particular version bump there aren't
> any practical consequences, are there? I mean there's no automated
> tooling wrapped around Purr Data
> that is going to break one million in-dash entertainment systems or
> anything...
>
> -Jonathan
>
> >
> > Albert
> >
> >
> > On Wed, May 27, 2020 at 8:27 PM Jonathan Wilkes <jon.w.wilkes at gmail.com>
> wrote:
> >>
> >> On Wed, May 27, 2020 at 1:41 PM Ivica Bukvic <ico at vt.edu> wrote:
> >> >
> >> > 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?
> >>
> >> It was because the change introduced an ambiguity where argument
> >> "bang" could match
> >> both a "bang" message and "symbol bang" message. Since [route] already
> >> handles bang
> >> unambiguously and since the feature was never documented it seemed
> >> safe to remove it.
> >>
> >> I could make a branch of code in the select class to support that
> >> feature and couple it with a
> >> certain compatibility level. But that would require the user to a)
> >> know ahead of time which
> >> version number will unlock that branch and b) manually send a message
> >> to Pd to turn
> >> on that particular compatibility level.
> >>
> >> I started an issue related to the problems with the compatibility
> method:
> >>
> >> https://git.purrdata.net/jwilkes/purr-data/-/issues/636
> >>
> >> -Jonathan
> >>
> >> >
> >> > Best,
> >> >
> >> > Ico
> >> >
> >> > --
> >> > Ivica Ico Bukvic, D.M.A.
> >> > Director, Creativity + Innovation
> >> > Institute for Creativity, Arts, and Technology
> >> >
> >> > Virginia Tech
> >> > Creative Technologies in Music
> >> > School of Performing Arts – 0141
> >> > Blacksburg, VA 24061
> >> > (540) 231-6139
> >> > ico at vt.edu
> >> >
> >> > www.icat.vt.edu
> >> > www.performingarts.vt.edu
> >> > l2ork.icat.vt.edu
> >> > ico.bukvic.net
> >> >
> >> > On Wed, May 27, 2020, 12:52 Jonathan Wilkes <jon.w.wilkes at gmail.com>
> wrote:
> >> >>
> >> >> Hi all,
> >> >>
> >> >> We're gearing up for the official coding period to begin for Purr
> Data
> >> >> GSoC. Exciting!
> >> >>
> >> >> A few orders of business:
> >> >>
> >> >> 1. I've got a 3.0.0 version coming up. Since it removes "bang" method
> >> >> from [select] (thanks Zack) I incremented the major version to
> signify
> >> >> a breaking change.
> >> >>
> >> >> 2. I'd like to update the nw.js toolkit to the most recent version
> for
> >> >> the next version 3.0.1. Is anyone willing to help test and report
> >> >> bugs? Unfortunately we have no regression test for the front-end so
> it
> >> >> will probably require some time and effort to do this right.
> >> >>
> >> >> -Jonathan
> >> >> _______________________________________________
> >> >> L2Ork-dev mailing list
> >> >> L2Ork-dev at disis.music.vt.edu
> >> >> https://disis.music.vt.edu/listinfo/l2ork-dev
> >> >
> >> > _______________________________________________
> >> > L2Ork-dev mailing list
> >> > L2Ork-dev at disis.music.vt.edu
> >> > https://disis.music.vt.edu/listinfo/l2ork-dev
> >> _______________________________________________
> >> 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
> _______________________________________________
> 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/20200528/52819361/attachment-0001.html>


More information about the L2Ork-dev mailing list