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" <[email protected]>
Date: May 19, 2014 2:57 PM
Subject: Re: [PD] [expr] external crashing pd
To: "IOhannes m zmoelnig" <[email protected]>
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" <[email protected]> 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
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list