Pd-dev December 2012

pd-dev@lists.iem.at

14 participants
173 discussions

[ pure-data-Bugs-3598740 ] renaming delay into buffer size
by SourceForge.net 28 Dec '12

28 Dec '12

Bugs item #3598740, was opened at 2012-12-28 05:14 Message generated for change (Tracker Item Submitted) made by maxn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3598740&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: v0.44 Status: Open Resolution: None Priority: 5 Private: No Submitted By: max (maxn) Assigned to: Nobody/Anonymous (nobody) Summary: renaming delay into buffer size Initial Comment: something between a feature request and a usability bug: i think it would make the audio properties clearer if instead of "delay (ms)" it would read either of those instead: buffer (ms) buffer size (ms) I/O buffer size (ms) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3598740&group_…

1 0

[ pure-data-Patches-3598153 ] fix type punning issue in bsaylor/svf~
by SourceForge.net 28 Dec '12

28 Dec '12

Patches item #3598153, was opened at 2012-12-22 05:59 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3598153&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: externals Group: bugfix >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Katja (katjav) Assigned to: Nobody/Anonymous (nobody) Summary: fix type punning issue in bsaylor/svf~ Initial Comment: bsaylor/svf~.c uses a type punning method to avoid / eliminate subnormal numbers. When compiled with -ftree-vectorize, the object doesn't give signal output. Compiler warnings: svf~.c: In function 'run_svf': svf~.c:60: warning: dereferencing type-punned pointer will break strict-aliasing rules svf~.c:61: warning: dereferencing type-punned pointer will break strict-aliasing rules ... cc1: warning: -ftree-vectorize enables strict aliasing. -fno-strict-aliasing is ignored when Auto Vectorization is used. File bsaylor_svf~-type-punning-fix.patch fixes the issue by using PD_BIGORSMALL() function instead. ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2012-12-27 21:13 Message: accepted with this commit: http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revision&revisio… ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3598153&group_…

1 0

[ pure-data-Bugs-3598530 ] toggle display not updated everytime
by SourceForge.net 26 Dec '12

26 Dec '12

Bugs item #3598530, was opened at 2012-12-26 07:54 Message generated for change (Tracker Item Submitted) made by ceplatel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3598530&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pd-extended Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Charles Platel (ceplatel) Assigned to: Hans-Christoph Steiner (eighthave) Summary: toggle display not updated everytime Initial Comment: Pd version 0.43.4-extended 20121226. Mac Pro OSX Lion or MacbookPro Snow Leopard The toggle GUI object display is not updated anymore when receiving data messages. But OK when receiving bangs, position, size or color messages. To test, see the toggle-help.pd patch and try it. However the toggle display can be refreshed by minimizing, then maximizing the Finder window or sending a color message, for example. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3598530&group_…

1 0

tclpd vs unicode on GNU/Linux
by Hans-Christoph Steiner 24 Dec '12

24 Dec '12

Hey Federico, I just finished getting full unicode support on Pd-extended 0.43.4 and ran into a bizarre problem. It turns out that when tclpd is loaded by default, Pd freaks out on some Portugeuse text like "modulação". Replace the ç and ã with c and a, and the problem goes away. Or stop loading tclpd at startup and the problem goes away. I attached the patch in question. This only happens on GNU/Linux, Windows and Mac OS X are unaffected. I tried looking around the code, and using strace to follow the function calls, but I didn't see anything. I'd like to be able to include tclpd by default in Pd-extended, but this is a show stopper. .hc

1 1

[ pure-data-Bugs-3598318 ] AVG detects threat
by SourceForge.net 24 Dec '12

24 Dec '12

Bugs item #3598318, was opened at 2012-12-24 04:41 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3598318&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pd-extended Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Hans-Christoph Steiner (eighthave) Summary: AVG detects threat Initial Comment: [import] $Revision: 1.2 $ [import] is still in development, the interface could change! compiled against Pd version 0.42.5 Running this immediately causes AVG Identity Protection to flag up "threat detected" for \pd\bin\pd.exe ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3598318&group_…

1 0

[ pure-data-Patches-3598256 ] OpenBSD support
by SourceForge.net 23 Dec '12

23 Dec '12

Patches item #3598256, was opened at 2012-12-23 13:06 Message generated for change (Tracker Item Submitted) made by fgsch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3598256&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Federico Schwindt (fgsch) Assigned to: Nobody/Anonymous (nobody) Summary: OpenBSD support Initial Comment: With this it compiles and runs under OpenBSD. I still need to do some more testing but I think this is good to go. This was originally from #3581737 but apparently I cannot add another file to the report so opening a new one. Please let me know. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3598256&group_…

1 0

[ pure-data-Patches-3581737 ] OpenBSD support
by SourceForge.net 23 Dec '12

23 Dec '12

Patches item #3581737, was opened at 2012-10-29 16:36 Message generated for change (Comment added) made by fgsch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3581737&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: None >Status: Pending Resolution: Fixed Priority: 5 Private: No Submitted By: Federico Schwindt (fgsch) Assigned to: Nobody/Anonymous (nobody) Summary: OpenBSD support Initial Comment: FIrst round of patches to add support for OpenBSD. ---------------------------------------------------------------------- >Comment By: Federico Schwindt (fgsch) Date: 2012-12-23 13:03 Message: Looks like I cannot add another file to this so I will open a new report and attach the diff there. Putting the status back to pending. ---------------------------------------------------------------------- Comment By: Federico Schwindt (fgsch) Date: 2012-12-23 10:47 Message: Apologies for the silence, I just returned from holidays. The changes have helped to some extent but more work is required at least for OpenBSD. I will add the patch here once I get everything sorted. btw, why you have used stddef.h for alloca? This is not correct but I'm curious where you get the idea from. ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2012-11-26 11:44 Message: OK, added the ifdefs, tested on linux (makefile.gnu) and MSVC (makefile.msvc) , and pushed to git - please report back if there are problems on other platforms. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2012-11-20 12:00 Message: that looks good to me, Miller, but I don't know the BSD stuff. ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2012-11-20 09:08 Message: I think HAVE_ALLOCA_H is traditionally used to indicate the existence of a file, "alloca.h" which apparently doesn't exist in MSVC. I'm no longer worried about how we can get teh makefiles set up but rather what should go in the C code... at teh moment I believe it #ifdef HAVE_ALLOCA_H # include <alloca.h> /* linux, mac, mingw, cygwin */ #elif defined _MSC_VER # include <malloc.h> /* MSVC */ #else # include <stddef.h> /* BSDs for example */ #endif ... and that I can put that in, clean out the "old" autoconf stuff and voila. Do we all think that that work OK? ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2012-11-20 08:51 Message: or don't use config.h at all, add /D=HAVE_ALLOCA_H to makefile.nt (for those compiling on w32 using msvc) and use AC_CONFIG_HEADERS(alloca.h) for the systems that use autoconf. i doubt whether anybody involved in writing configure.ac has done the testing on all platforms known to compile Pd before submitting changes. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2012-11-19 19:46 Message: if you really think its worth your time, then go ahead and prepare a patch that you've tested on OpenBSD, GNU/Linux, Windows, Mac OS X, iOS, Android, Rockbox, and Microsoft Visual Studio. IMHO, things are working well as they are. ---------------------------------------------------------------------- Comment By: Federico Schwindt (fgsch) Date: 2012-11-19 15:01 Message: Not necessarily. You can supply pre-generated config.h for some platforms (that are obviously not going to change) and generate one for the rest. So basically if you're using autoconf you could use AC_CONFIG_HEADERS, if not just supply a config.h with all the defines for that platform. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2012-11-19 11:02 Message: AC_CONFIG_HEADERS works fine if your code is only built by the single autotools build system. In Pd's case, there are multiple build systems because of all of the platforms it runs on. There is configure.ac for UNIX and MinGW, src/makefile.nt for Microsoft Visual Studio, libpd for Android, iOS and more. Pd is also included in Rockbox. So using some auto-tools things makes it harder on the other platforms. ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2012-11-19 08:03 Message: I'm preparing to throw out the old "configure" stuff (which, by the way, I didn't originate and which I've tried and failed to understand; for some reason I never got AC_CONFIG_HEADERS() to work). But I'd still like to know what a good way to declare alloca(0 in a C file is. The autoconf web site suggests that I cut and past a 16-line #ifdef mess into every c file using alloca() .. perhaps under the "new" (autogen) system something shorter would work, but I'd want to have some confidence I'm doing something reasonable. ---------------------------------------------------------------------- Comment By: Federico Schwindt (fgsch) Date: 2012-11-17 19:37 Message: unfortunately you're wrong. alloca is not posix so i wouldn't expect any agreement here. as i said openbsd doesn't have alloca.h. i would not be surprised if other bsd are the same. malloc.h is also incorrect. here alloca's prototype is in stdlib.h. i will prepare a diff to add the maze of defines in all the configures and what not but I really fail to see why you can simply use AC_CONFIG_HEADERS() since you're already depending on configure. ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2012-11-17 15:03 Message: I went ahead and applied the patch by hand. I could be wrong, but isn't there now an alloca() function and an alloca.h on all unix-likes? and an alloca() defined in Windows? If so we can blow off all the configuration stuff and just conditionall include alloca or malloc.h depending on whether we're Windows. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2012-11-13 15:45 Message: no not really. afaiu the plan is to add a check for "alloca.h" to configure, which willl define HAVE_ALLOCA_H if the file is found. if HAVE_ALLOCA_H is defined alloca.h will get included. now the current behaviour is to include alloca.h in any case. but if the include is protected, then the build-system has to actively define HAVE_ALLOCA_H in order keep the old behaviour. simply ignoring the other build-systems might break them. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2012-11-13 11:45 Message: I think you'll be safe only touching the ./configure.ac and Makefile.ams. Miller seems to want to hold only to the old, crufty src/configure.in build, but he doesn't use OpenBSD. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2012-11-06 05:13 Message: #1 yes, the build-system is messed up (or rather, it is in a state of transition) #2 .../src/configure adds HAVE_foo to CPPFLAGS (and .../configure adds it to DEFS), which get expanded in the resp. makefiles (so technically you are right, they don't get added to CFLAGS) #3 i said "makefile.nt" and not "makefile.in", which is the 3rd(!) build-system that is there and which is used to build on w32 using MSVC. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2012-11-06 04:45 Message: I might be missing something but unless you add it manually I don't see where configures adds the HAVE_XXX to CFLAGS unless you do it manually. And src/makefile.in is processed by src/configure(.in) so only ../configure.ac and ../src/configure.in need to be modified. <rant> You have a pretty messed up build system. </rant> ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2012-11-06 03:57 Message: if the patch comes from git, then please create a branch, commit to that and then create a patch-set using "git format-patch master". as for the HAVE_ALLOCA_H: if you don't instruct configure to write defines into config.h, it will add them to the CFLAGS, so that the compilation will still work. thus, no need to change the build-system. bear in mind though, that currently Pd uses to separate build-systems: .../configure.ac and .../src/configure.in (and .../src/makefile.nt); you might need to modify all 3 in order to get accepted (yes, it's a PITA) ---------------------------------------------------------------------- Comment By: Federico Schwindt (fgsch) Date: 2012-11-06 02:48 Message: @zmoelnig: The patch comes from git. My main concern is how to proceed with the other changes that require more changes than just extending an existing ifdef. For example the exclusion of alloca.h, etc. In my git clone I've modified configure to use config headers and so I can do ifdef HAVE_ALLOCA_H, etc. but I'm not sure if such patches will be accepted. The reason I've break them down is so they can be committed while I understand what your preference is. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2012-11-06 02:39 Message: this patch is simple enough (almost trivial) as it only adds "#ifdef __OpenBSD__" to the clauses that are already handled by "__FreeBSD__". i don't see a reason to not include it (but of course this all depends on miller). small note on patches: - the patch doesn't apply here (`patch` thinks the diff is garbage) - Pd is developped in git; it would be great if you could generate your patches using git as well; see [1] - as for atomicity of patches: personally i think creating a (few) smaller patches is not a real problem; make sure that those patches are logical units rather than reflecting your iterative trial-and-error history to fix a problem. then attach all patch files to this ticket (rather than creating a new patchtracker-ticket for each file) [1] http://puredata.info/docs/developer/GitWorkflows/ ---------------------------------------------------------------------- Comment By: Federico Schwindt (fgsch) Date: 2012-11-06 02:03 Message: Comments please? I'd really to move forward with this. Thanks. ---------------------------------------------------------------------- Comment By: Federico Schwindt (fgsch) Date: 2012-10-29 19:01 Message: That'd be ideal but since I'm not sure about the other changes (using config headers, etc.) I'm submitting what I know for certain that won't change depending on the approach. For example what should I do if alloca.h doesn't exist? In my git repo I have #ifdef HAVE_ALLOCA_H where the define is driven from autotools header check but I'm still unclear whether you want to use the headers or not (and the reason you might not want to do it since you're already using autotools). Happy to submit everything in one go if you can suggest what the best course of action is. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2012-10-29 18:57 Message: The best thing to do would be to make a single patch that includes everything needed for OpenBSD support. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3581737&group_…

1 0

[ pure-data-Patches-3598097 ] add setup() function to hexname objs to guarantee loading
by SourceForge.net 23 Dec '12

23 Dec '12

Patches item #3598097, was opened at 2012-12-21 14:24 Message generated for change (Settings changed) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3598097&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: externals Group: bugfix >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: IOhannes m zmölnig (zmoelnig) Summary: add setup() function to hexname objs to guarantee loading Initial Comment: When objects like ||~, &&~, etc are installed with a symlink to the 0x file name, they don't load because they can't find the setup function. They are looking for setup_0x7c0x7c_tilde(). Now that loading from setup() is included in Pd-vanilla 0.44 and Pd-extended 0.43.4, this patch adds setup() aliases to ensure that these objects load no matter what the filename is. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2012-12-23 10:34 Message: well, it seems that sourceforge has a bug, it won't let me upload the new patch, so I'm emailing it to you. I keep getting "File upload: ArtifactFile: Could not open file for writing" ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2012-12-23 10:27 Message: I added #ifndef ZEXY_LIBRARY and it built and linked a zexy.pd_linux. Hope I did it right, the updated patch is attached. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2012-12-23 08:48 Message: this will never link when zexy is compiled as a a multi-object library. when providing patches, please check whether they work with the _recommended_ way of using zexy. (e.g. at least use #ifdef ZEXY_LIBRARY to protect multiple definitions of the same functions) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3598097&group_…

1 0

[ pure-data-Patches-3581737 ] OpenBSD support
by SourceForge.net 23 Dec '12

23 Dec '12

Patches item #3581737, was opened at 2012-10-29 16:36 Message generated for change (Comment added) made by fgsch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3581737&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: None >Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Federico Schwindt (fgsch) Assigned to: Nobody/Anonymous (nobody) Summary: OpenBSD support Initial Comment: FIrst round of patches to add support for OpenBSD. ---------------------------------------------------------------------- >Comment By: Federico Schwindt (fgsch) Date: 2012-12-23 10:47 Message: Apologies for the silence, I just returned from holidays. The changes have helped to some extent but more work is required at least for OpenBSD. I will add the patch here once I get everything sorted. btw, why you have used stddef.h for alloca? This is not correct but I'm curious where you get the idea from. ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2012-11-26 11:44 Message: OK, added the ifdefs, tested on linux (makefile.gnu) and MSVC (makefile.msvc) , and pushed to git - please report back if there are problems on other platforms. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2012-11-20 12:00 Message: that looks good to me, Miller, but I don't know the BSD stuff. ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2012-11-20 09:08 Message: I think HAVE_ALLOCA_H is traditionally used to indicate the existence of a file, "alloca.h" which apparently doesn't exist in MSVC. I'm no longer worried about how we can get teh makefiles set up but rather what should go in the C code... at teh moment I believe it #ifdef HAVE_ALLOCA_H # include <alloca.h> /* linux, mac, mingw, cygwin */ #elif defined _MSC_VER # include <malloc.h> /* MSVC */ #else # include <stddef.h> /* BSDs for example */ #endif ... and that I can put that in, clean out the "old" autoconf stuff and voila. Do we all think that that work OK? ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2012-11-20 08:51 Message: or don't use config.h at all, add /D=HAVE_ALLOCA_H to makefile.nt (for those compiling on w32 using msvc) and use AC_CONFIG_HEADERS(alloca.h) for the systems that use autoconf. i doubt whether anybody involved in writing configure.ac has done the testing on all platforms known to compile Pd before submitting changes. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2012-11-19 19:46 Message: if you really think its worth your time, then go ahead and prepare a patch that you've tested on OpenBSD, GNU/Linux, Windows, Mac OS X, iOS, Android, Rockbox, and Microsoft Visual Studio. IMHO, things are working well as they are. ---------------------------------------------------------------------- Comment By: Federico Schwindt (fgsch) Date: 2012-11-19 15:01 Message: Not necessarily. You can supply pre-generated config.h for some platforms (that are obviously not going to change) and generate one for the rest. So basically if you're using autoconf you could use AC_CONFIG_HEADERS, if not just supply a config.h with all the defines for that platform. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2012-11-19 11:02 Message: AC_CONFIG_HEADERS works fine if your code is only built by the single autotools build system. In Pd's case, there are multiple build systems because of all of the platforms it runs on. There is configure.ac for UNIX and MinGW, src/makefile.nt for Microsoft Visual Studio, libpd for Android, iOS and more. Pd is also included in Rockbox. So using some auto-tools things makes it harder on the other platforms. ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2012-11-19 08:03 Message: I'm preparing to throw out the old "configure" stuff (which, by the way, I didn't originate and which I've tried and failed to understand; for some reason I never got AC_CONFIG_HEADERS() to work). But I'd still like to know what a good way to declare alloca(0 in a C file is. The autoconf web site suggests that I cut and past a 16-line #ifdef mess into every c file using alloca() .. perhaps under the "new" (autogen) system something shorter would work, but I'd want to have some confidence I'm doing something reasonable. ---------------------------------------------------------------------- Comment By: Federico Schwindt (fgsch) Date: 2012-11-17 19:37 Message: unfortunately you're wrong. alloca is not posix so i wouldn't expect any agreement here. as i said openbsd doesn't have alloca.h. i would not be surprised if other bsd are the same. malloc.h is also incorrect. here alloca's prototype is in stdlib.h. i will prepare a diff to add the maze of defines in all the configures and what not but I really fail to see why you can simply use AC_CONFIG_HEADERS() since you're already depending on configure. ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2012-11-17 15:03 Message: I went ahead and applied the patch by hand. I could be wrong, but isn't there now an alloca() function and an alloca.h on all unix-likes? and an alloca() defined in Windows? If so we can blow off all the configuration stuff and just conditionall include alloca or malloc.h depending on whether we're Windows. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2012-11-13 15:45 Message: no not really. afaiu the plan is to add a check for "alloca.h" to configure, which willl define HAVE_ALLOCA_H if the file is found. if HAVE_ALLOCA_H is defined alloca.h will get included. now the current behaviour is to include alloca.h in any case. but if the include is protected, then the build-system has to actively define HAVE_ALLOCA_H in order keep the old behaviour. simply ignoring the other build-systems might break them. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2012-11-13 11:45 Message: I think you'll be safe only touching the ./configure.ac and Makefile.ams. Miller seems to want to hold only to the old, crufty src/configure.in build, but he doesn't use OpenBSD. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2012-11-06 05:13 Message: #1 yes, the build-system is messed up (or rather, it is in a state of transition) #2 .../src/configure adds HAVE_foo to CPPFLAGS (and .../configure adds it to DEFS), which get expanded in the resp. makefiles (so technically you are right, they don't get added to CFLAGS) #3 i said "makefile.nt" and not "makefile.in", which is the 3rd(!) build-system that is there and which is used to build on w32 using MSVC. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2012-11-06 04:45 Message: I might be missing something but unless you add it manually I don't see where configures adds the HAVE_XXX to CFLAGS unless you do it manually. And src/makefile.in is processed by src/configure(.in) so only ../configure.ac and ../src/configure.in need to be modified. <rant> You have a pretty messed up build system. </rant> ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2012-11-06 03:57 Message: if the patch comes from git, then please create a branch, commit to that and then create a patch-set using "git format-patch master". as for the HAVE_ALLOCA_H: if you don't instruct configure to write defines into config.h, it will add them to the CFLAGS, so that the compilation will still work. thus, no need to change the build-system. bear in mind though, that currently Pd uses to separate build-systems: .../configure.ac and .../src/configure.in (and .../src/makefile.nt); you might need to modify all 3 in order to get accepted (yes, it's a PITA) ---------------------------------------------------------------------- Comment By: Federico Schwindt (fgsch) Date: 2012-11-06 02:48 Message: @zmoelnig: The patch comes from git. My main concern is how to proceed with the other changes that require more changes than just extending an existing ifdef. For example the exclusion of alloca.h, etc. In my git clone I've modified configure to use config headers and so I can do ifdef HAVE_ALLOCA_H, etc. but I'm not sure if such patches will be accepted. The reason I've break them down is so they can be committed while I understand what your preference is. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2012-11-06 02:39 Message: this patch is simple enough (almost trivial) as it only adds "#ifdef __OpenBSD__" to the clauses that are already handled by "__FreeBSD__". i don't see a reason to not include it (but of course this all depends on miller). small note on patches: - the patch doesn't apply here (`patch` thinks the diff is garbage) - Pd is developped in git; it would be great if you could generate your patches using git as well; see [1] - as for atomicity of patches: personally i think creating a (few) smaller patches is not a real problem; make sure that those patches are logical units rather than reflecting your iterative trial-and-error history to fix a problem. then attach all patch files to this ticket (rather than creating a new patchtracker-ticket for each file) [1] http://puredata.info/docs/developer/GitWorkflows/ ---------------------------------------------------------------------- Comment By: Federico Schwindt (fgsch) Date: 2012-11-06 02:03 Message: Comments please? I'd really to move forward with this. Thanks. ---------------------------------------------------------------------- Comment By: Federico Schwindt (fgsch) Date: 2012-10-29 19:01 Message: That'd be ideal but since I'm not sure about the other changes (using config headers, etc.) I'm submitting what I know for certain that won't change depending on the approach. For example what should I do if alloca.h doesn't exist? In my git repo I have #ifdef HAVE_ALLOCA_H where the define is driven from autotools header check but I'm still unclear whether you want to use the headers or not (and the reason you might not want to do it since you're already using autotools). Happy to submit everything in one go if you can suggest what the best course of action is. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2012-10-29 18:57 Message: The best thing to do would be to make a single patch that includes everything needed for OpenBSD support. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3581737&group_…

1 0

[ pure-data-Patches-3598097 ] add setup() function to hexname objs to guarantee loading
by SourceForge.net 23 Dec '12

23 Dec '12

Patches item #3598097, was opened at 2012-12-21 14:24 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3598097&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: externals Group: bugfix Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: IOhannes m zmölnig (zmoelnig) Summary: add setup() function to hexname objs to guarantee loading Initial Comment: When objects like ||~, &&~, etc are installed with a symlink to the 0x file name, they don't load because they can't find the setup function. They are looking for setup_0x7c0x7c_tilde(). Now that loading from setup() is included in Pd-vanilla 0.44 and Pd-extended 0.43.4, this patch adds setup() aliases to ensure that these objects load no matter what the filename is. ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2012-12-23 10:34 Message: well, it seems that sourceforge has a bug, it won't let me upload the new patch, so I'm emailing it to you. I keep getting "File upload: ArtifactFile: Could not open file for writing" ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2012-12-23 10:27 Message: I added #ifndef ZEXY_LIBRARY and it built and linked a zexy.pd_linux. Hope I did it right, the updated patch is attached. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2012-12-23 08:48 Message: this will never link when zexy is compiled as a a multi-object library. when providing patches, please check whether they work with the _recommended_ way of using zexy. (e.g. at least use #ifdef ZEXY_LIBRARY to protect multiple definitions of the same functions) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3598097&group_…

1 0

Jump to page:

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 December 2012