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-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_…
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-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_…
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-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_…
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-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 #3584286, was opened at 2012-11-05 10:14
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3584286&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: v0.43
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Scrolling much too fast (mousewheel)
Initial Comment:
Instead of scrolling step by step it goes directly to the end of the canvas (using the mousewheel).
That is true for vanilla and ext releases of pd0.43 (windows). Worked in pd0.42.5
Bye
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3584286&group_…
Bugs item #3583473, was opened at 2012-11-04 10:36
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3583473&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
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: [namecanvas] is not obsolete!
Initial Comment:
I always read that the [namecanvas] is obsolete. That's not true.
One can address a subpatch via "pd-SUBPATCHNAME", but that does not work with the toplevel-patch.
Actually it does with "pd-FILENAME.pd". But it's not a good idea (nor intended I guess) to make the patches internals depend on the filename. - Filenames may change and thus break the patch. Eg. if you improve a patch and save it to a new file, you would always have to rearrange that name as well...
And, more important, if you open several patches with the same name, you will get nameconflicts! (One cannot use "$0" in the filename, ofcourse...)
So in short: [namecanvas] is needed. Eg. for GOP-abstractions!
Bye
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3583473&group_…
Bugs item #3582935, was opened at 2012-11-03 19:22
Message generated for change (Tracker Item Submitted) made by jancsika1
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3582935&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
Resolution: None
Priority: 5
Private: No
Submitted By: Jonathan Wilkes (jancsika1)
Assigned to: Nobody/Anonymous (nobody)
Summary: iemgu infinite loop crasher
Initial Comment:
[vsl] <- send-symbol = "foo" receive-symbol = "bar"
[vsl] <- send-symbol = "bar" receive-symbol = "foo"
BOOM!
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3582935&group_…
Bugs item #3582902, was opened at 2012-11-03 18:22
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3582902&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
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: ds-plot inconsistency
Initial Comment:
hey,
I just noticed a small inconsistency with [plot].
There is a flag for making the scalars along the path invisible. That is already simply possible by not using a drawinginstruction inside the array-scalar-structure.
But there is no flag for making the connection-line (= the actual plot-structure) invisible and leave the scalars.
Why not rearrange that flag for the visibility of the line?!
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3582902&group_…
Patches item #3582746, was opened at 2012-11-02 14:39
Message generated for change (Tracker Item Submitted) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3582746&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: Hans-Christoph Steiner (eighthave)
Assigned to: Miller Puckette (millerpuckette)
Summary: fix setting of [bng]'s hold time in properties panel
Initial Comment:
one of the variables didn't get renamed in the GUI rewrite:
--- a/tcl/dialog_iemgui.tcl
+++ b/tcl/dialog_iemgui.tcl
@@ -73,7 +73,7 @@ proc ::dialog_iemgui::sched_rng {mytoplevel} {
$mytoplevel.rng.max_ent configure -textvariable $var_iemgui_max_rng
$mytoplevel.rng.min_ent configure -textvariable $var_iemgui_min_rng }
if {[eval concat $$var_iemgui_max_rng] < $define_min_flashhold} {
- set $var_iemgui_max_rng $iemgui_define_min_flashhold
+ set $var_iemgui_max_rng $define_min_flashhold
$mytoplevel.rng.max_ent configure -textvariable $var_iemgui_max_rng
}
if {[eval concat $$var_iemgui_min_rng] < $define_min_flashbreak} {
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3582746&group_…
Patches item #3582739, was opened at 2012-11-02 13:22
Message generated for change (Settings changed) made by eighthave
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: Open
Resolution: None
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.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3582739&group_…