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_…
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_…
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_…
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_…
Patches item #3585469, was opened at 2012-11-08 13:59
Message generated for change (Comment added) made by jancsika1
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3585469&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: Jonathan Wilkes (jancsika1)
Assigned to: Nobody/Anonymous (nobody)
Summary: Drop-in replacement for helpbrowser.tcl
Initial Comment:
Improved document browser and search engine for Pure Data internal/external documentation.
This is a refactored version of this GUI plugin:
http://puredata.info/Members/jancsika/searchplugindesc/
with the following mods:
* same key bindings as other dialogs
* withdrawing the window with <ctrl-w> or ESC will stop the current search in case it isn't finished
* clearer home page
----------------------------------------------------------------------
>Comment By: Jonathan Wilkes (jancsika1)
Date: 2012-11-11 12:22
Message:
Made the navigation bar in a separate text widget that stays at the top
when scrolling
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3585469&group_…
Patches item #3585461, was opened at 2012-11-08 13:09
Message generated for change (Settings changed) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3585461&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: IOhannes m zmölnig (zmoelnig)
Assigned to: Miller Puckette (millerpuckette)
Summary: [readsf~] loops some files
Initial Comment:
some wav-files get looped when played back via [readsf~].
it seems that the problem is dues to the soundfile fitting exactly into the fifobuffer, thus the EOF (signalled by the read-thread) drain never really starts in the perform routine.
(fifohead==fifosize, so the test for (!x_eof && x_fifohead >= x_fifotail && x_fifohead < x_fifotail + wantbytes-1) never triggers, resulting in a continuous drain of the entire buffer.
the attached soundfile triggers this behaviour.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2012-11-08 13:11
Message:
attached is a simplistic attempt to fix the problem: if the
fifohead==fifosize, we wrap it to 0 even if we just read the last byte.
(originally this was only done if !EOF)
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3585461&group_…
Patches item #3585469, was opened at 2012-11-08 13:59
Message generated for change (Tracker Item Submitted) made by jancsika1
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3585469&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: Jonathan Wilkes (jancsika1)
Assigned to: Nobody/Anonymous (nobody)
Summary: Drop-in replacement for helpbrowser.tcl
Initial Comment:
Improved document browser and search engine for Pure Data internal/external documentation.
This is a refactored version of this GUI plugin:
http://puredata.info/Members/jancsika/searchplugindesc/
with the following mods:
* same key bindings as other dialogs
* withdrawing the window with <ctrl-w> or ESC will stop the current search in case it isn't finished
* clearer home page
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3585469&group_…
Bugs item #3585461, was opened at 2012-11-08 13:09
Message generated for change (Tracker Item Submitted) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3585461&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: IOhannes m zmölnig (zmoelnig)
Assigned to: Miller Puckette (millerpuckette)
Summary: [readsf~] loops some files
Initial Comment:
some wav-files get looped when played back via [readsf~].
it seems that the problem is dues to the soundfile fitting exactly into the fifobuffer, thus the EOF (signalled by the read-thread) drain never really starts in the perform routine.
(fifohead==fifosize, so the test for (!x_eof && x_fifohead >= x_fifotail && x_fifohead < x_fifotail + wantbytes-1) never triggers, resulting in a continuous drain of the entire buffer.
the attached soundfile triggers this behaviour.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3585461&group_…
Patches item #3585457, was opened at 2012-11-08 12:17
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3585457&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: bugfix
Status: Open
Resolution: None
>Priority: 7
Private: No
Submitted By: IOhannes m zmölnig (zmoelnig)
Assigned to: Miller Puckette (millerpuckette)
Summary: support for OSSv4
Initial Comment:
one of Pd's older audio-backends is OSS.
while OSS is rather old and not a fast-moving target, some development does happen...
e.g. a while ago (probably years) all SOUND_PCM_-defines have been renamed to SNDCTL_DSP_.
luckily, the linux headers provided fallback defines, so old code (like Pd) would still compile.
now OSS is not dead and is currently developed as OSSv4.
unfortunately, the new OSSv4 headers have dropped the old fallback defines, and instead pro-actively create errors when the old defines are still used.
the attached patch changes these defines (and provides fallbacks in case the *new* defines are not defined), in order to be able to still use the OSS backend.
----------------------------------------------------------------------
>Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2012-11-08 12:19
Message:
raising priority since the old s_audio_oss.c breaks compilation.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3585457&group_…
Patches item #3585457, was opened at 2012-11-08 12:17
Message generated for change (Tracker Item Submitted) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3585457&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: bugfix
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: IOhannes m zmölnig (zmoelnig)
Assigned to: Miller Puckette (millerpuckette)
Summary: support for OSSv4
Initial Comment:
one of Pd's older audio-backends is OSS.
while OSS is rather old and not a fast-moving target, some development does happen...
e.g. a while ago (probably years) all SOUND_PCM_-defines have been renamed to SNDCTL_DSP_.
luckily, the linux headers provided fallback defines, so old code (like Pd) would still compile.
now OSS is not dead and is currently developed as OSSv4.
unfortunately, the new OSSv4 headers have dropped the old fallback defines, and instead pro-actively create errors when the old defines are still used.
the attached patch changes these defines (and provides fallbacks in case the *new* defines are not defined), in order to be able to still use the OSS backend.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3585457&group_…