[PD] Very large patches unstable?

[Matteo Sisti Sette]

IOhannes m zmoelnig escribió:
> 
> hmm, so what is your suggestion to solve the problem?

Unfortunately I am not a C++ developer so I cannot study the source code 
and give practical, specific, useful suggestions.
The only suggestions I can give are the obvious ones:
- fix the bugs
- design things with an eye on optimization and scalability.

Regarding the second point, just from what I have "heard" (i.e. I can't 
speak with full knowledge of the facts), I think a lot of things in PD 
are not implemented in the most optimized way, that is for example, 
double linked lists are used where more efficient data structures could 
be used. I guess efficiency is considered often "not to be an issue" 
just because it is (implicitely) considered unlikely that a user will 
put a few thousands objects with a dozen of levels of nesting 
(abstractions inside abstractions).
I simply guess that in some cases, an implementation that is O(n^2) is 
chosen just because it is the easiest one, where a O(nlogn) is possible. 
The implicit assumption is that n won't ever be big enough to make a 
difference. Sometimes that assumption is reasonable, sometimes it is 
not. I can't suggest anything more specific than just ask yourself, when 
you (I'm saying 'you' meaning PD developers) take such decisions: "Is it 
really safe to assume 'n' won't ever be big enough? Isn't it worth using 
a more efficient data structure? Can I really assume that it would be 
'foolish' to have n>[some value here]? Or maybe not?"

That is about "pushing the limits". That accounts for cases where big 
numbers get unmanageable for efficiency reasons (either of time or of 
memory, but usually time), that is things get slow when they COULD be 
fast enough.

BUT, that does not account for crashes. When PD (or any program) 
crashes, there's no philosophical reasoning about pushing/hitting/going 
beyound the limits that can justify that. When there's a crash, there's 
simply a bug. Some pointer goes out of the bounds of allocated memory, 
or maybe an integer wraps to negative values and is used as an array 
index, or whatever. That is, someone forgot to write a line of code that 
does a check; or, there is some kind of leak (memory leak, for example), 
which is simply due to an oversight in writing code, and probably that 
only becomes evident when numbers (of things doing things) get large.
Etcetera. Those are bugs, oversights, it is not a matter of allowing to 
go beyound limits.
Allowing the user to go beyound limits doesn't mean allocating N bytes 
and then allowing the user to address locations that don't exist. It 
doesn't mean using N bits for a number and allowing the user to 
introduce a number that exceeds 2^N.
Allowing to go beyound the limits means designing things in such a way 
that they can be used in ways that the developer haven't thought about. 
And wherever a physical, numerical, well-defined limit still exists, 
which is unavoidable, it MUST be documented.


 > in many it does the latter (which
> is the strength of Pd, i believe).

Of course it does. That's why I love it. But sometimes I have the 
impression that though that is the philosophy, it is not fully expressed 
in the implementation.


> rather i would have people who reach them, report here and provide
> examples how to reach these limits, so they can be fixed.

That's what I always do whenever I can. If I had the skills, I would 
even try to locate the problem in the source code, but I don't have 
them. So I just report the bugs and, if I can, provide some example patch.

Sometimes however the bugs are too difficult to isolate, so the only 
patch I could send with the report, would be the "complete" patch, and 
usually I can't do that because I develop patches for artists (i.e. not 
for myself) so I can't "make them publish" even if I would like to. If 
they were mine, I would, but I can't "trust" people "on behalf of" other 
people.
However in some cases I did manage to isolate the bug, report it, and 
even get it fixed.

I know it feels bad to receive a bug report without an easy way to 
reproduce the bug. In those cases, I try to give as much information as 
I can in order to give some "clue" to the developers.


> "i find Pd frustrating because it is so unstable" is for me a highly
> frustrating statement.

Well, since the subject was touched, I just thought I would just share 
my opinion. I am happy, and sorry at the same time, that I have 
transmitted you my frustration.

Note that I keep using PD after all. Perhaps I should sometimes share 
also the great joys and satisfactions it gives me, and not only the 
frustrations which are a small percentage. I tend to be somewhat 
"practical" and write only when there's an issue to be solved; that 
implies being unintentionally "negative".


Cheers,
m.


-- 
Matteo Sisti Sette
matteosistisette at gmail.com
http://www.matteosistisette.com