[PD-dev] bug when redrawing gop within gop inside a closed sub-patch

[Hans-Christoph Steiner]

On Nov 19, 2009, at 10:04 PM, Ivica Ico Bukvic wrote:

>> 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's the one line?

Here's what I found, not being able to open the subpatch happens on Pd  
0.42.5 and Pd-extended 0.42.5-2009-1112, but not with pd-gui-rewrite/ 
0.43

The level of visual cruft left behind varies:  vanilla none, extended  
text, pd-gui-rewrite/0.43 the whole sub-subpatch...

So if we get the lack of visual cruft of 0.42.5 combined with pd-gui- 
rewrite/0.43's functional subpatch, we are golden :)

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

Miller posts his source notes:
http://puredata.info/docs/developer/sourcenotes

Did you see Martin Peach's docs? Its the current best. Also, there is  
this,but its minimal, but please add to it!
http://puredata.info/docs/developer/PdAPI
http://puredata.info/docs/developer/DictionaryOfMacros

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


Yes, that is indeed a core motivation. I am about to start work on it  
again, so I'd love to hear feedback on how it could be made easier to  
understand and easier to customize using plugins, etc.  And of course  
code, patches, bug reports, etc. are encouraged!

.hc


----------------------------------------------------------------------------

There is no way to peace, peace is the way.       -A.J. Muste