> That's not a reason for removing it. I never said it was. It was simply icing on the cake, if you like: pd-extended exhibits a problem that pd-vanilla doesn't exactly because of this one line. Namely, this is the culprit for profuse canvas errors every time an object is updated that is visible on a GOP of a closed sub-patch (and hence it is not really visible). Please see my previous email regarding this.
On the flip-side, I am sure there must be a reason why this thing was put in there in the first place, it is just that I am unable in my set of tests to reproduce its relevance beyond the said regression. So, if anyone is aware of the reason for its placement, it would be most helpful to learn more about that before making the final decision whether to keep/remove it. > > > What really eats a lot of time, is lack of comments/annotations in the > > code making it rather difficult to trace things down... > > What would those comments tell you? What things like "&x->x_obj.te_gobj.g_pd" (to use your example) mean (e.g. struct structure and function of g_pd vs. te_gobj vs. x_obj etc.) and how and why they are being used. As it is right now, it takes forever to grep the stuff and figure out what each line/call actually does. Even a good chunk of calls have IMHO vague descriptions (like canvas_map call, if I recall correctly the name). Unless I am mistaken (and please do correct me if I am wrong) this call is for both mapping and unmapping, yet the description suggests it is about mapping only. All that said, I may have very well missed something, so if there is a good resource that shows the code tree and basic API information, that would be certainly very helpful and most appreciated. > If those comments are wrong or eventually went wrong by lack of > updating, > who would actually take the time to update those comments? What > would > ensure that those comments stayed right? And what's the damage > caused by a > wrong comment compared to no comment? I think we're already there. Please see my comment above. Besides, "no comment" is just as bad as "bad comment" if you have no easy way to understand the api/variables and their functions. It's like asking a question if you were lost in a jungle, would you prefer no map or a misleading map. My answer would be neither. > What about removing distracting stuff like unused variables, struct > member > prefixes and struct nesting like &x->x_obj.te_gobj.g_pd instead of just x, > and stuff like that? If it makes it more legible without breaking the code, I am all for it. That said, I don't feel I am up to the task until I am able to fully understand the api/code as I have no idea even which of these are unused/obsolete and/or what is their primary function/role. Hunting for these three bugs alone has taken up 40+ hours of my time, most of which was used to trace what each call/variable does. I would love to contribute more, but time is a precious commodity we are all short on. So, for the sake of making contributions easier, IMHO I think it would be a great idea to overhaul the code to the point where it is possible to make such contributions much more efficiently. I am hoping that this is what Hans is trying to do with the gui rewrite. Best wishes, Ico _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev