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
matteosistise...@gmail.com
http://www.matteosistisette.com
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
