Pd-dev June 2014

pd-dev@lists.iem.at

1 participants
16 discussions

[pure-data:patches] #524 cmdline options to undo previous options
by IOhannes m zmölnig via Pd-dev 10 Jun '14

10 Jun '14

--- ** [patches:#524] cmdline options to undo previous options** **Status:** open **Group:** bugfix **Created:** Tue Jun 10, 2014 10:45 AM UTC by IOhannes m zmölnig **Last Updated:** Tue Jun 10, 2014 10:45 AM UTC **Owner:** Miller Puckette currently, Pd has no way to disable a cmdline option. e.g. the flag **-noautopatch** disables the auto-patching feature, but there is no corresponding **-autopatch** flag. similarily, on linux there is no way to switch to the default MIDI-API (*OSS*) once the *alsa*-API has been chosen (using the **-alsamidi** flag). this is annoying in three cases: - *partially overriding preferences:* if the user added some flags to their preferences (e.g. to use alsa-MIDI as the default; or run in verbose mode), they cannot override these defaults on an ad-hoc basis without either completely disabling their preferences (using the **-noprefs** flag) or by modifying them (which they probably don't want to, as these are the settings they *prefer*) - *scripts that call Pd with flags:* some scripts (I use) call Pd with a number of flags that makes them fit for the target purpose (e.g. running on an embedded device, thuse using **-nogui**) and other wise pass cmdline args unchanged to Pd (e.g. the patch to open, the search-paths to use). it is often desirable to be able to override one of these flags for testing purposes (e.g. starting up the GUI when running the script in an interactive session with X-Forwarding) - *binaries with different defaults:* sometimes binaries that pretend to be Pd-vanilla (like the Debian package "puredata") chose slightly different defaults (Debian uses *alsa* as the default MIDI-API, as this provides an out-of-the-box solution for much more people than *OSS*). how to restore the original "defaults"? the attached patch adds a number of additional flags that negate previous settings (e.g. **-gui** to override a **-nogui** flag) when it seems to make sense. i left out the **-prefs** flag (overriding a **-noprefs** option) mainly because this could be useful for specifying an alternative preferences-file (**-prefs /tmp/myotherprefs**). --- 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

[pure-data:bugs] #1147 Puredata and sudo not starting UI.
by Ticket 1147 via Pd-dev 09 Jun '14

09 Jun '14

--- ** [bugs:#1147] Puredata and sudo not starting UI.** **Status:** open **Group:** v0.43 **Created:** Mon Jun 09, 2014 08:35 PM UTC by Anonymous **Last Updated:** Mon Jun 09, 2014 08:35 PM UTC **Owner:** nobody pd is not starting the UI, if started via "sudo -u XX puredata". The problem seems to be that puredata tries to read configuration files from HOME/, which are then not accessible and thus startup stops. What works is: sudo -u XX bash > export HOME=/tmp > puredata Sound devices are opened in both cases. Details: * Pd-0.45.4 ("") compiled 17:28:13 Dec 11 2013 * Ubuntu 14.04 64bit * Linux x201 3.13.0-29-generic #53-Ubuntu SMP Wed Jun 4 21:00:20 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux --- Sent from sourceforge.net because pd-dev(a)lists.iem.at is subscribed to http://sourceforge.net/p/pure-data/bugs/ To unsubscribe from further messages, a project admin can change settings at http://sourceforge.net/p/pure-data/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

1 0

[pure-data:bugs] #1146 iemlib fails to build on linux using externals/Makefile
by Ticket 1146 via Pd-dev 06 Jun '14

06 Jun '14

--- ** [bugs:#1146] iemlib fails to build on linux using externals/Makefile** **Status:** open **Group:** v0.45 **Created:** Fri Jun 06, 2014 07:13 PM UTC by Anonymous **Last Updated:** Fri Jun 06, 2014 07:13 PM UTC **Owner:** nobody I'm doing a custom build of several externals on Linux (Debian Wheezy arm hf on an Udoo board) using the externals Makefile and iemlib fails to build. Adding the following to line 835 after $(CLFAGS) fixes this: -I$(externals_src)/iemlib/include -fPIC --- Sent from sourceforge.net because pd-dev(a)lists.iem.at is subscribed to http://sourceforge.net/p/pure-data/bugs/ To unsubscribe from further messages, a project admin can change settings at http://sourceforge.net/p/pure-data/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

1 0

[pure-data:patches] #523 build (parts of) pd as static library
by IOhannes m zmölnig via Pd-dev 05 Jun '14

05 Jun '14

--- ** [patches:#523] build (parts of) pd as static library** **Status:** open **Group:** wishlist **Labels:** dev libpd **Created:** Thu Jun 05, 2014 12:55 PM UTC by IOhannes m zmölnig **Last Updated:** Thu Jun 05, 2014 12:55 PM UTC **Owner:** Miller Puckette the attached patch makes the autotools-based build-system additionally create most part of the pd as a static library "libpd-core". this static lib can then be used to e.g. build `libpd` without using the copy puredata that comes bundled with libpd itself. (thus avoiding the code-copy) --- 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

type of A_GIMME argc?
by IOhannes m zmoelnig via Pd-dev 02 Jun '14

02 Jun '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 recently, i received a bug-report for the "puredata" Debian-package, that warned of conflicting declarations of the glist_scalar() function. the problem seems to be, that glist_scalar() uses "int argc" for it's A_GIMME argument in the declaration in g_canvas.c, but uses "t_int argc" in the function definition in g_scalar.c. now "t_int" is defined as a "pointer-sized integer", which is a "long int" on amd64, thus incompatible with the 32bit "int". it is often tempting to use "t_int" whenever possible, as it is the Pd-native integer type. unfortunately this can (and will) break binary compatibility in some cases. i think it should be *well documented* which types to use. e.g. the only way to find out how to use A_GIMME is reading the source code (where we have at least 4 occurences that use "t_int" (glist_scalar(), curve_new(), plot_new() and drawnumber_new()) and a lot more (>200) uses of "int". also t_listmethod and t_anymethod in m_imp.h seem to suggest that "int" is the correct type (though "m_imp.h" was historically considered a "private" header, not meant for documentation). i think it's necessary to fix all uses of "t_int argc" to "int argc". additionally i think it would be good to: - - clearly document the function-signature for (A_GIMME) callbacks (and while doing so, move the various callback-typedefs from m_imp.h to m_pd.h) - - split the generic "t_int" type into multiple names, that suggest their usage. afaict, the original use of "t_int" is for the dsp process function (t_perfroutine) , though the name does not suggest anything like this. probably we should move to a new (probably even more pointer-like) type typedef t_perfarg void*; and replace all other uses of t_int (e.g. the return value of "atom_getint()" or the struct-member "t_resample.upsample") by other types, e.g. "int", for compatibility reasons, we might need to keep the two (or more) types the same size, but they should be separated on a semantic level. msdr IOhannes PS: it's pure coincidence that we had this recent conversation on pd-list, where argc was declared "short". [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750168 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJTjEvdAAoJELZQGcR/ejb43zYQAItRxoL1PTtTVOGZsbP8ZPqs prt/bGDQRF9LbyNGGAvLjlQEVIgNTaVf51m/pIoFngif3b9LuBRSPWjjpWirwQeC Xu9wRMzNucuWmxCTAlxqUYFZn30Yl5aqw2KE7nDdo372lY8S130wbhopwRT/i/jX fEQpQqbo3Ub6kRRbHmKbCXAZhbS8APgJiJxZPRYHetkDzqnksHDEi0PrQi+R/5Ko UkoefV7QsTl9uZAEw22HUlmShdSaigh7EMqezWHfXomqu2qU/T6/ho8fF8y65V45 PeE8aXqEOvFW4tKsdQ4i8cIBu+SNxEWNMtTW3ETBxUsBQnmJCvS7/GS4E4anCWzf eA9FmzB7OEyn3LGaZJaON/hAzuL67ICdQJXQvmYkSmr/M1HA5yUj98HTtidLQo/6 LvxvJa0n+EzK4Xrnr7Janna2Un8ySa94L36DV9DpgXS+7NvwUEAfVIBMMfrm8x+i YS7AKjQABN0FukpdeXFTIr4D+eSr0C2Xsk6CcUoAlFa79i1MY2p0EkS7Lj6pXBuv Oo7UMR1ZDCubE+I1xTvGqs0+SkHwuq/ohAFDcA9ZskD5jtNfM1DwAEEOHMvyJiHT 8Q1xJ646ZrSGM12RceRJUEzv2ROexYHXAkm/bfWo883DjGnMlQgaHUQC3/MEdk3p GFrPBNIK5wgf7wned5N7 =whxF -----END PGP SIGNATURE-----

2 2

[pure-data:bugs] #1145 inconsitent type of argc in A_GIMME-callback
by IOhannes m zmölnig via Pd-dev 02 Jun '14

02 Jun '14

--- ** [bugs:#1145] inconsitent type of argc in A_GIMME-callback** **Status:** open **Group:** v0.45 **Labels:** API devel **Created:** Mon Jun 02, 2014 10:11 AM UTC by IOhannes m zmölnig **Last Updated:** Mon Jun 02, 2014 10:11 AM UTC **Owner:** Miller Puckette recently, i received a bug-report for the "puredata" Debian-package, that warned of conflicting declarations of the glist_scalar() function. the problem seems to be, that glist_scalar() uses "int argc" for it's A_GIMME argument in the declaration in g_canvas.c, but uses "t_int argc" in the function definition in g_scalar.c. now "t_int" is defined as a "pointer-sized integer", which is a "long int" on amd64, thus incompatible with the 32bit "int". it is often tempting to use "t_int" whenever possible, as it is the Pd-native integer type. unfortunately this can (and will) break binary compatibility in some cases. i think it should be *well documented* which types to use. e.g. the only way to find out how to use A_GIMME is reading the source code (where we have at least 4 occurences that use "t_int" (glist_scalar(), curve_new(), plot_new() and drawnumber_new()) and a lot more (>200) uses of "int". also t_listmethod and t_anymethod in m_imp.h seem to suggest that "int" is the correct type (though "m_imp.h" was historically considered a "private" header, not meant for documentation). i think it's necessary to fix all uses of "t_int argc" to "int argc". additionally i think it would be good to: - clearly document the function-signature for (A_GIMME) callbacks (and while doing so, move the various callback-typedefs from m_imp.h to m_pd.h) - split the generic "t_int" type into multiple names, that suggest their usage. afaict, the original use of "t_int" is for the dsp process function (t_perfroutine) , though the name does not suggest anything like this. probably we should move to a new (probably even more pointer-like) type typedef t_perfarg void*; and replace all other uses of t_int (e.g. the return value of "atom_getint()" or the struct-member "t_resample.upsample") by other types, e.g. "int", for compatibility reasons, we might need to keep the two (or more) types the same size, but they should be separated on a semantic level. i'm attaching a patch that changes the use of `t_int` to `int` in A_GIMME callbacks. --- 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

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