[L2Ork-dev] Current HEAD of Purr Data is broken

Ivica Ico Bukvic ico at vt.edu
Tue Jun 30 21:29:02 EDT 2020


So, I cannot issue a merge request since the main branch still has the 
older version of gui_scalar_new that does not have the plot_style option 
which is meant to fine-tune plot positioning (and may be tied to the 
0.4x nw.js). While this fixes it on my branch, I will have to dig 
through yours to see what you may have not been merged (as is the case 
with the previously mentioned merge) to have caused this regression.

I really wish that we moved forward with the 0.4x transition...

Best,

Ico

On 6/30/2020 9:22 PM, Ivica Ico Bukvic wrote:
>
> OK, I got the fix. This was definitely my doing--in fixing the plots I 
> completely forgot that a non-plot scalar may not have a valid plot 
> type and therefore will have matrix left undefined. Below is a diff. 
> Also, I will send out a merge request shortly.
>
> Best,
>
> Ico
>
> index 6d85631a..1a0ea4bc 100644
> --- a/pd/nw/pdgui.js
> +++ b/pd/nw/pdgui.js
> @@ -3514,7 +3514,11 @@ function gui_scalar_new(cid, tag, isselected, 
> t1, t2, t3, t4, t5, t6,
>                      transform_string = "translate(" + 0 +
>                          "," + (t6+1) + ") scale(" + t1 + "," + t4 + ")";
>                      //post("transform_string = " + transform_string);
> -                    break;
> +                    break;
> +                default:
> +                    // we are a non-plot scalar
> +                    matrix = [t1,t2,t3,t4,t5,t6];
> +                    break;
>              }
>          }
>          else {
> @@ -3535,6 +3539,10 @@ function gui_scalar_new(cid, tag, isselected, 
> t1, t2, t3, t4, t5, t6,
>                          "," + (t6+1.5) + ") scale(" + t1 + "," + t4 + 
> ")";
>                      //post("transform_string = " + transform_string);
>                      break;
> +                default:
> +                    // we are a non-plot scalar
> +                    matrix = [t1,t2,t3,t4,t5,t6];
> +                    break;
>              }
>          }
>
>
>
>
> On 6/30/2020 9:13 PM, Ivica Ico Bukvic wrote:
>>
>> It appears my branch is affected, as well, so it is either something 
>> I did or something that was merged from the main branch. The error is 
>> as follows (on Windows, at least):
>>
>> C:\Program Files (x86)\Purr Data\bin\pdgui.js:3542 Uncaught 
>> TypeError: Cannot read property 'join' of undefined
>>     at C:\Program Files (x86)\Purr Data\bin\pdgui.js:3542:51
>>     at get (C:\Program Files (x86)\Purr Data\bin\pdgui.js:2057:21)
>>     at Object.get_elem (C:\Program Files (x86)\Purr 
>> Data\bin\pdgui.js:2073:24)
>>     at gui_scalar_new (C:\Program Files (x86)\Purr 
>> Data\bin\pdgui.js:3491:14)
>>     at eval (eval at perfect_parser (C:\Program Files (x86)\Purr 
>> Data\bin\pdgui.js:1885:21), <anonymous>:1:1)
>>     at perfect_parser (C:\Program Files (x86)\Purr 
>> Data\bin\pdgui.js:1885:21)
>>     at Socket.<anonymous> (C:\Program Files (x86)\Purr 
>> Data\bin\pdgui.js:1903:9)
>>     at Socket.emit (events.js:315)
>>     at addChunk (_stream_readable.js:302)
>>     at readableAddChunk (_stream_readable.js:278)
>>
>> Best,
>>
>> Ico
>>
>> On 6/30/2020 8:08 PM, Ivica Bukvic wrote:
>>> Before we do that, allow me to take a stab at this to see what may 
>>> have broke. I will also test to see if my branch exhibits the same 
>>> problem. What about the plot drawing optimizations you introduced, 
>>> could they be also somehow involved? I don't have those yet on my 
>>> branch and have not experienced any known problems yet, although I 
>>> need to test the about page.
>>>
>>> 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 <mailto:ico at vt.edu>
>>>
>>> www.icat.vt.edu <http://www.icat.vt.edu>
>>> www.performingarts.vt.edu <http://www.performingarts.vt.edu>
>>> l2ork.icat.vt.edu <http://l2ork.icat.vt.edu>
>>> ico.bukvic.net <http://ico.bukvic.net>
>>>
>>> On Tue, Jun 30, 2020, 19:23 Jonathan Wilkes <jon.w.wilkes at gmail.com 
>>> <mailto:jon.w.wilkes at gmail.com>> wrote:
>>>
>>>     Albert-- now that HEAD is what it is, what would the process be of
>>>     rolling it back while putting all those merges
>>>     into a separate nwjs-update branch?
>>>
>>>     -Jonathan
>>>
>>>     On Tue, Jun 30, 2020 at 5:57 PM Jonathan Wilkes
>>>     <jon.w.wilkes at gmail.com <mailto:jon.w.wilkes at gmail.com>> wrote:
>>>     >
>>>     > On Tue, Jun 30, 2020 at 3:20 PM Ivica Bukvic <ico at vt.edu
>>>     <mailto:ico at vt.edu>> wrote:
>>>     > >
>>>     > > The fix that may have triggered the regression you describe
>>>     was supposed to fix a regression :-)
>>>     > >
>>>     > > Namely the code removed that deletes data structures during
>>>     a redraw also tends to delete all the other objects on a
>>>     subpatch when an undo action is triggered, leaving only patch
>>>     cords visible. This was true regardless of the nw.js version. I
>>>     suspect that the fix that Jonathan originally introduced there
>>>     may have been because of drawing of the data structures
>>>     alongside the regular objects on the same canvas, which is what
>>>     the about page has with the animated cat.
>>>     >
>>>     > Unfortunately, I can't create a scalar on a canvas at all.
>>>     This is a
>>>     > bug even if there are no gop subpatches in existence.
>>>     >
>>>     > Also-- I tried reverting the code you're referring to, Ico.
>>>     Even with
>>>     > that code path present, a simple scalar will fail to
>>>     > be displayed. Even worse-- nothing gets created on the GUI
>>>     side. So
>>>     > either the problem is something you introduced to
>>>     > gui_scalar_new, or in the backend preventing that from every
>>>     being called.
>>>     >
>>>     > -Jonathan
>>>     >
>>>     > >
>>>     > > My originally proposed merge request offered deleting only
>>>     scalars in a situation that the code seemed to address. I also
>>>     indicated that it needed to be tested further given I was unsure
>>>     under which circumstances this code would be necessary. The
>>>     final merge was Jonathan's where he erased that part entirely
>>>     suggesting it was not necessary anymore.
>>>     > >
>>>     > > What may be helpful, as the code complexity continues to
>>>     grow, is to carefully annotate each of these calls in the code
>>>     so that we can better understand why they are placed there in
>>>     the first place and what needs to be done to check for regressions.
>>>     > >
>>>     > > 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 <mailto:ico at vt.edu>
>>>     > >
>>>     > > www.icat.vt.edu <http://www.icat.vt.edu>
>>>     > > www.performingarts.vt.edu <http://www.performingarts.vt.edu>
>>>     > > l2ork.icat.vt.edu <http://l2ork.icat.vt.edu>
>>>     > > ico.bukvic.net <http://ico.bukvic.net>
>>>     > >
>>>     > > On Tue, Jun 30, 2020, 14:16 Albert Graef <aggraef at gmail.com
>>>     <mailto:aggraef at gmail.com>> wrote:
>>>     > >>
>>>     > >> Sorry, I missed these remarks earlier.
>>>     > >>
>>>     > >> On Tue, Jun 30, 2020 at 2:14 PM Jonathan Wilkes
>>>     <jon.w.wilkes at gmail.com <mailto:jon.w.wilkes at gmail.com>> wrote:
>>>     > >>>
>>>     > >>> I can confirm running HEAD against a local 0.46.3 nw.js on
>>>     aarch64
>>>     > >>> does indeed work to load and display patches.
>>>     > >>
>>>     > >>
>>>     > >> Have you tried  the Help - About Pd-L2ork menu entry?
>>>     > >>
>>>     > >>> What do I need to add to the contributor's guide to make
>>>     it clear what
>>>     > >>> a desirable merge request branch should look like?
>>>     > >>
>>>     > >>
>>>     > >> I guess you're talking about workflow here? That is,
>>>     rebasing and squashing commits so that you present your feature
>>>     branch a.k.a. merge request as simple and comprehensible as
>>>     possible, with a clean and logical commit history. There's a lot
>>>     that goes into that  process and much of it is common sense --
>>>     but you'd probably have to replicate half the Git Book to
>>>     explain these things really thoroughly.
>>>     > >>
>>>     > >> However, the main failure in this case IMHO was that there
>>>     weren't enough eyeballs looking at this "patchset from hell",
>>>     before the changes were merged into master. A call for help on
>>>     the mailing list goes a long way there, explaining what the new
>>>     set of changes is about, what parts of the program might be
>>>     affected, and what needs to be tested. I did notice the flurry
>>>     of commits, but I wasn't sure what they were about and didn't
>>>     have the time to look into them. I would certainly have tried to
>>>     give a helping hand in testing, though, when asked about it in
>>>     the manner described. ;-) (Or maybe I missed that call, then I
>>>     have to apologize.)
>>>     > >>
>>>     > >> Albert
>>>     > >>
>>>     > >>> > On Tue, Jun 30, 2020 at 11:42 AM Sam Thursfield
>>>     <ssssam at gmail.com <mailto:ssssam at gmail.com>> wrote:
>>>     > >>> >>
>>>     > >>> >> Hi Albert,
>>>     > >>> >>
>>>     > >>> >> On Tue, Jun 30, 2020 at 9:12 AM Albert Graef
>>>     <aggraef at gmail.com <mailto:aggraef at gmail.com>> wrote:
>>>     > >>> >> > The program still builds fine, launches and I can
>>>     still open new patch windows (^n), but "About Pd-L2ork" doesn't
>>>     work any more and I can't open existing patches either
>>>     (apparently the patches do get opened in the engine, but no
>>>     window is mapped).
>>>     > >>> >>
>>>     > >>> >> Is it possible that you are using a version of nw.js >=
>>>     0.42.3 ?
>>>     > >>> >> This issue sounds a bit like
>>>     > >>> >> https://git.purrdata.net/jwilkes/purr-data/-/issues/572
>>>     > >>> >> Sam
>>>     > >>> >> _______________________________________________
>>>     > >>> >> L2Ork-dev mailing list
>>>     > >>> >> L2Ork-dev at disis.music.vt.edu
>>>     <mailto: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 <mailto:aggraef at gmail.com>,
>>>     web: https://agraef.github.io/
>>>     > >>> > _______________________________________________
>>>     > >>> > L2Ork-dev mailing list
>>>     > >>> > L2Ork-dev at disis.music.vt.edu
>>>     <mailto: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
>>>     <mailto: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 <mailto:aggraef at gmail.com>, web:
>>>     https://agraef.github.io/
>>>     > >> _______________________________________________
>>>     > >> L2Ork-dev mailing list
>>>     > >> L2Ork-dev at disis.music.vt.edu
>>>     <mailto: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
>>>     <mailto: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 <mailto:L2Ork-dev at disis.music.vt.edu>
>>>     https://disis.music.vt.edu/listinfo/l2ork-dev
>>>
>> -- 
>> 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
> -- 
> 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

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20200630/bd20e78f/attachment-0001.html>


More information about the L2Ork-dev mailing list