On 05/19/2014 05:01 PM, Hans-Christoph Steiner wrote:
It would be nice if you would forward bug fixes upstream to the patch tracker.
http://sourceforge.net/p/pure-data/patches/522/
That's generally considered the right thing to do when building upon a project. Don't take my word for it, there are many sources that go in depth on the topic all over the internet.
It's also considered good practice to look at the patches on the tracker and make a decision after 3 years whether or not to accept a patch:
http://sourceforge.net/p/pure-data/patches/369/
If you don't get a response from the developer of the project that's upstream from you, there's a multi-line text box on that page where you can write a response to _your_ users about why the patch was or wasn't accepted. You can click the "Preview" button to make sure your response looks the way you want. Then click the "Post" button to make your response viewable by the public.
-Jonathan
.hc
On 05/19/2014 02:57 PM, Ivica Bukvic wrote:
Forgot to include pd-list... ---------- Forwarded message ---------- From: "Ivica Bukvic" ico@vt.edu Date: May 19, 2014 2:57 PM Subject: Re: [PD] [expr] external crashing pd To: "IOhannes m zmoelnig" zmoelnig@iem.at Cc:
This had been fixed in pd-l2ork a while ago, it is alloc/dealloc error where math is off by one and hence the crash. On top of that pd-l2ork version warns user they have exceeded the number of allowable arguments and fails to create the object this preventing potential problems that may come as a result of improperly instantiated object receiving data. Please dig through recent pd-l2ork commits to find the fix.
HTH On May 19, 2014 1:11 PM, "IOhannes m zmoelnig" zmoelnig@iem.at wrote:
On 2014-05-16 21:12, Kim Cascone wrote:
two situations are crashing pd:
- when I try to change an expression in the object, like multiply
a ratio by 2 or something it crashes pd
unable to reproduce.
- when I attempt to create 10 ratio divisions with outlets (try
adding one to the patch I've attached below) it crashes the app as well
is this a known bug?
kind of. looking at the sources of expr i see (extra/expr~/vexp.h):
<snip> /* * Currently the maximum number of variables (inlets) that are supported * is 10. */ #define MAX_VARS 9 </snip>
and later (showing that not only the "inlets" are limited, but also the number of outlets is hardcoded to MAX_VARS):
<snap> t_outlet *exp_outlet[MAX_VARS]; </snap>
so you cannot have more than 9 inlets. expr should not crash though, and instead print something to the pd-console, that tells you about that problem.
so for now, my hint would be to not use [expr] and instead do explicit patching. in your case this is pretty straightforward (see attached patch...)
fgamsdr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list