[L2Ork-dev] Current HEAD of Purr Data is broken
Ivica Bukvic
ico at vt.edu
Wed Jul 1 13:20:04 EDT 2020
I got the debug message resolved. Will be submitting a merge request
shortly. Still working on the other one.
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
ci.icat.vt.eduwww.icat.vt.edu
www.performingarts.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net
On Wed, Jul 1, 2020 at 12:40 AM Albert Graef <aggraef at gmail.com> wrote:
> I'm getting those debugging messages also with vanilla array scalars:
>
> [image: image.png]
>
> That might just be some leftover debugging message. At least this example
> seems to work properly.
>
>
> On Wed, Jul 1, 2020 at 6:35 AM Albert Graef <aggraef at gmail.com> wrote:
>
>> Ok, that improved things *a lot*. The about dialog is working again, as
>> does doc/4.data.structures/07.sequencer.pd. But I'm still having trouble
>> with some (array-related?) pd-l2ork scalar examples, specifically
>> doc/4.data.structures/pd-l2ork/ds-tutorials/00.under.construction.pd gives
>> me this when launched (and the animation of the construction sign fails to
>> work):
>>
>> [image: image.png]
>>
>> Do you have a fix for that as well? It seems that we're getting really
>> close...
>>
>> Albert
>>
>>
>> On Wed, Jul 1, 2020 at 4:14 AM Ivica Ico Bukvic <ico at vt.edu> wrote:
>>
>>> Just submitted a merge request that does 2 things:
>>>
>>> 1) fixes the scalar issue and
>>>
>>> 2) included as a separate commit in the same merge request items that
>>> were for some reason omitted during the mergefest
>>>
>>> This should now solve most issues with the exception of the 0.47
>>> features whose status I did not explore in detail since they have not been
>>> completely merged.
>>>
>>> The new scrollbars do work here but please note I am using 0.47.
>>>
>>> Best,
>>>
>>> Ico
>>> On 6/30/2020 9:32 PM, Ivica Ico Bukvic wrote:
>>>
>>> Never mind, this should apply onto your branch fine. I am curious why my
>>> "git checkout -b <new_branch> upstream/master" does not get me the most
>>> up-to-date content from your branch. Plot thickens...
>>>
>>> Once I figure out this, I will send you a merge request.
>>>
>>> Best,
>>>
>>> Ico
>>> On 6/30/2020 9:29 PM, Ivica Ico Bukvic wrote:
>>>
>>> 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
>>>
>>> www.icat.vt.edu
>>> www.performingarts.vt.edu
>>> l2ork.icat.vt.edu
>>> ico.bukvic.net
>>>
>>> On Tue, Jun 30, 2020, 19:23 Jonathan Wilkes <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>
>>>> wrote:
>>>> >
>>>> > On Tue, Jun 30, 2020 at 3:20 PM Ivica Bukvic <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
>>>> > >
>>>> > > www.icat.vt.edu
>>>> > > www.performingarts.vt.edu
>>>> > > l2ork.icat.vt.edu
>>>> > > ico.bukvic.net
>>>> > >
>>>> > > On Tue, Jun 30, 2020, 14:16 Albert Graef <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> 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> wrote:
>>>> > >>> >>
>>>> > >>> >> Hi Albert,
>>>> > >>> >>
>>>> > >>> >> On Tue, Jun 30, 2020 at 9:12 AM Albert Graef <
>>>> 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
>>>> > >>> >> 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/
>>>> > >> _______________________________________________
>>>> > >> 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
>>>
>>> --
>>> 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-6139ico at vt.edu
>>> www.icat.vt.eduwww.performingarts.vt.edul2ork.icat.vt.eduico.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-6139ico at vt.edu
>>> www.icat.vt.eduwww.performingarts.vt.edul2ork.icat.vt.eduico.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-6139ico at vt.edu
>>> www.icat.vt.eduwww.performingarts.vt.edul2ork.icat.vt.eduico.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-6139ico at vt.edu
>>> www.icat.vt.eduwww.performingarts.vt.edul2ork.icat.vt.eduico.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-6139ico at vt.edu
>>> www.icat.vt.eduwww.performingarts.vt.edul2ork.icat.vt.eduico.bukvic.net
>>>
>>> _______________________________________________
>>> 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/
>>
>
>
> --
> 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/20200701/a7ae7469/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 525434 bytes
Desc: not available
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20200701/a7ae7469/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 448533 bytes
Desc: not available
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20200701/a7ae7469/attachment-0003.png>
More information about the L2Ork-dev
mailing list