I've certainly used patches with 500-1000 abstraction instances without problem, I guess I haven't tried 4600.
I wouldn't be surprised at all if the "limit" (i.e. the point where things begins not working) were somwhere between the two numbers.
I had a lot of problems with very big patches, and a lot of times things that worked perfectly fine with a "dimension" N stopped working with N+1, where by "dimension" I mean just the "quantity of things" (e.g. instances of a same abstraction), without the smallest change in "complexity". In some cases some developer (I won't tell the name, but it's someone very important here) was able to find specific bugs and fixed it and published a new release.
Unfortunately PD becomes somewhat unreliable if not unstable, when patches get really big. That's very frustrating, because the way it is 'defined' (i.e. the way it is supposed to work) really allows beautiful, complex, scalable design; but the implementation doesn't support it at the end. Also, these kind of bugs are very difficult to isolate.
The greatest frustration is when you carefully design something so that size (e.g. number of instances) shouldn't be a problem, you strongly test it within a certain 'size' and verify it is rock-solid, and then, when you have everything working and your project grows a little bit and you just add a couple more instances of something, it stasrts crashing....
Matteo Sisti Sette wrote:
I've certainly used patches with 500-1000 abstraction instances without problem, I guess I haven't tried 4600.
The greatest frustration is when you carefully design something so that size (e.g. number of instances) shouldn't be a problem, you strongly test it within a certain 'size' and verify it is rock-solid, and then, when you have everything working and your project grows a little bit and you just add a couple more instances of something, it stasrts crashing....
hmm, so what is your suggestion to solve the problem?
either you restrict people to what they can do on purpose, or you allow them to go beyond limits. in some aspects, Pd does the former, in many it does the latter (which is the strength of Pd, i believe). however, pushing the limits inevitably also means hitting the limits. since the limits are always expanding, it is a bad target for development. rather i would have people who reach them, report here and provide examples how to reach these limits, so they can be fixed.
"i find Pd frustrating because it is so unstable" is for me a highly frustrating statement.
<lines intentionally left blang to fill in the usualy rant on FLOSS software and the user>
mgfasdr IOhannes
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 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. The only suggestions I can give are the obvious ones:
- fix the bugs
- design things with an eye on optimization and scalability.
Before that I would try the very large patch on a faster computer with more RAM.
Martin
Martin Peach escribió:
Matteo Sisti Sette wrote:
The only suggestions I can give are the obvious ones:
- fix the bugs
- design things with an eye on optimization and scalability.
Before that I would try the very large patch on a faster computer with more RAM.
I strongly disagree with that. Maybe _after_, but certainly not _before_ that. That way of thinking (with all respect) is the reason why so much software is very badly done - and obviously I am _NOT_ talking about PD here.
On Wed, 2 Dec 2009, Martin Peach wrote:
Before that I would try the very large patch on a faster computer with more RAM.
Good idea. Now with four CPUs, you can now load Pd in the same amount of time as before, but as a bonus, your system is 75% CPU idle in the meanwhile.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
matju wrote:
On Wed, 2 Dec 2009, Martin Peach wrote:
Before that I would try the very large patch on a faster computer with more RAM.
Good idea. Now with four CPUs, you can now load Pd in the same amount of time as before, but as a bonus, your system is 75% CPU idle in the meanwhile.
Oh no of course not! You must then make your patch even bigger until it's again using 110% and crashes because of 'bugs'.
Martin
On Wed, 2 Dec 2009, martin.peach@sympatico.ca wrote:
On Wed, 2 Dec 2009, Martin Peach wrote:
Before that I would try the very large patch on a faster computer with more RAM.
Good idea. Now with four CPUs, you can now load Pd in the same amount of time as before, but as a bonus, your system is 75% CPU idle in the meanwhile.
Oh no of course not! You must then make your patch even bigger until it's again using 110% and crashes because of 'bugs'.
What I mean is that Pd has only two threads and so can't get any faster with 4 CPUs than with two. Furthermore, if the slowdown is concentrated in one thread, it doesn't get any faster with 4 CPUs than with _one_. This 1/4 ratio is where I took the 75% in my example.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
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
Let's suppose 'I' am the user and 'you' are the developer, which I guess is partially true sometimes.
Let's also say what should be implicit, that we are discussing for the sake of exchanging ideas, and that nobody is criticising the work of nobody, and also that the fact of replying in a somewhat 'polemic' tone doesn't mean one feels offended but only that the debate excites him/her (this is my case, hope it is yours as well).
You're right, mine are not suggestions, they are demands.
Wich leads me to what seems to be the (or one) underlying point throughout your email, that is: what right do I have to demand things from you? Why should you listen to my demands and work to fulfill [dunnow if it is the right verb here] them? What do you get from it?
Well, I admit I don't know the answers; in a commercial software scenario it is easier, because you are paid to develop the software, and I [am supposed to] pay to use it, so asking to fix things is a right for me, and fixing things is a due for you. This is not the case with FLOSS and I don't really know what is the motivation for the developer to, well, develop. But I assume there is one, because if there wasn't one then the software would'nt exist and we wouldn't be talking about it. I have to assume that for some reason you (the developer) are interested in developing the software and in making it the best it can be. Otherwise, we wouldn't be talking in the first place.
So, I don't have any right to demand anything, I am very grateful that PD exists the way it is, with its bugs and everything, and you don't have to fix anything; but assuming you are interested for some reason in developing the software and you are doing it, what kind of contribution can I give as a user? The answer is "feedback", and feedback consists, among other things, in DEMANDS. These demands can be reasonable or foolish, that is, the feedback from the user can be valuable or useless.
The latter also holds for bug reports (another kind of feedback), which can actually help to fix the bug or not.
[.......] allowing the user to go "beyond limits" usually involves more sophisticated code: easier to make errors, easier to create bugs.
Well yes, I agree with that, or I understand that. Does that mean that we should be happy with the presence of bugs? Seems like you're saying: "What do you prefer, a boring, simple, limited but rock-solid software, or a powerful, flexible [whatever positive adjective you may want to add here] but buggy one?" Well if I, as a user, had to choose I would probably agree with you in chosing the second one, but you, as a developer, are [should be/may be/whatever] committed to go towards the goal of the flexible, powerful [etc] AND rock-solid software...
Jesus, are we discussing whether bugs should be fixed or not?????????
Remember (I say this to myself too) that the whole "debate" arose because somebody mentioned a situation of instability and I pointed out that it seems to be particularly frequent with big patches in PD. So, let's try not to take this as a criticism (maybe the tone of my first mail didn't help in this sense). PD is constantly under development, isn't it? It is not a "finished" product (if such a thing even exists). So, it has its strengths and weaknesses, like every piece of software. It doesn't make sense to discuss whether the first compensate the latter or viceversa; it MAY make sense to analyze its strengths and merits; but I think it is more useful to point out weaknesses so that they can be worked on in the future.
What are the weak points of PD (don't be afraid, I won't try to list them)? Well, to make an example everybody knows the graphical interface is tremendously slow. That is well known; I don't know how much priority the developer community give to that problem (quite low I guess), but the problem is well known, so there is no need to discuss about it. One thing that I have experienced, and that a few users have experienced but, I suspect, not so many, is that with huge patches things start becoming unstable. Since it is not so frequent to "hit" this problem, when I did, I gave my feedback about them, including bug reports when I could isolate some reproducible crash, and test patches when I could. Now, since another user commented about instability with huge patches, I took the opportunity to stress again the importance that this kind of issue has (imo, obviously), and to express the feeling (possibly wrong) that they are not given the importance they deserve. That's all.
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.
Well, unfortunately I can't do it better, and about the second option, I guess you are sarchastic. I think there's a third thing I can do: give the developers information (i.e. reports, test patches, etc) that can help them doing it better, which implies the assumption that they are interested in doing it better. If every time I do that I should feel like I was telling them what they MUST do, thus offending them, well, then I probably had better unsubscribe this mailing list.
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".
(first, I didn't say I don't trust you; I just said I can't give you what is not mine, stop) No, I just think I have to report the bug with as much information as I can; if that is not enough to fix the bug, well, I tried. I think the developer usually has much more information than the user, and sometimes with some clues can find the problem even without a directly reproducible crash. Obviously your oversimplification or example is exagerated.
I am a developer also (or I consider myself such), though I don't develop in C++; obviously my work is way way simpler than something even comparable to a software like PD. But sometimes "my users" simply report that things "don't work" and they are not capable of giving me a directly reproducible error that I can investigate, nor anything better than a confused explanation. I don't consider their duty to do so, I rather consider my duty to find out what's wrong, which is my error in the first place. Anyway, the fact that there's no simple way to reproduce the problem has no relevance in evaluating the importance of fixing it. That can be very frustrating, I know. However, I recognize this is not the same thing because I do get paid for the work.
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.
Well I must recognize you are right here. But please be sure I didn't mean to "shout".
Here's a friendly suggestion, instead of spending time writing giant
emails, spend that time trying to isolate the bugs that you are
complaining about. If you can make a pd patch that reproduces a bug
every time, then that is usually 90% of the work needed to get it
fixed. I'm very unlikely to read really long emails, there is just
too much email in the world these days, but I read every single bug
report, and try almost all patch submitted to the trackers. If I have
a Pd patch that shows me the problem, then I am very likely to try to
fix it.
.hc
On Dec 2, 2009, at 11:36 AM, Matteo Sisti Sette wrote:
Let's suppose 'I' am the user and 'you' are the developer, which I
guess is partially true sometimes.Let's also say what should be implicit, that we are discussing for the sake of exchanging ideas, and that nobody is criticising the work of nobody, and also that the fact of replying in a somewhat 'polemic'
tone doesn't mean one feels offended but only that the debate excites him/ her (this is my case, hope it is yours as well).You're right, mine are not suggestions, they are demands.
Wich leads me to what seems to be the (or one) underlying point throughout your email, that is: what right do I have to demand things from you? Why should you listen to my demands and work to fulfill [dunnow if it is the right verb here] them? What do you get from it?
Well, I admit I don't know the answers; in a commercial software scenario it is easier, because you are paid to develop the software,
and I [am supposed to] pay to use it, so asking to fix things is a right
for me, and fixing things is a due for you. This is not the case with
FLOSS and I don't really know what is the motivation for the developer to, well, develop. But I assume there is one, because if there wasn't one then the software would'nt exist and we wouldn't be talking about
it. I have to assume that for some reason you (the developer) are interested in developing the software and in making it the best it can be. Otherwise, we wouldn't be talking in the first place.So, I don't have any right to demand anything, I am very grateful that PD exists the way it is, with its bugs and everything, and you don't have to fix anything; but assuming you are interested for some
reason in developing the software and you are doing it, what kind of
contribution can I give as a user? The answer is "feedback", and feedback consists, among other things,
in DEMANDS. These demands can be reasonable or foolish, that is, the feedback from the user can be valuable or useless.The latter also holds for bug reports (another kind of feedback),
which can actually help to fix the bug or not.[.......] allowing the user to go "beyond limits" usually involves more sophisticated code: easier to make errors, easier to create bugs.
Well yes, I agree with that, or I understand that. Does that mean that we should be happy with the presence of bugs? Seems like you're saying: "What do you prefer, a boring, simple,
limited but rock-solid software, or a powerful, flexible [whatever
positive adjective you may want to add here] but buggy one?" Well if I, as a user, had to choose I would probably agree with you
in chosing the second one, but you, as a developer, are [should be/ may be/whatever] committed to go towards the goal of the flexible,
powerful [etc] AND rock-solid software...Jesus, are we discussing whether bugs should be fixed or not?????????
Remember (I say this to myself too) that the whole "debate" arose
because somebody mentioned a situation of instability and I pointed
out that it seems to be particularly frequent with big patches in PD. So, let's try not to take this as a criticism (maybe the tone of my
first mail didn't help in this sense). PD is constantly under
development, isn't it? It is not a "finished" product (if such a
thing even exists). So, it has its strengths and weaknesses, like
every piece of software. It doesn't make sense to discuss whether
the first compensate the latter or viceversa; it MAY make sense to
analyze its strengths and merits; but I think it is more useful to
point out weaknesses so that they can be worked on in the future.What are the weak points of PD (don't be afraid, I won't try to list
them)? Well, to make an example everybody knows the graphical
interface is tremendously slow. That is well known; I don't know how
much priority the developer community give to that problem (quite
low I guess), but the problem is well known, so there is no need to
discuss about it. One thing that I have experienced, and that a few users have
experienced but, I suspect, not so many, is that with huge patches
things start becoming unstable. Since it is not so frequent to "hit"
this problem, when I did, I gave my feedback about them, including
bug reports when I could isolate some reproducible crash, and test
patches when I could. Now, since another user commented about
instability with huge patches, I took the opportunity to stress
again the importance that this kind of issue has (imo, obviously),
and to express the feeling (possibly wrong) that they are not given
the importance they deserve. That's all.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.Well, unfortunately I can't do it better, and about the second
option, I guess you are sarchastic. I think there's a third thing I
can do: give the developers information (i.e. reports, test patches, etc)
that can help them doing it better, which implies the assumption
that they are interested in doing it better. If every time I do that
I should feel like I was telling them what they MUST do, thus
offending them, well, then I probably had better unsubscribe this
mailing list.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".(first, I didn't say I don't trust you; I just said I can't give you
what is not mine, stop) No, I just think I have to report the bug with as much information
as I can; if that is not enough to fix the bug, well, I tried. I
think the developer usually has much more information than the user,
and sometimes with some clues can find the problem even without a
directly reproducible crash. Obviously your oversimplification or
example is exagerated.I am a developer also (or I consider myself such), though I don't
develop in C++; obviously my work is way way simpler than something
even comparable to a software like PD. But sometimes "my users"
simply report that things "don't work" and they are not capable of
giving me a directly reproducible error that I can investigate, nor
anything better than a confused explanation. I don't consider their
duty to do so, I rather consider my duty to find out what's wrong,
which is my error in the first place. Anyway, the fact that there's
no simple way to reproduce the problem has no relevance in
evaluating the importance of fixing it. That can be very
frustrating, I know. However, I recognize this is not the same thing because I do get
paid for the work.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.Well I must recognize you are right here. But please be sure I didn't mean to "shout".
-- Matteo Sisti Sette matteosistisette@gmail.com http://www.matteosistisette.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I hate it when they say, "He gave his life for his country." Nobody
gives their life for anything. We steal the lives of these kids. -
Admiral Gene LeRocque
On Wed, 2 Dec 2009, Hans-Christoph Steiner wrote:
Here's a friendly suggestion, instead of spending time writing giant emails, spend that time trying to isolate the bugs that you are complaining about.
One is lost in the code, and you tell him that the solution is to spend more time running around in no particular direction.
Here's a friendly suggestion : stop replying to mails that you don't read and don't care about.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Matteo Sisti Sette wrote:
[.......] allowing the user to go "beyond limits" usually involves more sophisticated code: easier to make errors, easier to create bugs.
Well yes, I agree with that, or I understand that. Does that mean that we should be happy with the presence of bugs? Seems like you're saying: "What do you prefer, a boring, simple, limited but rock-solid software, or a powerful, flexible [whatever positive adjective you may want to add here] but buggy one?" Well if I, as a user, had to choose I would probably agree with you in chosing the second one, but you, as a developer, are [should be/may be/whatever] committed to go towards the goal of the flexible, powerful [etc] AND rock-solid software...
i am sure that everyone agrees with that. it is only, that bugs do happen. and i think that they happen more often when writing more complicated code.
not everybody here is called knuth.
Jesus, are we discussing whether bugs should be fixed or not?????????
i don't think we are discussing that (at least i hope; the thread seems to have the tendency towards such a discussion; i want to avoid it, as the answer is clear for me anyhow). in order to avoid more confusion: yes, i agree that all bugs should be fixed.
(note that i don't _believe_ that all bugs _can_ be fixed; but this another thing)
I am a developer also (or I consider myself such), though I don't develop in C++; obviously my work is way way simpler than something even comparable to a software like PD.
i wish people would stop saying that there work is inferior than others they build upon. it's only slightly more annoying than people saying there work is better than the ones they build upon :-) (seriously: don't make yourself worse than you are; even if you cannot write something comparable to Pd, you can probably write things that those writing Pd cannot do)
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.
Well I must recognize you are right here. But please be sure I didn't mean to "shout".
oh, i said i was polemic.
fgmasdr IOhannes
On Wed, 2 Dec 2009, Matteo Sisti Sette wrote:
Well, I admit I don't know the answers; in a commercial software scenario it is easier, because you are paid to develop the software, and I [am supposed to] pay to use it, so asking to fix things is a right for me, and fixing things is a due for you.
It's not that easy with commercial software either. Naturally, it depends on the specific company and product. But chances are that if you just found a rare-enough bug (difficult to come across), then for the company it might make more business sense to take the time that could be spent on your bug and instead allocate this effort on increasing the deliberate vendor lock-in, even considering the impact on their own reputation. Companies may decide to fix the bug anyway, and in that case, consider yourself lucky.
This is not the case with FLOSS and I don't really know what is the motivation for the developer to, well, develop.
That's great of you: some people would instead claim that they know, and then when they see real behaviour of FLOSS authors they'd call it "illogical" or "paradoxical". Those people don't know that they don't know, whereas you, you don't claim to know. And frankly, no-one can find all of the reasons.
but assuming you are interested for some reason in developing the software and you are doing it, what kind of contribution can I give as a user? The answer is "feedback", and feedback consists, among other things, in DEMANDS.
There's this major difference between «demand» in English and «demande» in French, such that both of those words get translated to a completely different-looking word in the other language. I believe you are meaning to say «demande» as in French, because «demand» in English is more like an order for something that MUST be done. The invisible walls of language are worsened by the fact that people do as if they can always rely on nonverbal cues, even when they read pure text.
Well yes, I agree with that, or I understand that. Does that mean that we should be happy with the presence of bugs? Seems like you're saying: "What do you prefer, a boring, simple, limited but rock-solid software, or a powerful, flexible [whatever positive adjective you may want to add here] but buggy one?"
Depends on which bugs. Bugs have different priorities. Different people put different priorities on bugs.
It is not a "finished" product (if such a thing even exists).
Miller Puckette opened the 2007 convention by saying that PureData is almost finished.
What are the weak points of PD (don't be afraid, I won't try to list them)? Well, to make an example everybody knows the graphical interface is tremendously slow. That is well known; I don't know how much priority the developer community give to that problem (quite low I guess), but the problem is well known, so there is no need to discuss about it.
At the time of the 2007 convention I worked a bit on accelerating TkCanvas. I mentioned it on the pd-list but got no replies. I don't recall anyone else suggesting that as a solution.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Mathieu Bouchard escribió:
It's not that easy with commercial software either. [...]
Well I was just implying that with commercial software I feel the RIGHT to complain about bugs and EXPECT (in the sense of "demand" in english, lol, not of real expectation) them to be fixed, because software is the only field where you BUY something that does not work and are even supposed to accept that, which I don't. I didn't imply that companies will do what I would expect them to do according to what I think is their moral duty. Indeed business strategy will usually push them to the exactly opposite direction. They will wait for the next majour release to fix bugs, so that you pay again for something you have already bought. That's why I think nobody should ever pay for software. Well, I would indeed be happy to pay for software if it was bug free, but if I take for true what seems to be an almost universally shared opinion, that bug free software does not and won't ever exist, then I must conclude, that nobody should pay for software.
There's this major difference between «demand» in English and «demande» in French, [..] I believe you are meaning to say «demande» as in French, because «demand» in English is more like an order for something that MUST be done.
Oh... I don't speak a word of French, so I'm not sure, you may be right. I meant (and understood) "demand" more or less as "asking" someone to do something, not necessarily in an imperative way.
Miller Puckette opened the 2007 convention by saying that PureData is almost finished.
Hahahahahahha, yes, I remember that was mentioned in the mailing list. But even if I don't know Miller at all, I had seen his performance in Barcelona at "OFF ICMC 2006" so I already knew he has a great sense of humor.
Matteo Sisti Sette wrote:
I meant (and understood) "demand" more or less as "asking" someone to do something, not necessarily in an imperative way.
Demand is a strong word. It implies such position of power that you have a right to make a demand.
Free software is such a gift that developers have more place to "demand" that you learn to code C and fix the bug yourself or contribute better documentation, than you have to "demand" they improve the software. Or you could always make a financial agreement, and offer money, and demand in return that they fix the software in the way you wish. Ardour, for example, has worked well with this micro-sponsored open source development model.
Justin Glenn Smith escribió:
Matteo Sisti Sette wrote:
I meant (and understood) "demand" more or less as "asking" someone to do something, not necessarily in an imperative way.
Demand is a strong word. It implies such position of power that you have a right to make a demand.
Ok then I used the wrong word and apologize for that. I meant something more like "requirement". About not having the "right" to state the requirement I already explained myself.
On Wed, 2 Dec 2009, Matteo Sisti Sette wrote:
Well I was just implying that with commercial software I feel the RIGHT to complain about bugs and EXPECT (in the sense of "demand" in english, lol, not of real expectation) them to be fixed, because software is the only field where you BUY something that does not work and are even supposed to accept that, which I don't.
That's because software is the only field in which new developments are called "maintenance". It's also the only field in which the only thing you ever do is plan (a computer programme is a plan). It's also the only field in which the cost of repairing a mistake is that much low. Therefore the market expands to handle the biggest plans that human minds can possibly handle, as there aren't so many consequences to making a mistake here and there.
I didn't imply that companies will do what I would expect them to do according to what I think is their moral duty.
I think that their first moral duty is to express all of the disclaimers that they mean, before you buy. All of the rest is optional.
but if I take for true what seems to be an almost universally shared opinion, that bug free software does not and won't ever exist,
I believe that bug-free software is possible. I also believe that it is not a very interesting fact, because all it focuses on are all-or-nothing things: no bug vs any number of any bugs. Basically any other fact about bugs is more important than that. Before facts, though, you need definitions and agreements. A «bug» in the «bug tracker» is somewhat likely to not be one. Bugs are only relative to a statement of what the programme should do.
Oh... I don't speak a word of French, so I'm not sure, you may be right. I meant (and understood) "demand" more or less as "asking" someone to do something, not necessarily in an imperative way.
I guessed that if you made the mistake I thought you had made, then it must be having some kind of link with the same mistake in French.
Miller Puckette opened the 2007 convention by saying that PureData is almost finished.
Hahahahahahha, yes, I remember that was mentioned in the mailing list. But even if I don't know Miller at all, I had seen his performance in Barcelona at "OFF ICMC 2006" so I already knew he has a great sense of humor.
I already had read Miller's posts for five years when I attended that keynote. When he said it, it didn't cross my mind for a second that it could be a joke. Instead I firmly believed that he was being serious. I haven't changed my position since, I won't reconsider it, and I'd like you to reconsider yours. Yes, I've seen Miller perform a few times, but it's really unrelated.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Mathieu Bouchard escribió:
I already had read Miller's posts for five years when I attended that keynote. When he said it, it didn't cross my mind for a second that it could be a joke. Instead I firmly believed that he was being serious. I haven't changed my position since, I won't reconsider it, and I'd like you to reconsider yours.
I was just kidding. I hope I didn't offend anybody.
On Wed, Dec 2, 2009 at 5:04 PM, Mathieu Bouchard matju@artengine.ca wrote:
That's because software is the only field in which new developments are called "maintenance". It's also the only field in which the only thing you ever do is plan (a computer programme is a plan).
That's a particularly apt observation. I'm gonna try that one at work.
"No, go away, boss. I'm planning."
--- On Wed, 12/2/09, Matteo Sisti Sette matteosistisette@gmail.com wrote:
From: Matteo Sisti Sette matteosistisette@gmail.com Subject: Re: [PD] Very large patches unstable? To: "Mathieu Bouchard" matju@artengine.ca Cc: pd-list@iem.at Date: Wednesday, December 2, 2009, 11:01 PM Mathieu Bouchard escribió:
It's not that easy with commercial software
either. [...]
Well I was just implying that with commercial software I feel the RIGHT to complain about bugs and EXPECT (in the sense of "demand" in english, lol, not of real expectation) them to be fixed, because software is the only field where you BUY something that does not work and are even supposed to accept that, which I don't. I didn't imply that companies will do what I would expect them to do according to what I think is their moral duty. Indeed business strategy will usually push them to the exactly opposite direction. They will wait for the next majour release to fix bugs, so that you pay again for something you have already bought. That's why I think nobody should ever pay for software. Well, I would indeed be happy to pay for software if it was bug free, but if I take for true what seems to be an almost universally shared opinion, that bug free software does not and won't ever exist, then I must conclude, that nobody should pay for software.
Do you mean to say that "nobody should pay for _proprietary_ software?"
Otherwise, I don't understand how your conclusion follows from your
argument, because free software has no obligation to follow the business
model you describe (well, neither does proprietary software, for that
matter).
Besides, how is it that "existence of bug" = "the software doesn't
work?" Buggs can exist without makking software inoperable, you konw.
-Joanthan
Jonathan Wilkes escribió:
[...] then I must conclude, that nobody should pay for software.
Do you mean to say that "nobody should pay for _proprietary_ software?"
You're right, I meant: "nobody should be charged for using software" Now you can put or not the word "proprietary" and it makes no difference, since nobody can be charged for using FLOS software.
Besides, how is it that "existence of bug" = "the software doesn'twork?" Buggs can exist without makking software inoperable, you konw.
Well, exagerating on purpose, I said "doesn't work" not to mean "is inoperable" but rather "doesn't work 100% as expected". Even if this is very questionable, it was in relation to the comparison with "hardware" commercial products, where usually even small defects give you the right to have the product replaced.
--- On Thu, 12/3/09, Matteo Sisti Sette matteosistisette@gmail.com wrote:
From: Matteo Sisti Sette matteosistisette@gmail.com Subject: Re: [PD] Very large patches unstable? To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Mathieu Bouchard" matju@artengine.ca, pd-list@iem.at Date: Thursday, December 3, 2009, 3:41 AM Jonathan Wilkes escribió:
[...] then I must conclude, that nobody should pay for software.
Do you mean to say that "nobody should pay for
_proprietary_ software?"
You're right, I meant: "nobody should be charged for using software" Now you can put or not the word "proprietary" and it makes no difference, since nobody can be charged for using FLOS software.
That's not true: http://www.gnu.org/philosophy/selling.html
Besides, how is it that "existence
of bug" = "the software doesn't work?" Buggs can exist without makking software inoperable, you konw.
Well, exagerating on purpose, I said "doesn't work" not to mean "is inoperable" but rather "doesn't work 100% as expected". Even if this is very questionable, it was in relation to the comparison with "hardware" commercial products, where usually even small defects give you the right to have the product replaced.
But in the hardware example, you're paying money for a product, and (at least in the U.S.) I think your demands to have the product replaced that you are speaking of stem from the Uniform Commerce Code. That's a demand in the true sense. With the free software examples we're talking about, you're not paying a fee to download and use the software. There's certainly still a code by which people work and interact, but it's much more elusive and far from uniform.
-Jonathan
Jonathan Wilkes escribió:
You're right, I meant: "nobody should be charged for using software" Now you can put or not the word "proprietary" and it makes no difference, since nobody can be charged for using FLOS software.
That's not true: http://www.gnu.org/philosophy/selling.html
I may be missing something, but it seems to me that you can be charged for GETTING free software, you cannot be charged for USING it.
On Thu, 3 Dec 2009, Matteo Sisti Sette wrote:
I may be missing something, but it seems to me that you can be charged for GETTING free software, you cannot be charged for USING it.
I am allowed to run a Free Software application rental business and charge the customer by the minute, or by the total number of pixels written to disk. What's wrong with that?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Jonathan Wilkes escribió:
Well, exagerating on purpose, I said "doesn't work" not to mean "is inoperable" but rather "doesn't work 100% as expected". Even if this is very questionable, it was in relation to the comparison with "hardware" commercial products, where usually even small defects give you the right to have the product replaced.
But in the hardware example, you're paying money for a product,
Exactly, that's why I said that _if you buy_ software you should "demand" that it works. Obviously that doesn't hold for free software you don't pay for, that was my point.
On Dec 3, 2009, at 5:53 AM, Matteo Sisti Sette wrote:
Jonathan Wilkes escribió:
Well, exagerating on purpose, I said "doesn't work" not to mean "is inoperable" but rather "doesn't work 100% as expected". Even if this is very questionable, it was in relation to the comparison with "hardware" commercial products, where usually even small defects give you the right to have the product replaced.
But in the hardware example, you're paying money for a product,
Exactly, that's why I said that _if you buy_ software you should
"demand" that it works. Obviously that doesn't hold for free
software you don't pay for, that was my point.
If you pay for Free Software, then you can also demand that it works.
Since you want to make demands, I suggest paying someone to listen to
them :)
.hc
Information wants to be free. -Stewart Brand
Hans-Christoph Steiner escribió:
Since you want to make demands, I suggest paying someone to listen to them :)
I don't know who said I want to make demands
On Wed, 2 Dec 2009, Matteo Sisti Sette wrote:
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.
In almost all of Pd, singly-linked lists are used. That's even more inefficient than doubly-linked lists.
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.
Quite often, it's even O(n) vs O(n^2).
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?"
I agree about this but it would be foolish to not think about how those modifications to the source code would get distributed. There's not much that I would bother to write for pd-vanilla, without à priori getting an explicit note from the man, certifying that the proposal won't sit for æternal rest in the holy sourceforget repository of forgotten diffs.
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.
You can't learn that in a culture that encourages people to think of programming by imagining an infinite, strictly-monotonous sequence of ever-bigger computers, whereby if a given programme runs on any infinite subsequence of those computers, it's all fine. ;)
Sometimes however the bugs are too difficult to isolate,
If you still have not tried Valgrind, now is the time. It does wonders.
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'm guilty of that too.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Wed, 2 Dec 2009, IOhannes m zmoelnig wrote:
"i find Pd frustrating because it is so unstable" is for me a highly frustrating statement.
I was also told "we can't install Pd, because it is not secure. so we are using MAX instead." I asked questions about it but got no answers. This is in a university that sponsored a Pd Convention.
<lines intentionally left blang to fill in the usualy rant on FLOSS software and the user>
One minute of silence.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Wed, 2 Dec 2009, Matteo Sisti Sette wrote:
The greatest frustration is when you carefully design something so that size (e.g. number of instances) shouldn't be a problem, you strongly test it within a certain 'size' and verify it is rock-solid, and then, when you have everything working and your project grows a little bit and you just add a couple more instances of something, it stasrts crashing....
[...]
In some cases some developer (I won't tell the name, but it's someone very important here) was able to find specific bugs and fixed it and published a new release.
I think it's more constructive to say who fixed bugs, even if it's someone who wrote the bugs in the first place. We shouldn't have a culture in which bugs are that much shameful, because it steepens a few learning curves, it raises the entry level, and it causes finished externals to stay sitting on their author's hard disk just because it's too long to review it to ensure it contains no potentially embarrassing mistakes...
http://en.wikipedia.org/wiki/File:CatalysisScheme.png
complex, scalable design; but the implementation doesn't support it at the end. Also, these kind of bugs are very difficult to isolate.
It's hard to do anything about this unless we are talking about specific cases. I'd rather have you point at specific bugs than making general claims.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Mathieu Bouchard escribió:
In some cases some developer (I won't tell the name, but it's someone very important here) was able to find specific bugs and fixed it and published a new release.
I think it's more constructive to say who fixed bugs, even if it's someone who wrote the bugs in the first place. We shouldn't have a culture in which bugs are that much shameful,
Wait wait wait, i'm SORRY for the terrible MISUNDERSTANDING here - well i'd rather call it MISEXPLAINING to place the blame on the right place, which is on me.
The reason why I didn't tell the name wasn't ABSOLUTELY that. That possibility didn't even come up to my mind, and no, I don't consider bugs a shameful thing, not only that much but not even a bit. Also, the part of not telling the name was a kind of a joke since I _thought_ it was clear I was talking about Miller. I didn't "want to" tell the name (facetiously) in order to avoid "setting a precedent" so that every user would start sending Miller crashing patches and expect bug fixes for the next day. When Miller wrote me (publicly in this m/l) to send him a crashing patch (in reply to a message of mine about some bug), he started the message with "It's a dangerous thing to offer, but...".
On Wed, 2 Dec 2009, Matteo Sisti Sette wrote:
Wait wait wait, i'm SORRY for the terrible MISUNDERSTANDING here - well i'd rather call it MISEXPLAINING to place the blame on the right place, which is on me.
That's what the problem is. I want you to put the blame on a piece of code, not on any person, even you.
Also, the part of not telling the name was a kind of a joke since I _thought_ it was clear I was talking about Miller.
We have no idea. We still have no info about your bug about big patches, except that it's about big patches and that it frustrates you. The bug could be involving anyone else's GUI classes, but how would we know?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Mathieu Bouchard escribió:
Also, the part of not telling the name was a kind of a joke since I _thought_ it was clear I was talking about Miller.
We have no idea. We still have no info about your bug about big patches, except that it's about big patches and that it frustrates you.
Errr........
You are confusing me.
No, right now I am not working on any big patch and I am not experimenting any frustrating bug.
( Well, actually, right now I am working with GEM and even with a dozen of objects I experiment some sudden crashes every now and then which have brought me to the point that I now hit CTRL+S without even realising. But that's almost surely GEM, and I won't even care until I test it on the target machine which is a mac (me on windows now) with dunnow-which version of Extended (me using vanilla + the last gem). )
The one that was reporting a specific problem was the guy who started the thread; I was just speaking in general terms. I had some problems with huge patches in the past; I usually had strict deadlines so I had to go on with whatever workaround saved the show.
When I mentioned the fact that Miller fixed some bug I reported, it was not supposed to matter what bug since it is now fixed...
Wait wait wait, i'm SORRY for the terrible MISUNDERSTANDING here - well i'd rather call it MISEXPLAINING to place the blame on the right place, which is on me.
That's what the problem is. I want you to put the blame on a piece of code, not on any person, even you.
Errrr..... no, I meant the blame about the misunderstanding: I don't like the word "misunderstanding" because it seems to blame the person who misunderstood, while the responsible may perfectly be the person who didn't explain clearly.
On Thu, 3 Dec 2009, Matteo Sisti Sette wrote:
You are confusing me. No, right now I am not working on any big patch and I am not experimenting any frustrating bug.
I'm sorry.
Well, actually, right now I am working with GEM and even with a dozen of objects I experiment some sudden crashes every now and then which have brought me to the point that I now hit CTRL+S without even realising.
There are so many ways to bring Pd to its knees by doing funny patching, that it's a good idea to hit Ctrl+s often, especially when I have many patches and subpatches and am bound to forget what are the changes I made since last crash. It's quite often not Pd's fault at all. Whether I do infinite recursion, boundless [until], flooding the console, testing a new external I wrote too quickly, or do something well-defined that just happens to want 50000% CPU, it's all the same, Ctrl+s, Ctrl+s, Ctrl+s, ...
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Mathieu Bouchard escribió:
Well, actually, right now I am working with GEM and even with a dozen of objects I experiment some sudden crashes every now and then which have brought me to the point that I now hit CTRL+S without even realising.
There are so many ways to bring Pd to its knees by doing funny patching,
It's not my case, no funny patching at all. I have now realised it happens mostly when I save an abstraction which is used a few times (in the order of 25, not thousands) in the main patch.
I think it must be some gem object because I think I did this thousands of times with PD alone (though I try to avoid it if I can), and with no crashes....
Obviously if I happen to find a 100% reproducible case I'll post it.
On Thu, 3 Dec 2009, Matteo Sisti Sette wrote:
It's not my case, no funny patching at all. I have now realised it happens mostly when I save an abstraction which is used a few times (in the order of 25, not thousands) in the main patch. I think it must be some gem object because I think I did this thousands of times with PD alone (though I try to avoid it if I can), and with no crashes.... Obviously if I happen to find a 100% reproducible case I'll post it.
It doesn't need to be a 100% reproducible crash. If you run Pd in Valgrind and it finds "Invalid Write", that is most certainly a bug already, and it's possible that it triggers a Valgrind error 100% of the time on any machine, or that it triggers a crash 100% of the time on any machine, but that if you run it outside of Valgrind, it crashes only sometimes and only on some machines. That way, Valgrind is a great tool for finding bugs, especially elusive ones.
That said, there are some bugs that are more elusive than that, and for example, they may be completely invisible in Valgrind and crash 0% of the time in Valgrind, but crash some random % of the time outside of Valgrind...
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
-
Charles Henry -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Jonathan Wilkes -
Justin Glenn Smith -
Martin Peach -
martin.peach＠sympatico.ca
-
Mathieu Bouchard -
Matteo Sisti Sette