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
_______________________________________________
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
