purr-data issueshttps://git.purrdata.net/jwilkes/purr-data/-/issues2020-09-17T19:37:10Zhttps://git.purrdata.net/jwilkes/purr-data/-/issues/666ci logs are too long for GitLab CI2020-09-17T19:37:10ZSam Thursfieldci logs are too long for GitLab CIgit.purrdata.net has a limit of 4194304 bytes for CI logs and this is sometimes exceeded by CI jobs, e.g. https://git.purrdata.net/jwilkes/purr-data/-/jobs/18898 and https://git.purrdata.net/jwilkes/purr-data/-/jobs/18862
Here are some ...git.purrdata.net has a limit of 4194304 bytes for CI logs and this is sometimes exceeded by CI jobs, e.g. https://git.purrdata.net/jwilkes/purr-data/-/jobs/18898 and https://git.purrdata.net/jwilkes/purr-data/-/jobs/18862
Here are some things to investigate to reduce the size of logs:
- [x] Enable Automake's [silent mode](https://www.gnu.org/software/automake/manual/html_node/Automake-Silent-Rules.html) so compiler/linker commandlines are only shown when an error occurs
- [ ] fix the many `dpkg-shlibdeps` warnings that occur
- [x] modify the tests to only show output when there's a problem (i don't know how the tests work, but maybe it's simple to do)https://git.purrdata.net/jwilkes/purr-data/-/issues/665Use ccache to speed up build times2020-09-17T20:02:41ZSam ThursfieldUse ccache to speed up build timesWe can speed up the CI by installing [ccache](https://ccache.dev/) on all of the GitLab CI runners, and using [GitLab CI caching](https://docs.gitlab.com/ee/ci/caching/index.html) to share the `$CCACHE_DIR` between jobs.
For the Linux r...We can speed up the CI by installing [ccache](https://ccache.dev/) on all of the GitLab CI runners, and using [GitLab CI caching](https://docs.gitlab.com/ee/ci/caching/index.html) to share the `$CCACHE_DIR` between jobs.
For the Linux runners we can install the ccache package inside the containers. For OSX and Windows the admin of those machines will need to install it in the host.
It's also important that the GitLab CI machines have a reasonable about of disk space dedicated to the CI cache -- at least large enough to fit all the .o files from a build of PD.https://git.purrdata.net/jwilkes/purr-data/-/issues/662[list store] not optimal for building gigantic messages2020-07-26T19:30:06ZJonathan Wilkes[list store] not optimal for building gigantic messagesIf you try to accumulate a large list with [list store], reallocation time becomes a major factor on Windows.
Can easily improve realloc times by overallocating using a simple doubling algorithm.
There's already a related "quick-and-di...If you try to accumulate a large list with [list store], reallocation time becomes a major factor on Windows.
Can easily improve realloc times by overallocating using a simple doubling algorithm.
There's already a related "quick-and-dirty" algorithm like that in unpost_printhook to fill in for C++ iostream from matju's original C++ implementation. So we probably want to put an interface in m_memory.c for general use.
However, we'd need to be careful to document this interface as inappropriate for realtime computation. While it can vastly improve average performance it doesn't guarantee worst-case performance. (And in fact better average perf can *hide* worst-case perf from the user, which is a strange but very real usability problem in soft realtime environments like this.)
In fact, we may consider adding something like [list storeupto 100] to initialize max size to 100 and error out above that. This would avoid realloc altogether and *could* be realtime safe if we handle gpointers efficiently.Jonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/issues/661"inlet: expected x but got y" should name the object that owns it2021-04-21T09:57:28ZJonathan Wilkes"inlet: expected x but got y" should name the object that owns itreplace it with:
"inlet of z: expected x but got y"
where z is the classnamereplace it with:
"inlet of z: expected x but got y"
where z is the classnamehttps://git.purrdata.net/jwilkes/purr-data/-/issues/658Legacy tcl command in g_canvas.c tripped by about patch2020-09-02T09:16:46ZAlbert GräfLegacy tcl command in g_canvas.c tripped by about patchUnfortunately, I can't reproduce this reliably, but while testing Ico's branch for "old" (pre 0.46) nw.js regressions, I sometimes got a message like this in the console when opening the about patch via Help => About Pd-L2ork, so I thoug...Unfortunately, I can't reproduce this reliably, but while testing Ico's branch for "old" (pre 0.46) nw.js regressions, I sometimes got a message like this in the console when opening the about patch via Help => About Pd-L2ork, so I thought that I might just as well report it:
~~~
legacy tcl command at 1815 of g_canvas.c: pdtk_select_all_gop_widgets .x56290a4297b0 56290a392610 1
~~~
The line is actually at https://git.purrdata.net/jwilkes/purr-data/-/blob/master/pd/src/g_canvas.c#L1772 in the current master branch (but at line 1815 in Ico's branch), in the `glist_redrawall` function. It reads (I've included the two comment lines above for context):
~~~c
/* Haven't tested scalars inside gop yet, but we
probably need a gui_vmess here */
sys_vgui("pdtk_select_all_gop_widgets .x%lx %lx %d\n",
glist_getcanvas(gl), gl, 1);
~~~
This code is pretty ancient (rev. 4717bd585 "Jonathan's clean-up of the g_canvas.c" submitted by Ico Sat Mar 8 22:32:28 2014 -0500 according to git blame), so this seems to be a leftover from the olden pd-l2ork 1.x days.
I'm not sure how this code gets tripped or why, as I said I couldn't really pin this down because I can only reproduce it by accident so far. It *might* be tripped by Ico's changes (if so, then maybe by rev. b16cbaed3cb40d232849553b200fdbfa70e7f9e2?), but I'm not sure at all about that either. But I'm pretty well sure that we don't want this code to be there in 2020, waiting for its chance to be executed. ;-)
@jwilkes Maybe you can figure out what's up with this legacy tcl call and why it's still there. Maybe we can just comment it out, so that it doesn't by accident rear its head?Jonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/issues/657make selection from clicking "error" link in pd more obvious2020-07-07T07:15:01ZJonathan Wilkesmake selection from clicking "error" link in pd more obviousWhen the user clicks the "error" hyperlink in the Pd window, if the relevant object is in the current top level window then putting a selection around it is too subtle.
Especially for an iemgui with a dark background color, the border h...When the user clicks the "error" hyperlink in the Pd window, if the relevant object is in the current top level window then putting a selection around it is too subtle.
Especially for an iemgui with a dark background color, the border highlight is barely even noticeable.
Two options:
* use a CSS animation to draw the user's eye
* put the cord inspector over there (and perhaps fill it with the error message)https://git.purrdata.net/jwilkes/purr-data/-/issues/656[symbol 123( needs a warning2020-07-05T17:52:20ZJonathan Wilkes[symbol 123( needs a warningWhen the user types a float payload for a symbol message into the message box, it should give a warning:
[symbol 123( <-- warning: this is silently converted to empty symbol
We should also check the code to make sure it's well-defined ...When the user types a float payload for a symbol message into the message box, it should give a warning:
[symbol 123( <-- warning: this is silently converted to empty symbol
We should also check the code to make sure it's well-defined c that does the conversion, and not just setting one union field and accidentally reading from the otherhttps://git.purrdata.net/jwilkes/purr-data/-/issues/655Scrollbar viewport slightly off2020-07-06T05:57:17ZAlbert GräfScrollbar viewport slightly offThis is just something I noticed while testing Ico's nw.js 0.4x branch, but I can reproduce this also with Purr Data 2.10.1 and 2.11.0 (using nw.js 0.24.4), so it's not related to the latest work in any way and has been with us for a lit...This is just something I noticed while testing Ico's nw.js 0.4x branch, but I can reproduce this also with Purr Data 2.10.1 and 2.11.0 (using nw.js 0.24.4), so it's not related to the latest work in any way and has been with us for a little while. Tested on Linux (Manjaro), but I suspect that it's the same across all supported platforms. It's just a (very) minor cosmetic issue, just something I noticed, so I thought I'd report it, so that it might be addressed in a future release.
It appears that the viewport calculation for the scrollbars is slightly off, so that it's possible to have the patch window contents partially obscured, but no scrollbar visible yet. E.g., in the screenshot below you can see that both the right edge of the array `wave` and the bottom edge of the `tabwrite~` object have become invisible (by reducing the window size), yet there are no scrollbars (yet). (Of course, the scrollbars do appear if I continue to make the window smaller.)
![viewport](/uploads/98e96b02c808500f656ca92970a2b3c0/viewport.png)
Here's the little patch I used in the screenshot, for reproducibility: [subtractive.pd](/uploads/ab00df534bdaccdc08c5cb2f283c62bb/subtractive.pd)https://git.purrdata.net/jwilkes/purr-data/-/issues/653[cputime] doesn't work properly when compiled with emscripten2020-06-25T00:17:55ZZack Lee[cputime] doesn't work properly when compiled with emscriptenThe [cputime] object doesn't work properly and always outputs 0 when compiled with emscripten.
The issue is caused by the `times()` function from `sys/times.h` not currently being supported/implemented in emscripten.
Here's the relevan...The [cputime] object doesn't work properly and always outputs 0 when compiled with emscripten.
The issue is caused by the `times()` function from `sys/times.h` not currently being supported/implemented in emscripten.
Here's the relevant post: https://github.com/emscripten-core/emscripten/issues/11491
This could potentially be fixed by using JavaScript to calculate the CPU time when built with emscripten.https://git.purrdata.net/jwilkes/purr-data/-/issues/652gui_textarea uses both "top" and "transform" property2020-06-22T02:05:02ZJonathan Wilkesgui_textarea uses both "top" and "transform" propertyRecent improvements to gui_textarea added a "transform" to translateY by some pixels. This extra property is not needed-- the value should just be calculated into the "top" property above it.Recent improvements to gui_textarea added a "transform" to translateY by some pixels. This extra property is not needed-- the value should just be calculated into the "top" property above it.Ivica BukvicIvica Bukvichttps://git.purrdata.net/jwilkes/purr-data/-/issues/651add element parameter for gui.append method2020-06-21T17:01:17ZJonathan Wilkesadd element parameter for gui.append methodThe user might want to have a reference to the parent they're appending to. So the function sig should be something like `function(frag, e, window, nw_win)`The user might want to have a reference to the parent they're appending to. So the function sig should be something like `function(frag, e, window, nw_win)`Jonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/issues/650iemgui updates from Pd 0.46/0.472020-06-21T00:13:08ZAlexandre Porresiemgui updates from Pd 0.46/0.47Hi, as of Pd 0.46, there has been a few changes to iemguis, which now don't clip values anymore (nbx still does though). Moreover, the color scheme changed for [cnv] and [vu]. Finally, as of Pd 0.47 you can now set colors with hexnotatio...Hi, as of Pd 0.46, there has been a few changes to iemguis, which now don't clip values anymore (nbx still does though). Moreover, the color scheme changed for [cnv] and [vu]. Finally, as of Pd 0.47 you can now set colors with hexnotation.
You can check the help files of iemguis for more details in the newly released Pd Vanilla 0.51https://git.purrdata.net/jwilkes/purr-data/-/issues/649route dereferences wrong type in t_word union2020-06-20T05:06:26ZJonathan Wilkesroute dereferences wrong type in t_word unionIn route_list (and possibly route_anything), the first branch is based off `x->x_type` *OR* the if we're in `x->x_mixed` mode.
Further down the each element of the routeelement array is dereferenced to check against the incoming value. ...In route_list (and possibly route_anything), the first branch is based off `x->x_type` *OR* the if we're in `x->x_mixed` mode.
Further down the each element of the routeelement array is dereferenced to check against the incoming value. But it always checks the w_float field of the union, which we shouldn't be doing if we originally set it in route_new as a t_symbol.
I can't trigger a bug from this, but it's at least conceivable that one of the routeelements could be set to a symbol value that gets read out as a w_float and creates a false positive match.
Anyway, we should be reading the other union type here since we're not type-punning.Jonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/issues/6480.47 transition remaining known issues2020-06-17T21:29:30ZIvica Bukvic0.47 transition remaining known issues* it is impossible to move points on toplevel non-joc patches that open with the patch (even if you afterwards close it and reopen it and even change the joc settings) (this is a major issue)
* Need to rework dialog window sizes and mak...* it is impossible to move points on toplevel non-joc patches that open with the patch (even if you afterwards close it and reopen it and even change the joc settings) (this is a major issue)
* Need to rework dialog window sizes and make them fixed in height and width
* Adjust vertical offset for the search box
Also, given the discussion here: https://github.com/nwjs/nw.js/issues/7504 I am now moving from 0.46.2 to the 0.47.0beta1
NB: menu background color now matches that of the OS theme, so it is not changeable.https://git.purrdata.net/jwilkes/purr-data/-/issues/647Remaining issues for the GOP/toplevel Plots2020-08-27T05:01:24ZIvica BukvicRemaining issues for the GOP/toplevel Plots* last element on the plots is not clickable
* make bezier plot look like bezier (may need to leverage curve_path)
* @jwilkes it looks like the elements not being clickable may be linked to the overall miscalculation of the scalar hitbox...* last element on the plots is not clickable
* make bezier plot look like bezier (may need to leverage curve_path)
* @jwilkes it looks like the elements not being clickable may be linked to the overall miscalculation of the scalar hitbox. See disis_wiimote-help.pd patch and open the subpatch with the 4 blobs (found on the right). Selecting each blob creates a much larger selection box than it should and it is larger the more the object is to the right and down. If you position the object the top left corner of the patch screen, its bbox is near perfect. This is clearly a miscalculation/regression from the port to nw.js as this was not an issue before.
I also edited this issue title since it affects all nw.js versions.Ivica BukvicIvica Bukvichttps://git.purrdata.net/jwilkes/purr-data/-/issues/646Different plots inside GOP tend to either overlap or spill over the GOP edges2020-06-17T19:09:03ZIvica BukvicDifferent plots inside GOP tend to either overlap or spill over the GOP edgesSee attached patch. Note that resizing and zooming can also mess with values. I spent probably good 8 hours tracking this issue, so while I am pleased to report I have this fixed, the upcoming commit has some less user-friendly variable ...See attached patch. Note that resizing and zooming can also mess with values. I spent probably good 8 hours tracking this issue, so while I am pleased to report I have this fixed, the upcoming commit has some less user-friendly variable names as a result of the ensuing mental marathon...[test.pd](/uploads/5afba140b088a47d43daab3eab06f0fe/test.pd)Ivica BukvicIvica Bukvichttps://git.purrdata.net/jwilkes/purr-data/-/issues/642Need to find a consistent scaling value for different OSs to ensure that the ...2020-06-08T05:16:14ZIvica BukvicNeed to find a consistent scaling value for different OSs to ensure that the same window size fits the same amount of contentIvica BukvicIvica Bukvichttps://git.purrdata.net/jwilkes/purr-data/-/issues/641Selecting a large gop when pressing the mouse button shows correct highlight ...2020-06-08T05:26:06ZIvica BukvicSelecting a large gop when pressing the mouse button shows correct highlight bbox, but upon releasing the mouse it gets slightly largerSee L2Ork-Tweet abstraction for an example inside the L2Ork-Tweeter which has 10 instances of it:
http://l2ork.music.vt.edu/main/make-your-own-l2ork/tweeter/See L2Ork-Tweet abstraction for an example inside the L2Ork-Tweeter which has 10 instances of it:
http://l2ork.music.vt.edu/main/make-your-own-l2ork/tweeter/https://git.purrdata.net/jwilkes/purr-data/-/issues/638Selecting any object and pasting bogus stuff (e.g. random text) crashes Purr-...2020-06-19T02:14:06ZIvica BukvicSelecting any object and pasting bogus stuff (e.g. random text) crashes Purr-DataTested on Windows 2.11, likely affects all platforms.Tested on Windows 2.11, likely affects all platforms.https://git.purrdata.net/jwilkes/purr-data/-/issues/637object chain spotlighting2020-05-25T03:41:12ZJonathan Wilkesobject chain spotlightingText-based languages have syntax highlighting.
Here's what a diagram-based language like Purr Data/Pd needs:
1. Select an object or wire.
2. Click some shortcut or menu option.
3. Every object/wire on the canvas that follows that conne...Text-based languages have syntax highlighting.
Here's what a diagram-based language like Purr Data/Pd needs:
1. Select an object or wire.
2. Click some shortcut or menu option.
3. Every object/wire on the canvas that follows that connection gets displayed normally.
4. Every object/wire that is *not* part of that object chain gets less than 1 opacity applied to it
That way the user can view the context of an object chain without being distracted by other parts of the patch outside of that chain.
A good subset of canvas spaghetti could almost be rendered readable if one could interactively highlight the individual noodles.
Almost. :)