purr-data issueshttps://git.purrdata.net/jwilkes/purr-data/-/issues2017-10-16T12:24:18Zhttps://git.purrdata.net/jwilkes/purr-data/-/issues/220Release blockers2017-10-16T12:24:18ZAlbert GräfRelease blockersThis is just a "meta" bug report intended to collect all the most annoying issues still open which should probably/hopefully be fixed before the first release.
- #157: the part about changing attributes of the 2nd array in a graph **f...This is just a "meta" bug report intended to collect all the most annoying issues still open which should probably/hopefully be fixed before the first release.
- #157: the part about changing attributes of the 2nd array in a graph **fixed 2017-01-29**
- #209: Packaging issue: RC4 OSX app has wrong name **fixed 2017-01-27**
- #213: secondary midi dev can't (easily) get removed **fixed 2017-01-17**
- #215: fluid~ doesn't load on OSX **fixed 2017-01-27**
- #218: Error when trying to install on OSX **fixed 2017-01-18**
- #222: initial Open path on OSX **fixed 2017-02-05**
- #237: OSX: help browser folder button opens file dialog in wrong folder **fixed 2017-02-05**
@jwilkes, this is from the top of my head and from a quick glance of the issue list, so please add other release blockers that I overlooked.https://git.purrdata.net/jwilkes/purr-data/-/issues/221OSX: no "Open Recent" feature yet?2017-10-16T12:24:18ZEsa RuohoOSX: no "Open Recent" feature yet?Hi, at least the OS X version of pd|lork i dont know Pd-Lork-2016-05-25 does not show any such feature as "open recent" -list?Hi, at least the OS X version of pd|lork i dont know Pd-Lork-2016-05-25 does not show any such feature as "open recent" -list?https://git.purrdata.net/jwilkes/purr-data/-/issues/197dsp-status method of [pdinfo] doesn't give useful info at loadtime2017-10-16T12:24:18ZJonathan Wilkesdsp-status method of [pdinfo] doesn't give useful info at loadtimeCalling [dsp-status(--[pdinfo] at patch load time gives technically correct yet unhelpful output.
This is because dsp is temporarily suspended when loading a toplevel patch.
Since [dsp-status(--[pdinfo] is likely to be used with [loadb...Calling [dsp-status(--[pdinfo] at patch load time gives technically correct yet unhelpful output.
This is because dsp is temporarily suspended when loading a toplevel patch.
Since [dsp-status(--[pdinfo] is likely to be used with [loadbang] the vast majority of the time, it should have a workable interface that doesn't require adding a [delay 0] to get useful output.
RFC: signal whether dsp is being temporarily suspended in the output for the "dsp-status" method of [pdinfo].
I propose the following four possible outputs for [dsp-status(--[pdinfo]:
1. `-1` means dsp is off and dsp is currently suspended
2. `0` means dsp is off and dsp is not currently suspended
3. `1` means dsp is on and dsp is not currently suspended
4. `2` means dsp is on and dsp is currently suspended
This way the user can just do `[loadbang]--[dsp-status(--[pdinfo]--[> 0]` to get sane default behavior in logical time.
This can be acheived by adding a single field to the pd_this struct and querying it in [pdinfo].Jonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/issues/198ubuntu 16.04 runner broken by software updates2017-10-16T12:24:18ZJonathan Wilkesubuntu 16.04 runner broken by software updatesautomatic software updates are probably breaking the ubuntu 16.04 runner by locking out apt:
http://askubuntu.com/questions/855492/apt-get-could-not-open-lock-permanentlyautomatic software updates are probably breaking the ubuntu 16.04 runner by locking out apt:
http://askubuntu.com/questions/855492/apt-get-could-not-open-lock-permanentlyJonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/issues/222OSX: Loading a patch - PDLork20160525 loses previous path in Finder2017-10-16T12:24:18ZEsa RuohoOSX: Loading a patch - PDLork20160525 loses previous path in FinderUnfortunately it looks like the 2016-05-25 build of pdlork loses previous path in Finder - so when you open pdlork for the first time, and press cmd-o, it boots up in either Documents, or inside the pd-package (inside the app). then when...Unfortunately it looks like the 2016-05-25 build of pdlork loses previous path in Finder - so when you open pdlork for the first time, and press cmd-o, it boots up in either Documents, or inside the pd-package (inside the app). then when I maneuver into my PD-folder and load a patch, the next cmd-o (open) will again misplace where I was before.
Are there plans to make user-selected-folders sticky?
also, are there plans to make it so that the user can define a default folder that cmd-o(open) automatically opens to?https://git.purrdata.net/jwilkes/purr-data/-/issues/227$dmg used before set in tar_em_up.sh2017-10-16T12:24:18ZJonathan Wilkes$dmg used before set in tar_em_up.shI mistakenly download the nw.js binary before parsing the command line options. One side effect of this is that the "dmg" variable is used before getting set, which causes a (harmless error) in the OSX build.
Anyhow, the binary downloa...I mistakenly download the nw.js binary before parsing the command line options. One side effect of this is that the "dmg" variable is used before getting set, which causes a (harmless error) in the OSX build.
Anyhow, the binary downloading logic should be moved below the option parser. Also, if we use "curl" to fetch the binary we can specify one less dependency in the build instructions.https://git.purrdata.net/jwilkes/purr-data/-/issues/200something somewhere in gnu make breaks dmg target for OSX2017-10-16T12:24:18ZJonathan Wilkessomething somewhere in gnu make breaks dmg target for OSXCheck out this line from the build script from the OSX runner at
https://git.purrdata.net/jwilkes/purr-data/builds/2305/raw
`install: /Users/user/builds/jwilkes/purr-data/packages/darwin_app/build/Pd-l2ork-full-x86_64-20161210.app/...Check out this line from the build script from the OSX runner at
https://git.purrdata.net/jwilkes/purr-data/builds/2305/raw
`install: /Users/user/builds/jwilkes/purr-data/packages/darwin_app/build/Pd-l2ork-full-x86_64-20161210.app/Contents/Resources/app.nw/doc/manuals/Pd/ReadMe.html: No such file or directory`
The date in the first path comes from `$(DESTDIR)`, which depends on `$(PD_APP_CONTENTS)`, which depends on `$(PD_APP_NAME)`, which depends on `$(PACKAGE_NAME)`, which is defined in `../Makefile.buildlayour` and depends on `$(PD_VERSION)`, which is set in immediate-parsing-mode (or whatever the hell you call the sane assignment operator `:=` in Gnu make lingo) to `$(PD_TEST_VERSION)`, which is set to the PD_TEST_VERSION define inside m_pd.h.
Hmm-- that's not the correct value for test version from m_pd.h. It should be "20160525"...
Now witness the madness earlier in the log:
`rsync -ax /Users/user/builds/jwilkes/purr-data/pd/nw/nw/nwjs.app/ /Users/user/builds/jwilkes/purr-data/packages/darwin_app/build/Pd-l2ork-full-`uname -m`-20160525.app/`
That date comes from `$(PD_APP_NAME)`, which is set in lazy-parsing-mode to `$(PACKAGE_NAME)`...
Wait, we just went through this. So why is the latter the correct test version of m_pd.h and the former is the current date?
This is keeping the OSX runner from successfully building an OSX dmg installer. However, I can successfully build manually by going in packages/darwin_app and doing `make clean && make install && make package`. That makes me think there's some mutation happening somewhere in the vomit of recursively-set global state that is Gnu make...https://git.purrdata.net/jwilkes/purr-data/-/issues/228use pd-l2ork paths in sys_setextrapath2017-10-16T12:24:18ZJonathan Wilkesuse pd-l2ork paths in sys_setextrapathsys_setextrapath in s_path.c should use pd-l2ork subdir names for OSX and Windows.
Currently it only uses pd-l2ork dirs on Gnu/Linux.sys_setextrapath in s_path.c should use pd-l2ork subdir names for OSX and Windows.
Currently it only uses pd-l2ork dirs on Gnu/Linux.https://git.purrdata.net/jwilkes/purr-data/-/issues/201Does not remember new canvas position after saving (Windows 64-bit)2017-10-16T12:24:18ZmyQwilDoes not remember new canvas position after saving (Windows 64-bit)In order to change the position of a canvas, I have to open the patch in pd-vanilla and re-position from there.In order to change the position of a canvas, I have to open the patch in pd-vanilla and re-position from there.https://git.purrdata.net/jwilkes/purr-data/-/issues/225Help browser: Bad arguments for message 'open' to object 'pd'2017-10-16T12:24:18ZAlbert GräfHelp browser: Bad arguments for message 'open' to object 'pd'Here's one way to reproduce this:
- Open the help browser.
- Click the folder icon.
- In the Open File dialog, open any help patch.
- Click the folder icon again.
- In the Open File dialog, click Cancel.
This always gives the error mes...Here's one way to reproduce this:
- Open the help browser.
- Click the folder icon.
- In the Open File dialog, open any help patch.
- Click the folder icon again.
- In the Open File dialog, click Cancel.
This always gives the error message `error: Bad arguments for message 'open' to object 'pd'` in the console. I can reproduce this on both Linux and Mac.https://git.purrdata.net/jwilkes/purr-data/-/issues/229Startup prefs: lots of dialog data causing issues on OSX when transmitting fr...2017-10-16T12:24:18ZAlbert GräfStartup prefs: lots of dialog data causing issues on OSX when transmitting from GUI to engineTo reproduce: open the prefs dialog on OSX, hit Ok => spurious error message `error: mento: no such object` in the console (which obviously comes either from the /Applications/Pd-l2ork-full-x86_64-20161113.app/Contents/Resources/app.nw/e...To reproduce: open the prefs dialog on OSX, hit Ok => spurious error message `error: mento: no such object` in the console (which obviously comes either from the /Applications/Pd-l2ork-full-x86_64-20161113.app/Contents/Resources/app.nw/extra/memento entry in the search paths or the memento entry in the startup libraries).
This isn't a whitespace issue. I've tested search paths with embedded blanks -- sending these to the engine does work fine (on Linux at least), and the code properly encodes the pathnames using the dialog-save encoding before submitting them. Also, the error message changes when trying to insert a search path at the beginning of the table.
So it seems that lots of dialog data (which translates into lots of string arguments for pd_send and thus lots of string data being submitted over the socket) causes issues with pdgui.pd_send on some platforms (this doesn't happen on Linux); might be caused by socket buffer limits.
Possible solution: Transmit the search paths and startup libraries data one-by-one. Tedious and slow, but doable.
This should be considered a release blocker (#220). Working on it...https://git.purrdata.net/jwilkes/purr-data/-/issues/230Recent files on OSX: Unicode filenames get munged after saving to and reading...2017-10-16T12:24:18ZAlbert GräfRecent files on OSX: Unicode filenames get munged after saving to and reading back from persistent config data (OSX defaults)The superficial symptom is that items from the Recent files list seem to disappear when relaunching Purr Data on OSX, which doesn't happen on Linux.
Digging into this, I found that Unicode characters like `Ü` become `U\u0308` (with the ...The superficial symptom is that items from the Recent files list seem to disappear when relaunching Purr Data on OSX, which doesn't happen on Linux.
Digging into this, I found that Unicode characters like `Ü` become `U\u0308` (with the literal ASCII character sequence "\u0308", not the code point \u0308!) in the recentX defaults value on OSX. Obviously the Unicode glyph Ü a.k.a. U\u0308 gets "translated" to the literal 7-character sequence "U\u0308" when storing the defaults value. It seems that the defaults saving code is to blame here (which works by running the defaults program via system() on OSX), since sending the filename from the GUI to the engine seems to work ok (otherwise none of the open and save operations would work with such filenames on OSX).https://git.purrdata.net/jwilkes/purr-data/-/issues/226remove unnecessary -L/sw/lib linker flag for externals2017-10-16T12:24:18ZJonathan Wilkesremove unnecessary -L/sw/lib linker flag for externalsSome externals makefiles seem to have fink's "-L/sw/lib" path hard-coded in them.
This creates a linker warning, so we should probably remove this flag.Some externals makefiles seem to have fink's "-L/sw/lib" path hard-coded in them.
This creates a linker warning, so we should probably remove this flag.https://git.purrdata.net/jwilkes/purr-data/-/issues/231Launching pdlork on OSX - says "Pd started." but user needs to still wait 15-...2017-10-16T12:24:18ZEsa RuohoLaunching pdlork on OSX - says "Pd started." but user needs to still wait 15-20 seconds (mid-2009 MBP) before the app worksWhen I first moved from PD Vanilla to PDlork/PurrData, the first thing I had was, I'd boot up pdlork and immediately load up a patch. And nothing would happen.
I then realized that even though pdlork says "Pd started.", I gotta wait 1...When I first moved from PD Vanilla to PDlork/PurrData, the first thing I had was, I'd boot up pdlork and immediately load up a patch. And nothing would happen.
I then realized that even though pdlork says "Pd started.", I gotta wait 15-20 seconds before it is actually ready to be used. It then outputs this stuff:
`incoming connection to GUI
canvasinfo: v0.1
stable canvasinfo methods: args dir dirty editmode vis
pdinfo: v.0.1
stable pdinfo methods: dir dsp version
classinfo: v.0.1
stable classinfo methods: size
objectinfo: v.0.1
stable objectinfo methods: class
[import] $Revision: 1.2 $
[import] is still in development, the interface could change!
compiled against Pd-l2ork version 20170122
libdir loader 1.9
compiled on Jan 22 2017 at 20:09:36
compiled against Pd version 0.42.7.20170122
Gem: can't load library
libdir_loader: added 'cyclone' to the global objectclass path
libdir_loader: added 'zexy' to the global objectclass path
libdir_loader: added 'creb' to the global objectclass path
libdir_loader: added 'cxc' to the global objectclass path
libdir_loader: added 'iemlib' to the global objectclass path
libdir_loader: added 'list-abs' to the global objectclass path
libdir_loader: added 'mapping' to the global objectclass path
libdir_loader: added 'markex' to the global objectclass path
libdir_loader: added 'maxlib' to the global objectclass path
libdir_loader: added 'memento' to the global objectclass path
libdir_loader: added 'mjlib' to the global objectclass path
libdir_loader: added 'motex' to the global objectclass path
libdir_loader: added 'oscx' to the global objectclass path
libdir_loader: added 'pddp' to the global objectclass path
libdir_loader: added 'pdogg' to the global objectclass path
libdir_loader: added 'pixeltango' to the global objectclass path
libdir_loader: added 'rradical' to the global objectclass path
libdir_loader: added 'sigpack' to the global objectclass path
libdir_loader: added 'smlib' to the global objectclass path
libdir_loader: added 'unauthorized' to the global objectclass path
vbap - v1.1 - 14 Aug. 2014 - (c) Ville Pulkki 1999-2006 (Pd port by HCS)
libdir_loader: added 'pan' to the global objectclass path
libdir_loader: added 'hcs' to the global objectclass path
libdir_loader: added 'jmmmp' to the global objectclass path
libdir_loader: added 'ext13' to the global objectclass path
libdir_loader: added 'ggee' to the global objectclass path
libdir_loader: added 'ekext' to the global objectclass path
PDP: pure data packet version 0.12.7
libdir_loader: added 'disis' to the global objectclass path
libdir_loader: added 'lyonpotpourri' to the global objectclass path`
and THEN it's ready to be used. Could there be some sort of warning of this long haul of preparation being, well, in preparation - before Pd is actually started? Like some sort of "loading extra libraries" or something. I'm perfectly fine (no I'm not!) waiting 15-20 seconds for pdlork/purrdata to get it's default extensions (don't know what they're called?) loaded, but it would be nice to know that something extra is being done.https://git.purrdata.net/jwilkes/purr-data/-/issues/232Runtime executable available for Windows?2017-10-16T12:24:18ZEsa RuohoRuntime executable available for Windows?Hi! I now have the opportunity to install pdlork/purrdata on a Windows 10 computar. I was attempting to figure out where to download an executable installer - is there such a thing?Hi! I now have the opportunity to install pdlork/purrdata on a Windows 10 computar. I was attempting to figure out where to download an executable installer - is there such a thing?https://git.purrdata.net/jwilkes/purr-data/-/issues/234is osx dmg from gitlab ci loading external libdirs?2017-10-16T12:24:18ZJonathan Wilkesis osx dmg from gitlab ci loading external libdirs?Can someone check if the OSX dmg adds the external libdirs to the global path?
https://git.purrdata.net/jwilkes/purr-data/builds/3035/artifacts/browseCan someone check if the OSX dmg adds the external libdirs to the global path?
https://git.purrdata.net/jwilkes/purr-data/builds/3035/artifacts/browsehttps://git.purrdata.net/jwilkes/purr-data/-/issues/235s_stuff.h.in breaks windows build2017-10-16T12:24:18ZJonathan Wilkess_stuff.h.in breaks windows buildThe build on Windows still uses "makefile.mingw" instead of makefile.in. So one of two options:
1. Copy/paste the s_stuff.h.in changes into makefile.mingw
2. Change the windows build so that it uses the same core Pd build scripts that ...The build on Windows still uses "makefile.mingw" instead of makefile.in. So one of two options:
1. Copy/paste the s_stuff.h.in changes into makefile.mingw
2. Change the windows build so that it uses the same core Pd build scripts that OSX and Gnu/Linux do.https://git.purrdata.net/jwilkes/purr-data/-/issues/237OSX: help browser folder button opens file dialog in wrong folder2017-10-16T12:24:18ZAlbert GräfOSX: help browser folder button opens file dialog in wrong folderOn OSX, the folder icon in the help browser opens / (the root folder) on OSX. It should open the app.nw/doc folder instead.
I already have a fix for this, but will have to check whether that doesn't break things on Linux. Expect a merge...On OSX, the folder icon in the help browser opens / (the root folder) on OSX. It should open the app.nw/doc folder instead.
I already have a fix for this, but will have to check whether that doesn't break things on Linux. Expect a merge request soon.https://git.purrdata.net/jwilkes/purr-data/-/issues/239latch~ kills purr data2017-10-16T12:24:18ZAlexandre Porreslatch~ kills purr datatested with rc5 in mac os (rc4 was also getting killed so it is old)
I'm also reporting this to Eric
https://github.com/ericlyon/lyonpotpourri3.0-64bit/issues/2tested with rc5 in mac os (rc4 was also getting killed so it is old)
I'm also reporting this to Eric
https://github.com/ericlyon/lyonpotpourri3.0-64bit/issues/2https://git.purrdata.net/jwilkes/purr-data/-/issues/241full ci and automated release deployment needed2017-10-16T12:24:18ZJonathan Wilkesfull ci and automated release deployment neededCI
--
1. (DONE) An extra flag must be added to tar_em_up.sh for building OSX 10.8 (i.e., using nw.js 14.7 lts instead of the current one which doesn't run on older OSX versions)
2. windows ci runner for both 32-bit and 64-bit nw.js
...CI
--
1. (DONE) An extra flag must be added to tar_em_up.sh for building OSX 10.8 (i.e., using nw.js 14.7 lts instead of the current one which doesn't run on older OSX versions)
2. windows ci runner for both 32-bit and 64-bit nw.js
3. armv7l ci runner
Deployment
----------
1. Need to have a way to deploy binaries for releases from *this* gitlab instance. Only thing I can think is to start a dev branch for CI where the binaries expire after a day or two, and to merge with the main branch for releases. Then the main branch could have artifacts that never expire.
Edit: For CI, there's also a *critical* upstream patch that needs to get merged for the gitlab runner binary:
https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/merge_requests/313
Unless that gets merged I'm pretty much the only person who will be able to set up a reliable build farm.