[PD] Very large patches unstable?

[IOhannes m zmoelnig]

Matteo Sisti Sette wrote:
> 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.

i was not talking about C/C++ suggestions.
i fully understand that not everybody is able or willing (e.g. because
of time constraints) to learn a programming language for the
implementation of things like Pd.

> The only suggestions I can give are the obvious ones:
> - fix the bugs
> - design things with an eye on optimization and scalability.

these are not the kind of suggestions i was trying to get.
imo, they do not solve any problem, just put the load on those that were
able or willing to do learn how to fix things on the code level.

these are demands.

> 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.

hmm. it's entirely "possible" that you do learn to code C and implement
something in O(nlogn) or O(1).
i guess it is just easier to not.


> 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. 

i haven't claimed anything else.
a bug is there to be fixed.
it's not about philosophical reasoning, it's about practical doing.

> 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.

no it's way simpler: Pd could just allow you to have a a single [osc~]
object and a single [dac~] object.
no need to write buggy code to dynamically create objects.
simple to maintain.
harder to create bugs.
boring to use.

allowing the user to go "beyond limits" usually involves more
sophisticated code: easier to make errors, easier to create bugs.

> And wherever a physical, numerical, well-defined limit still exists,
> which is unavoidable, it MUST be documented.

indeed. the Pdolice will get 'em sooner or later.


>> 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.

true.
but what can you do about it?
basically i see two ways: do it better, or tell people that they MUST do
it better.

>> 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.

but you feel that it is not too difficult for other people to isolate
the bug and fix it, with nothing more than "if i create 12000 instances
of a patch (which i cannot send you because it's proprietary and i can't
trust you) it crashes, but it doesn't crash with 20500 instances of
another patch".


> However in some cases I did manage to isolate the bug, report it, and
> even get it fixed.

which i appreciate (though right now i wonder why: it's not that anybody
 get's much for fixing the bug, apart from gory glory)

> 
>> "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".

i don't have much problems with that. mostly i'm a very happy person
(despite of how i write my emails)

but if somebody is ready to shout "your work frustrates me", than they
should be prepared to get an answer "your statement frustrates me".
i think there's equal rights about frustrations and expressing them.


lot's of the above i've written is a bit polemic.
whenever i say "you" i don't necessarily mean "matteo", but the unknown
poster.

fgmasdr
IOhannes


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20091202/fd8a574f/attachment.bin>