Pd-dev May 2016

pd-dev@lists.iem.at

19 participants
21 discussions

double menu bindings
by Dan Wilcox 10 May '16

10 May '16

On a related note to the zoom bindings, I’m wondering why we have keybindings for the canvas window in two places: pd_menus.tcl & pd_bindings.tcl? When switching to tk 8.5 on Mac, I noticed that the iem gui creation hot keys (Shift+Command+B for bng, etc) result in 2 objects being created. This was not the case with Tk 8.4 and might be related to how the shift key was being handled. Also, this is happening with *anything* that has a shift binding such as “Save As” opening 2 dialogs and “Redo” bing called twice. Anyway, commenting out the -command settings for each men item that uses shift in ::pd::menus::build_put_menu fixes the issue as far as I can tell as the global key bindings catch it. This is something I’ll throw up into a branch when I lock down updates for tk 8.5 on OSX soon. It will need to be tested on other platforms. -------- Dan Wilcox @danomatika <https://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

2 4

taking autobuilds down?
by IOhannes m zmölnig 09 May '16

09 May '16

hi, a couple of years ago, hans has set up an autobuild farm for Pd-extended. unfortunately hans has shifted focus to more wondrous things and Pd-extended has faded away. only the autobuilders are still running. this wouldn't be a problem (apart from global warming and all *that*), if the autobuilders would actually do something meaningful. as it stands, the only signs of life we had from those machines for months have been a daily(!) panic mail to the pd-cvs list, detailing how the build failed. actually it's not even the build that fails, but - it seems - only the final upload of the build artefacts. (though that doesn't matter much: at the end the autobuild is for naught, as there is no build artefact available for general consumption). i doubt that anybody ever reads one of those emails. for me, they are just spamming my mailbox. apart from that, the build artefacts that are produced are Pd-extended-0.44 on Debian squeeze (and later): proving that a package that was obsolete before it was ever released can be build on a system where the even the long-term support was terminated... i would therefore like to ask the maintainers of the autobuild farm to - either fix the build script so it actually succeeds in what it is doing - OR turn off the autobuilds i would prefer the 2nd option. i'm writing this to this list, since according to [1] this is the official address for the PdLab autobuild farm. it seems that all active autobuilders are hosted by the hfbk, but i don't have any more specific contact. mfgdsar IOhannes http://puredata.info/docs/developer/PdLab

2 2

[pure-data:bugs] #1242 pd-0.47-0 tarball misses ./configure
by Claude Heiland-Allen 09 May '16

09 May '16

--- ** [bugs:#1242] pd-0.47-0 tarball misses ./configure** **Status:** open **Group:** v0.46 **Labels:** buildsystem **Created:** Mon May 09, 2016 03:50 PM UTC by Claude Heiland-Allen **Last Updated:** Mon May 09, 2016 03:50 PM UTC **Owner:** nobody The tarball for the source release misses ./configure - using ./autogen.sh requires lots of developer tools which aren't necessary if ./configure is included in the tarball (which afaik is the recommended way to release, with configure pre-generated by the developer). --- Sent from sourceforge.net because pd-dev(a)lists.iem.at is subscribed to https://sourceforge.net/p/pure-data/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pure-data/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

1 0

Double loading suceeded...
by Winfried Ritsch 09 May '16

09 May '16

Not really a problem but I think not really correct and maybe already reported: I have a in an folder main.pd and searchme.pd and start pd i got on the console: $ pd -verbose main.pd tried /home/winfried/tmp/test_load/main.pd and succeeded tried /home/winfried/tmp/test_load/searchme.l_ia64 and failed tried /home/winfried/tmp/test_load/searchme.pd_linux and failed tried /home/winfried/tmp/test_load/searchme/searchme.l_ia64 and failed tried /home/winfried/tmp/test_load/searchme/searchme.pd_linux and failed tried /home/winfried/tmp/test_load/searchme.pd and succeeded tried /home/winfried/tmp/test_load/searchme.pd and succeeded Note the double suceeded lines. $ pd -verbose searchme.pd tried /home/winfried/tmp/test_load/searchme.pd and succeeded which is correct. I also notices double suceeded on loading externals: like the [acre/acre/initbang] from deken installed acre lib (last lines): [...] tried /home/winfried/pd-externals/acre/acre/initbang/initbang.l_ia64 and failed tried /home/winfried/pd-externals/acre/acre/initbang/initbang.pd_linux and failed tried /home/winfried/pd-externals/acre/acre/initbang.pd and succeeded tried /home/winfried/tmp/test_load/acre/acre/initbang.pd and failed tried /home/winfried/pd-externals/acre/acre/initbang.pd and succeeded see double succeeded line If this an unkown behaviour I can have a look in the s_loader.c mfg winfried -- -- - ao.Univ.Prof. DI Winfried Ritsch - ritsch(a)iem.at - http://iem.at/ritsch - Institut of Elektronic Music and Acoustics - University of Music and Dramatic Art Graz - Tel. ++43-316-389-3510 (3170) Fax ++43-316-389-3171 --

2 2

Double loading suceeded...
by Winfried Ritsch 08 May '16

08 May '16

1 0

Improving portability of the thread management
by Pierre Guillot 07 May '16

07 May '16

PD uses the pthread library, but with MVC this can be really annoying. The project pthread-win32 offers a dynamic version of the library for Windows but no static version. If you compile the static library, you have to change the code because there are linking problems with MVC. I think it would be better to use Windows thread system. The main problem comes from the file "d_soundfile.c". I made a small wrapper ( https://github.com/pierreguillot/thread) and if you're interested I can try to integrate this in PD. I have several questions before. Should I use a wrapper for pthread and "WinThread" or should I make a wrapper only for WinThread that allows to use the pthread function prototypes. I already have the two solutions. I don't know if the sys_lock/sys_unlock/sys_trylock functions (in m_sched.c) are really necessary in a context like libpd. The problem is that we can't have a static initializer for Windows critical sections, so we must use something like void sys_lock_init and sys_lock_destroy. For the moment, in my project I use the preprocessor definition THREAD_LOCKING=0 to avoid this part of the code but I think it would be better to enable this feature, in case someone uses it in an external. Cheers

2 3

Autotools Updates
by Dan Wilcox 06 May '16

06 May '16

Howdy again all, After quite a few days of digging into the pd autotools system, I put forward the work in the autotools_branch on Github: https://github.com/pure-data/pure-data/pull/16 <https://github.com/pure-data/pure-data/pull/16> You can grab is using: git clone https://github.com/pure-data/pure-data.git <https://github.com/pure-data/pure-data.git> -b autotools_updates I basically went through and updated the configure/makefile system so that it builds on newer versions of OSX, has a lot more configure options, and is cleaned up to aid maintainability. Also, finishing a make results in a bin folder like the src/makefile builds so using in place is easier. Last, for OSX, you can now build an .app bundle via: make app. Details are in the PR discussion. At this point, I’d like to know if it builds fine on other platforms and, moving forward, would like feedback on the overall changes. I am also totally willing to update the documentation and add more commenting to the configure.ac & Makefile.am’s to aid maintainability & understanding as I now autotools is, in some ways, black magic. :) -------- Dan Wilcox @danomatika <https://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

2 4

loading an external from gui-plugin (or vice-versa)
by IOhannes m zmölnig 03 May '16

03 May '16

i'm developing a little something that consists of a gui-plugin and some library running on the pd-core side. the gui plugin does not make any sense without the library loaded and vice-versa. so i'm looking for the best way to a1) load an external from a gui-plugin OR a2) load a gui-plugin from an external AND/OR b) check from one side that the other side is initialized properly. all of the above should not make any assumptions about the OS. all of the above should work without any nasty trace-back errors. instead, i would like to do the error-reporting myself (a traceback is cool for a dev; less so for a user) ad a1) i was thinking about abusing one of the invisible template-canvases to instantiate a dummy object that triggers the library load (e.g. "_float_template"). are there any pitfalls that i should be aware of? ad a2) the main reason or writing a GUI-plugin is to get rid of any tcl/tk hard-coded into the C-plugin. i guess sending a command like "load_plugin_script mycoolthing" is platform agnostic enough for my needs. however, it seems that the only way to load a plugin is currently by specifying the full filename: "load_plugin_script mycoolthing.tcl"; hmpf it also throws a nasty error if Pd cannot find the GUI-plugin: > Tcl) UNHANDLED ERROR: couldn't open "mycoolthing.tcl": no such file or directory ad b) the basic idea is to have a ping-function on the *other* side, that replies with a "hi, i'm here" when called. so far i've found two options: b1) create a proc in the plugin, and call that directly from the core; or b2) have the GUI register a plugin-receiver that does the dispatching. unfortunately both solutions give me a backtrace when the GUI-plugin has not been instantiated (and the point of the exercise is to avoid a backtrace) ideas?

2 2

[pure-data:patches] #577 sys_startgui: unnecessary listening after connection
by Tito Latini 02 May '16

02 May '16

--- ** [patches:#577] sys_startgui: unnecessary listening after connection** **Status:** open **Group:** bugfix **Created:** Mon May 02, 2016 10:05 AM UTC by Tito Latini **Last Updated:** Mon May 02, 2016 10:05 AM UTC **Owner:** nobody **Attachments:** - [0001-sys_startgui-unnecessary-listening-after-connection.patch](https://sou… (1.5 kB; text/x-patch) It seems a known problem (OOPS branch). --- Sent from sourceforge.net because pd-dev(a)lists.iem.at is subscribed to https://sourceforge.net/p/pure-data/patches/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pure-data/admin/patches/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

1 0

64 bit windows pointer size
by Dan Wilcox 02 May '16

02 May '16

Throwing another GH PR in the mix: https://github.com/pure-data/pure-data/pull/7 <https://github.com/pure-data/pure-data/pull/7> Basically sets the correct pointer size on 64 bit Windows. -------- Dan Wilcox @danomatika <https://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pd-dev May 2016