Pd-dev November 2012

pd-dev@lists.iem.at

9 participants
83 discussions

[ pure-data-Patches-3587346 ] VgIdZIVMmnhPS
by SourceForge.net 15 Nov '12

15 Nov '12

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

1 0

shared class data and functions
by Jonathan Wilkes 15 Nov '12

15 Nov '12

I have three classes: foo, bar, bow Foo has a function: void foo_blah(t_foo *x, t_symbol *s, t_int argc, t_atom *argv) { if(x->x_member == 1) do_something... } Bar and bow both have x->x_member, too, and I want all three to use the same function so I don't have to copy it two more times. Is there a way to do this: void foo_blah(t_pd *x, t_symbol *s, t_int argc, t_atom *argv) { if we can cast x to t_foo, t_bar or t_bow then check if x has x->member equal to 1, and if so then do_something... } which I can call by sending t_foo, t_bar or t_bow as the first arg to that function? It seems like I should be able to do this but I can't figure out all the pointer bs. -Jonathan

4 5

[ pure-data-Patches-3587145 ] cUaIxbRXQhKMBgM
by SourceForge.net 14 Nov '12

14 Nov '12

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

1 0

[ pure-data-Patches-2947822 ] space character in gui labels causes disaster
by SourceForge.net 14 Nov '12

14 Nov '12

Patches item #2947822, was opened at 2010-02-08 05:12 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=2947822&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: Matteo Sisti Sette (sistisette) Assigned to: Miller Puckette (millerpuckette) Summary: space character in gui labels causes disaster Initial Comment: Steps to reproduce: 1 - Open the attached patch Note the size of the radio and toggle. Note also they have "send" symbols set to "xxx" and "yyy" respectively 2 - Click on the big bang at the top This composes a symbol containing space characters and sends it as a label to both the radio and the toggle. This seems to work: the label is actually set with spaces, and the radio and toggle still work. However, if you right-click on any of them and try to select "properties", the properties dialog won't open 3 - Now save the patch and close it 4 - Open the patch again. The radio and toggle properties have been completely "reset": their size have been reset to default, and also the "number" property of the radio. They have lost their "send" symbol too: you can see the outlet and if you use them, the "r" objects won't receive anything. However, if you open the properties dialog of the radio or toggle, you'll see that the "send" property is still there (not the same can be said for the size and number); if you now do Apply or Ok, the send symbol will be restored. So, spaces in the label of a gui object cause weirdnesses and potential disaster. Note that data is lost (the properties of the gui objects) if the patch is saved after assigning such a label, and i is lost silently with no error message at any moment. There are ather "forbidden" characters ithat don't behave properly n labels, such as the open square bracket "[" (as reported in another bug report). However the space character is more disatrous as it causes data loss. Object should either accept ALL characters for a label, or properly detect and refuse forbidden characters, which should be documented, avoiding unexpected consequences. ---------------------------------------------------------------------- >Comment By: IOhannes m zmölnig (zmoelnig) Date: 2012-11-13 16:45 Message: added another patch (0002_*) that implements escaping spaces and tabs when saving the files to disk. i guess both patches should be applied for full fun. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2012-11-13 15:36 Message: the bug.pd file does not correctly show the labels with blanks after reloading but it doesn't throw any warnings) however, the bugfix-patch doesn't work for me. nevertheless the problem is known and is not in the pd->gui communication, but rather in the way the label is stored on disk (and then interpreted on reload): afaict, blanks (and other special chars) really must be escaped with backslash (e.g. "A\ A\ A") when saved to disk ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2012-11-13 12:52 Message: the values were not quoted, so just quoting them with {} fixes it. The patch is attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=2947822&group_…

1 0

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

14 Nov '12

Patches item #3581737, was opened at 2012-10-29 16:36 Message generated for change (Comment added) made by zmoelnig 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: 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-2947822 ] space character in gui labels causes disaster
by SourceForge.net 14 Nov '12

14 Nov '12

Patches item #2947822, was opened at 2010-02-08 05:12 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=2947822&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: Matteo Sisti Sette (sistisette) Assigned to: Miller Puckette (millerpuckette) Summary: space character in gui labels causes disaster Initial Comment: Steps to reproduce: 1 - Open the attached patch Note the size of the radio and toggle. Note also they have "send" symbols set to "xxx" and "yyy" respectively 2 - Click on the big bang at the top This composes a symbol containing space characters and sends it as a label to both the radio and the toggle. This seems to work: the label is actually set with spaces, and the radio and toggle still work. However, if you right-click on any of them and try to select "properties", the properties dialog won't open 3 - Now save the patch and close it 4 - Open the patch again. The radio and toggle properties have been completely "reset": their size have been reset to default, and also the "number" property of the radio. They have lost their "send" symbol too: you can see the outlet and if you use them, the "r" objects won't receive anything. However, if you open the properties dialog of the radio or toggle, you'll see that the "send" property is still there (not the same can be said for the size and number); if you now do Apply or Ok, the send symbol will be restored. So, spaces in the label of a gui object cause weirdnesses and potential disaster. Note that data is lost (the properties of the gui objects) if the patch is saved after assigning such a label, and i is lost silently with no error message at any moment. There are ather "forbidden" characters ithat don't behave properly n labels, such as the open square bracket "[" (as reported in another bug report). However the space character is more disatrous as it causes data loss. Object should either accept ALL characters for a label, or properly detect and refuse forbidden characters, which should be documented, avoiding unexpected consequences. ---------------------------------------------------------------------- >Comment By: IOhannes m zmölnig (zmoelnig) Date: 2012-11-13 15:36 Message: the bug.pd file does not correctly show the labels with blanks after reloading but it doesn't throw any warnings) however, the bugfix-patch doesn't work for me. nevertheless the problem is known and is not in the pd->gui communication, but rather in the way the label is stored on disk (and then interpreted on reload): afaict, blanks (and other special chars) really must be escaped with backslash (e.g. "A\ A\ A") when saved to disk ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2012-11-13 12:52 Message: the values were not quoted, so just quoting them with {} fixes it. The patch is attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=2947822&group_…

1 0

[ pure-data-Patches-2947822 ] space character in gui labels causes disaster
by SourceForge.net 13 Nov '12

13 Nov '12

Patches item #2947822, was opened at 2010-02-08 05:12 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=2947822&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: Matteo Sisti Sette (sistisette) Assigned to: Miller Puckette (millerpuckette) Summary: space character in gui labels causes disaster Initial Comment: Steps to reproduce: 1 - Open the attached patch Note the size of the radio and toggle. Note also they have "send" symbols set to "xxx" and "yyy" respectively 2 - Click on the big bang at the top This composes a symbol containing space characters and sends it as a label to both the radio and the toggle. This seems to work: the label is actually set with spaces, and the radio and toggle still work. However, if you right-click on any of them and try to select "properties", the properties dialog won't open 3 - Now save the patch and close it 4 - Open the patch again. The radio and toggle properties have been completely "reset": their size have been reset to default, and also the "number" property of the radio. They have lost their "send" symbol too: you can see the outlet and if you use them, the "r" objects won't receive anything. However, if you open the properties dialog of the radio or toggle, you'll see that the "send" property is still there (not the same can be said for the size and number); if you now do Apply or Ok, the send symbol will be restored. So, spaces in the label of a gui object cause weirdnesses and potential disaster. Note that data is lost (the properties of the gui objects) if the patch is saved after assigning such a label, and i is lost silently with no error message at any moment. There are ather "forbidden" characters ithat don't behave properly n labels, such as the open square bracket "[" (as reported in another bug report). However the space character is more disatrous as it causes data loss. Object should either accept ALL characters for a label, or properly detect and refuse forbidden characters, which should be documented, avoiding unexpected consequences. ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2012-11-13 12:52 Message: the values were not quoted, so just quoting them with {} fixes it. The patch is attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=2947822&group_…

1 0

[ pure-data-Patches-2947822 ] space character in gui labels causes disaster
by SourceForge.net 13 Nov '12

13 Nov '12

Patches item #2947822, was opened at 2010-02-08 05:12 Message generated for change (Settings changed) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=2947822&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: Matteo Sisti Sette (sistisette) >Assigned to: Miller Puckette (millerpuckette) Summary: space character in gui labels causes disaster Initial Comment: Steps to reproduce: 1 - Open the attached patch Note the size of the radio and toggle. Note also they have "send" symbols set to "xxx" and "yyy" respectively 2 - Click on the big bang at the top This composes a symbol containing space characters and sends it as a label to both the radio and the toggle. This seems to work: the label is actually set with spaces, and the radio and toggle still work. However, if you right-click on any of them and try to select "properties", the properties dialog won't open 3 - Now save the patch and close it 4 - Open the patch again. The radio and toggle properties have been completely "reset": their size have been reset to default, and also the "number" property of the radio. They have lost their "send" symbol too: you can see the outlet and if you use them, the "r" objects won't receive anything. However, if you open the properties dialog of the radio or toggle, you'll see that the "send" property is still there (not the same can be said for the size and number); if you now do Apply or Ok, the send symbol will be restored. So, spaces in the label of a gui object cause weirdnesses and potential disaster. Note that data is lost (the properties of the gui objects) if the patch is saved after assigning such a label, and i is lost silently with no error message at any moment. There are ather "forbidden" characters ithat don't behave properly n labels, such as the open square bracket "[" (as reported in another bug report). However the space character is more disatrous as it causes data loss. Object should either accept ALL characters for a label, or properly detect and refuse forbidden characters, which should be documented, avoiding unexpected consequences. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=2947822&group_…

1 0

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

13 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-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-Bugs-3586686 ] msgfile and textfile omits period/full stop after a number
by SourceForge.net 13 Nov '12

13 Nov '12

Bugs item #3586686, was opened at 2012-11-13 03:16 Message generated for change (Tracker Item Submitted) made by hellocatfood You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3586686&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: hellocatfood (hellocatfood) Assigned to: Hans-Christoph Steiner (eighthave) Summary: msgfile and textfile omits period/full stop after a number Initial Comment: If a single period/full stop appears after a number in a text file, when it is read by msgfile or textfile that period disappears. This does not happen if a period appears after text or if there are two or more periods. Attached is a patch that demonstrates this. I'm using pd-extended 0.43.4-extended-20121111 on Ubuntu 12.04 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3586686&group_…

1 0

← 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