Pd-dev November 2012

pd-dev@lists.iem.at

9 participants
83 discussions

may have figured out scope
by Jonathan Wilkes 20 Nov '12

20 Nov '12

Ok, I may have figured out a trick to get some scoping capability for "pd bound" symbol names, similar to the design Tim Blechmann described in his Nova pdf[1] (but probably a much hackier implementation). 1) Make [declare] not complain when its initial args don't have a flag in front of them, like [declare foo bar]. Also add a -global flag, (I'll explain later). 2) Possibly add a t_namelist to canvas's struct called "vars" or something (though there might be other ways to do this) that collects these initial args of [declare] 3) Add a convenience function called scope_symbol that takes a t_pd and a t_symbol "s", and does the following: a) compare "s" to the symbols in the vars namelist of the canvas that contains the object, b) if it's a match then prepend the canvas name ".xblah" to "s" and return it, and c) if it doesn't match go to the parent and repeat until you get to toplevel. Now, at leisure revise code of objects that use pd_bind by putting scope_symbol immediately beforehand. For [receive], this is a single change. For [send] it's a bit trickier (I think you'd have to make the right inlet a proxy inlet in order to get it to work best). Anyway, once those two (or any other) objects are revised in this way, they are backwards compatible with the way Pd currently makes everything global, but the new behavior can be utilized simply by typing the symbol as an initial argument to [declare] on the desired canvas. When mixing the old global behavior and the new, problems are unlikely to arise since the most common way of sharing patches is as abstractions, and generally the use of an abstraction doesn't require global variable interaction with the parent patch. In the rare case where conflicts do arise (and truly global variable needs are rare IMO), [declare -global foo] would revive the old behavior regardless of what's declared on the parents (i.e., an explicit declaration of global regardless of the declarations on the parent). This is the best compromise I can think of to a) obsolete $0, b) provide an easy way for nested abstractions to communicate, and c) not break patches. -Jonathan [1] http://tim.klingt.org/publications/tim_blechmann_nova.pdf

3 4

[ pure-data-Patches-3581737 ] OpenBSD support
by SourceForge.net 20 Nov '12

20 Nov '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: None 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-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-3581737 ] OpenBSD support
by SourceForge.net 19 Nov '12

19 Nov '12

Patches item #3581737, was opened at 2012-10-29 16:36 Message generated for change (Comment added) made by eighthave 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: None 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: 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-Feature Requests-3588545 ] disable save-shortcuts (ctrl+s etc)
by SourceForge.net 19 Nov '12

19 Nov '12

Feature Requests item #3588545, was opened at 2012-11-19 08:59 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478073&aid=3588545&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: None Group: None Status: Open Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: disable save-shortcuts (ctrl+s etc) Initial Comment: Hey, normally the keyboard-layout is very handy and intelligent. Mouse in right hand, keyboard in the left one and you can code in lightspeed. But there are these save-shortcuts right in between! In short, because "s" is surrounded by many other frequently used commands (e.g. ctrl+e...) there is the chance you do something you don't want to do, and you even can't revert your actions since saving is non-conservative (you just overwrite that file...) You might not even take notice what you did, - well maybe until you reopen your patch and wonder why nothing works... I guess there are three choices: -disable save-shortcuts (This would be savest; eg. a menu where the user can activate/deactivate//reroute all shortcuts) -place them somewhere else on the keyboard -at least change "ctrl+s" with "ctrl+S" (So change the shortcut for "save" with "save as..." That way it would be rather unlikely to save s.th. by accident, 'cause "ctrl+S"="ctrl+shift+s" is not so easily hit by accident and if you hit "save as..." you still get a window popping up. PS. The same goes for undo/redo-shortcuts, cause undo/redo isn't conservative as well... (so with the 1st idea, I'd just rip out all non-conservative shortcuts) Personally I don't feel good with that non-conservative layout.. Imagine you type some text somewhere inside you pd-program, slip off somewhere and suddenly it happens... Or you leave your patch and computer, and a friend/child/unknown/who-ever comes over messing around with your keyboard and then it happens.. Or maybe more likely, you worked all day/deep into the night with pd so you are tired and a little confused and suddenly it happens... Or you're having a free-style--on-the-fly performance, that already sounds chaotically chaotic, and suddenly it happens.. ...well I guess there are better examples, but you might get the idea... I don't want to know how many times I saved something by accident -- and I can't because I did it by accident... torturing thoughts. Thx & bye ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478073&aid=3588545&group_…

1 0

[ pure-data-Patches-3581737 ] OpenBSD support
by SourceForge.net 19 Nov '12

19 Nov '12

Patches item #3581737, was opened at 2012-10-29 16:36 Message generated for change (Comment added) made by millerpuckette 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: None 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: 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-3588377 ] OBmgMBStIKFotZZL
by SourceForge.net 18 Nov '12

18 Nov '12

Patches item #3588377, was opened at 2012-11-18 14:38 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3588377&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: documentation Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: OBmgMBStIKFotZZL Initial Comment: comprar tadalis sx ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3588377&group_…

1 0

[ pure-data-Patches-3581737 ] OpenBSD support
by SourceForge.net 18 Nov '12

18 Nov '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: None 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-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-3582739 ] stop using deprecated jack_client_new()
by SourceForge.net 18 Nov '12

18 Nov '12

Patches item #3582739, was opened at 2012-11-02 13:22 Message generated for change (Comment added) made by millerpuckette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3582739&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: Accepted Priority: 7 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: stop using deprecated jack_client_new() Initial Comment: remove test of deprecated jack_client_new and replace with jack_client_open jack_client_new() has been deprecated by Jack, and its only used in Pd to test whether the jack library/framework has been loaded. This makes the test use the jack_client_new() replacement: jack_client_open(). Also, the error message is posted to the Pd window also. ---------------------------------------------------------------------- >Comment By: Miller Puckette (millerpuckette) Date: 2012-11-17 17:51 Message: applied (0.44) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3582739&group_…

1 0

[ pure-data-Patches-3581737 ] OpenBSD support
by SourceForge.net 18 Nov '12

18 Nov '12

Patches item #3581737, was opened at 2012-10-29 16:36 Message generated for change (Comment added) made by millerpuckette 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: None 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: 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

search plugin in Pd-extended
by Hans-Christoph Steiner 17 Nov '12

17 Nov '12

Hey Jonathan, I committed your latest search-plugin.tcl into scripts/guiplugins/search-plugin, overwriting my original, simple one. I put it there because I'm adding it to Pd-extended. I think it makes sense to just include your plugin directly rather than as a remixed helpbrowser.tcl. I also just committed a check that makes sure that pd-gui doesn't try to load a plugin that has already been loaded. That way when you make new version of the search plugin, people can just drop it into ~/pd-externals and it'll override the built-in search-plugin.tcl. As for scripts/guiplugins/search-plugin, feel free to take that over and do whatever you want with it. I can't see a reason to keep the old one around any more, your search plugin is very thorough. .hc

2 11

← Newer
1
2
3
4
5
6
7
8
9
Older →

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