Please see attached patch. it appears whenever there is change in the gui of a closed sub-patch that has GOP sub-patch showing another GOP-ed subpatch (try reading that aloud) the redraw is attempted resulting in an error in a console. Probably the best thing is to test the attached patch. The good news--this is a non-lethal bug.
Basically run pd from terminal, open the patch and try changing the symbol value. You will likely get an error on the shell (not Pd console) stating:
invalid command name ".x89d1d08.c" (or whatever the name is of the sub-patch)
Now if you open the sub-patch [pd tester] that has a subpatch with GOP and another one below it in a GOP (visible through parent GOP), everything is fine.
#N canvas 258 155 296 207 10; #X symbolatom 115 54 10 0 0 0 - - -; #X obj 115 76 s test; #N canvas 538 176 297 192 tester 0; #N canvas 7 175 450 300 asdasdasda 0; #N canvas 2 50 450 300 blah 0; #X symbolatom 110 120 10 0 0 0 - - -; #X obj 113 29 r test; #X obj 98 61 prepend set; #X connect 1 0 2 0; #X connect 2 0 0 0; #X coords 0 -1 1 1 85 60 1 100 100; #X restore 127 119 pd blah; #X coords 0 -1 1 1 150 90 1 100 100; #X restore 66 44 pd asdasdasda; #X coords 0 0 1 1 300 80 0; #X restore 108 112 pd tester; #X connect 0 0 1 0;
Ico
Ok, here's the fix. This solves all but a few of the similar errors at patch closing (e.g. open the same pd patch-> open subpatch-> close subpatch-> close main patch-> get 2 errors invalid command name ".<window_name>.c".). This remaining bug does not happen if you close the entire patch with both windows open.
At any rate, the other fix is attached.
ico
On Thu, 2009-11-19 at 01:44 -0500, Ivica Ico Bukvic wrote:
Ok, here's the fix. This solves all but a few of the similar errors at patch closing (e.g. open the same pd patch-> open subpatch-> close subpatch-> close main patch-> get 2 errors invalid command name ".<window_name>.c".). This remaining bug does not happen if you close the entire patch with both windows open.
At any rate, the other fix is attached.
ico
Never mind. Just found a regression on this patch (when you disable gop, stale objects do not get removed). I'll keep searching and report when I have something...
Ico
All right. So, I've done some digging on this one and found out the following:
The bug affects all versions of Pd and behaves even worse in 0.43 extended. Given that Pd is all about abstracting one's work, I would consider this a high-priority bug.
Basically it has to do with having a GOP-enabled sub-patch that has another GOP-enabled sub-patch visible within its parent GOP.
Problems: 1) when turning off GOP on the parent subpatch through which you can see child GOP-enabled sub-patch, after applying settings, the parent sub-patch converts to a regular object but clicking on it does nothing and results in console errors like this:
bad window path name ".x9e91188" bad window path name ".x9e91188.c" bad window path name ".x9e91188" bad window path name ".x9e91188" bad window path name ".x9e91188.c" bad window path name ".x9e91188"
Doing the same while the child sub-patch is visible has no negative effect. See below patch for example (open [pd test] sub-patch and disable GOP in the pd parent-tester or whatever its name) and then try opening it.
2) when the same happens, there are sometimes stray objects left that were previously visible through GOP rectangle. they cannot be interacted with and are just leftover graphics. This is the case with both vanilla and pd-extended.
3) the problem also exists if you want to change the number on the main patch (provided below) that sends data to tester-child. This will result in similar errors on the console. This one affects only pd-extended and the offending line is in g_editor.c function gobj_shouldvis (around line 84):
sys_vgui(".x%lx.c raise all_cords\n", glist_getcanvas(glist));
This should be commented out as it is not present in vanilla version and is causing the problem I described in my earlier email.
Please see patch below:
#N canvas 265 330 294 205 10; #X obj 115 76 s test; #N canvas 696 341 288 186 tester 0; #N canvas 16 267 440 290 tester-parent 0; #N canvas 5 125 450 300 tester-child 0; #X obj 113 29 r test; #X floatatom 124 117 5 0 0 0 - - -; #X msg 130 60 set $1; #X connect 0 0 2 0; #X connect 2 0 1 0; #X coords 0 -1 1 1 85 60 1 100 100; #X restore 132 112 pd tester-child; #X coords 0 -1 1 1 150 90 1 100 100; #X restore 67 58 pd tester-parent; #X coords 0 0 1 1 300 80 0; #X restore 108 112 pd tester; #X floatatom 113 41 5 0 0 0 - - -; #X connect 2 0 0 0;
Any ideas how to tackle this one? Seems like a real pickle to me...
Ico
That's a tough one. I made a simpler version of your bug patch with directions. But I agree, there is a lot of potential to GOP, but only if it is rock-solid.
.hc
On Nov 19, 2009, at 3:31 PM, Ivica Ico Bukvic wrote:
All right. So, I've done some digging on this one and found out the following:
The bug affects all versions of Pd and behaves even worse in 0.43 extended. Given that Pd is all about abstracting one's work, I would consider this a high-priority bug.
Basically it has to do with having a GOP-enabled sub-patch that has another GOP-enabled sub-patch visible within its parent GOP.
Problems:
- when turning off GOP on the parent subpatch through which you can
see child GOP-enabled sub-patch, after applying settings, the parent sub-patch converts to a regular object but clicking on it does nothing and results in console errors like this:
bad window path name ".x9e91188" bad window path name ".x9e91188.c" bad window path name ".x9e91188" bad window path name ".x9e91188" bad window path name ".x9e91188.c" bad window path name ".x9e91188"
Doing the same while the child sub-patch is visible has no negative effect. See below patch for example (open [pd test] sub-patch and disable GOP in the pd parent-tester or whatever its name) and then try opening it.
- when the same happens, there are sometimes stray objects left that
were previously visible through GOP rectangle. they cannot be interacted with and are just leftover graphics. This is the case with both vanilla and pd-extended.
- the problem also exists if you want to change the number on the
main patch (provided below) that sends data to tester-child. This will result in similar errors on the console. This one affects only pd-extended and the offending line is in g_editor.c function gobj_shouldvis (around line 84):
sys_vgui(".x%lx.c raise all_cords\n", glist_getcanvas(glist));
This should be commented out as it is not present in vanilla version and is causing the problem I described in my earlier email.
Please see patch below:
#N canvas 265 330 294 205 10; #X obj 115 76 s test; #N canvas 696 341 288 186 tester 0; #N canvas 16 267 440 290 tester-parent 0; #N canvas 5 125 450 300 tester-child 0; #X obj 113 29 r test; #X floatatom 124 117 5 0 0 0 - - -; #X msg 130 60 set $1; #X connect 0 0 2 0; #X connect 2 0 1 0; #X coords 0 -1 1 1 85 60 1 100 100; #X restore 132 112 pd tester-child; #X coords 0 -1 1 1 150 90 1 100 100; #X restore 67 58 pd tester-parent; #X coords 0 0 1 1 300 80 0; #X restore 108 112 pd tester; #X floatatom 113 41 5 0 0 0 - - -; #X connect 2 0 0 0;
Any ideas how to tackle this one? Seems like a real pickle to me...
Ico
----------------------------------------------------------------------------
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
On Thu, 19 Nov 2009, Ivica Ico Bukvic wrote:
Never mind. Just found a regression on this patch (when you disable gop, stale objects do not get removed). I'll keep searching and report when I have something...
there are more GOP bugs than that. I have submitted one on SF recently. After you're done with yours, I bet you'll find a few more. It's something that is hard to get right.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Never mind. Just found a regression on this patch (when you disable
gop,
stale objects do not get removed). I'll keep searching and report when
I
have something...
there are more GOP bugs than that. I have submitted one on SF recently. After you're done with yours, I bet you'll find a few more. It's something that is hard to get right.
Yes, I've been finding them left and right. So far three have been squashed, two of which crash Pd, and one causes potentially high-volume of extraneous errors to the console affecting performance. As it turns out the regression I located above has nothing to do with my fix (although the better fix is the one I reported in my previous email where the raise all_cords call is commented out, as it is not included in pd-vanilla anyhow and I cannot see any benefit of having it there beyond causing aforesaid bug).
What really eats a lot of time, is lack of comments/annotations in the code making it rather difficult to trace things down...
Ico
On Thu, 19 Nov 2009, Ivica Ico Bukvic wrote:
as it is not included in pd-vanilla anyhow
That's not a reason for removing 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?
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?
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?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
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
On Thu, 19 Nov 2009, Ivica Ico Bukvic wrote:
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.
Because objectboxes and messageboxes and atomboxes have become opaque, so the stacking order of wires does matter more. They have to stay on top in order to be more visible, yet the pd architecture is not sophisticated enough to allow pd to force all of its externals to draw all boxes _under_ the wires.
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.)
You can look those up in <m_pd.h>. What kind of comment are you looking for? Where would they be placed? Suppose you are reading one function in particular. Where would be the comment that refers to the meaning of &x->x_obj.te_gobj.g_pd ?
In any case, the deepest meaning of &x->x_obj.te_gobj.g_pd as it could be documented is:
/* I should have learned C++ */
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.
send your comments to Miller and see whether he cares.
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.
Martin Peach wrote the most complete doc of the internals, but I don't recall whether it covers that or not.
If it makes it more legible without breaking the code, I am all for it.
Ok. Well, I did something like that in my branch, but that requires C++ and defining CPLUSPLUS_FACE before including <m_pd.h>.
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.
Why hope?... "Rewrite" is just another name for not rewriting, "GUI" is just another name for less than half of the GUI, and hope is all too often a disease that makes one stand still.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Nov 20, 2009, at 3:14 PM, Mathieu Bouchard wrote:
On Thu, 19 Nov 2009, Ivica Ico Bukvic wrote:
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.
Because objectboxes and messageboxes and atomboxes have become opaque, so the stacking order of wires does matter more. They have to stay on top in order to be more visible, yet the pd architecture is not sophisticated enough to allow pd to force all of its externals to draw all boxes _under_ the wires.
Well, its easy enough to raise all wires. That's what Pd-extended does, but there are a couple bugs with that...
.hc
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.)
You can look those up in <m_pd.h>. What kind of comment are you looking for? Where would they be placed? Suppose you are reading one function in particular. Where would be the comment that refers to the meaning of &x->x_obj.te_gobj.g_pd ?
In any case, the deepest meaning of &x->x_obj.te_gobj.g_pd as it could be documented is:
/* I should have learned C++ */
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.
send your comments to Miller and see whether he cares.
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.
Martin Peach wrote the most complete doc of the internals, but I don't recall whether it covers that or not.
If it makes it more legible without breaking the code, I am all for it.
Ok. Well, I did something like that in my branch, but that requires C ++ and defining CPLUSPLUS_FACE before including <m_pd.h>.
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.
Why hope?... "Rewrite" is just another name for not rewriting, "GUI" is just another name for less than half of the GUI, and hope is all too often a disease that makes one stand still.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801_______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
Access to computers should be unlimited and total. - the hacker ethic
On Sat, 21 Nov 2009, Hans-Christoph Steiner wrote:
On Nov 20, 2009, at 3:14 PM, Mathieu Bouchard wrote:
Because objectboxes and messageboxes and atomboxes have become opaque, so the stacking order of wires does matter more. They have to stay on top in order to be more visible, yet the pd architecture is not sophisticated enough to allow pd to force all of its externals to draw all boxes _under_ the wires.
Well, its easy enough to raise all wires. That's what Pd-extended does, but there are a couple bugs with that...
Btw I don't mean that DD does anything in particular with it. It's just that with the sys_vgui() free-for-all, the Pd GUI itself has no knowledge of which canvasitems have been created last, and so it can't call the 'lower' method (of a tk canvas object) on those items. Using the DD API, it could be done using the same abstraction layer that is used for zoomability, but I don't think I have done anything about keeping boxes below wires.
Given that, your "raise all_cords" is the best solution imho, as the Pd GUI has total control over wires, not boxes, therefore it's much easier to put wires over boxes than to put boxes below wires.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
In any case, the deepest meaning of &x->x_obj.te_gobj.g_pd as it could be documented is:
/* I should have learned C++ */
Except that you would also arguably lose on efficiency, particularly when it comes to encapsulation that Pd is designed around... Still, one could re-title these to something more readable without affecting efficiency and/or requiring moving away from C and that would go a long way towards improving legibility, e.g. all_present_objects.cords.visible.
Why hope?... "Rewrite" is just another name for not rewriting, "GUI" is just another name for less than half of the GUI, and hope is all too often a disease that makes one stand still.
So is 40 hours used for a task that should've taken a fraction of that...
Ico
On Sat, 21 Nov 2009, Ivica Ico Bukvic wrote:
/* I should have learned C++ */
Except that you would also arguably lose on efficiency, particularly when it comes to encapsulation that Pd is designed around...
What are you talking about? If it's arguable, could you please argue about it, so that I can learn something new? In that case, though, which compilers are you talking about, and which elements of the language are you talking about?
and that would go a long way towards improving legibility, e.g. all_present_objects.cords.visible.
What would that piece of code mean? how would you use it? how would it fit with a C<->Tcl/Tk architecture? can it be expressed as C code naturally enough?
So is 40 hours used for a task that should've taken a fraction of that...
«Should» ? If you have used those hours well, you have now 40 hours of experience with the Pd source code, and surely this reduces the time it takes you to find another bug in Pd, or another bug in any other C programme, or another bug in any other programme, even. Well, it would be nice if it took less time to write a programme, read a programme and debug a programme, but unless we really have a good list of time-savers that are demonstrably good, it's hard to claim how many hours it could have been, and even then, it heavily depends on one's experience and on one's reluctance.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
and that would go a long way towards improving legibility, e.g. all_present_objects.cords.visible.
What would that piece of code mean? how would you use it? how would it fit with a C<->Tcl/Tk architecture? can it be expressed as C code naturally enough?
Depends what you refer to as "natural enough." I speak a human language and since this is project developed by humans I would argue that having variable names that convey their function more clearly at the expense of typing a few extra characters certainly seems "natural enough."
So is 40 hours used for a task that should've taken a fraction of
that...
<Should> ? If you have used those hours well, you have now 40 hours of experience with the Pd source code, and surely this reduces the time it takes you to find another bug in Pd, or another bug in any other C programme, or another bug in any other programme, even. Well, it would be nice if it took less time to write a programme, read a programme and debug a programme, but unless we really have a good list of time-savers that are demonstrably good, it's hard to claim how many hours it could have been, and even then, it heavily depends on one's experience and on one's reluctance.
I disagree. Despite knowing more about the code structure, I still have to switch regularly back and forth between .h (documentation) files and the .c source. And that in and of itself doubles my cognitive load and cuts in half my efficiency for as long as I don't know the .h structs by heart, and I certainly have a lot more pressing matters than learning such stuff by heart.
Ico
On Mon, 23 Nov 2009, Ivica Ico Bukvic wrote:
Depends what you refer to as "natural enough." I speak a human language and since this is project developed by humans I would argue that having variable names that convey their function more clearly at the expense of typing a few extra characters certainly seems "natural enough."
Ok, I thought that you were talking about the code structure, and not the identifiers. So I was looking at your dot pattern and trying to guess how that could work.
About identifiers, I would say that it's better to have rather short identifiers on average, but the more local the identifiers are, the shorter the names can afford to be, and the more rarely used the identifiers are, the more they have an advantage at being long. This is notwithstanding the usual conventions such as naming rectangle corners like (x1,y1,x2,y2) and stuff...
<Should> ?
Are my doublequotes being unsupported by your mailer? Iso-latin-1 (and thus the first 256 chars of Unicode) support at least three doublequote styles but it seems that mine (that look like miniature left-shift and right-shift) get converted to other styles.
I disagree. Despite knowing more about the code structure, I still have to switch regularly back and forth between .h (documentation) files and the .c source.
I don't mean that you don't have to do this, I mean that you are probably a lot faster at it now than... 40 hours (of experience) ago. I agree that the naming could have been different and this is why I made my own changes to the naming.
And that in and of itself doubles my cognitive load and cuts in half my efficiency for as long as I don't know the .h structs by heart, and I certainly have a lot more pressing matters than learning such stuff by heart.
Perhaps you could take a few minutes to make yourself a summary of the structs the way you want it? You open m_pd.h and extract the parts you refer to most often, and then your reformat it so that it's easy to access it. Then you print it and stick it on the wall. You may also mail the summary here so that we can know what you mean.
The shortcuts I use involve 0% more CPU on any C++ compiler that I know about. C++ has been carefully designed so that the programmer can have total control on what's going on. Almost every speed decrease is at compile-time and so doesn't affect a running programme. With what C++ provides for nesting structs, you can remove most typecasts from Pd's code, including all the disguised typecasts (every use of te_gobj, g_gobj, x_obj, x_gui, as well as many uses of g_pd).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
<Should> ?
Are my doublequotes being unsupported by your mailer? Iso-latin-1 (and thus the first 256 chars of Unicode) support at least three doublequote styles but it seems that mine (that look like miniature left-shift and right-shift) get converted to other styles.
It could be my phone once again truncating things left and right. <OT>If anyone knows how to disable top-posting on a Droid (Android platform), I would greatly appreciate any hints.</OT>
Perhaps you could take a few minutes to make yourself a summary of the structs the way you want it? You open m_pd.h and extract the parts you refer to most often, and then your reformat it so that it's easy to access it. Then you print it and stick it on the wall. You may also mail the summary here so that we can know what you mean.
The shortcuts I use involve 0% more CPU on any C++ compiler that I know about. C++ has been carefully designed so that the programmer can have total control on what's going on. Almost every speed decrease is at compile-time and so doesn't affect a running programme. With what C++ provides for nesting structs, you can remove most typecasts from Pd's code, including all the disguised typecasts (every use of te_gobj, g_gobj, x_obj, x_gui, as well as many uses of g_pd).
Good idea. I'll try to give it a shot next time I mess with Pd source.
Best wishes,
Ico
On Mon, 23 Nov 2009, Ivica Ico Bukvic wrote:
With what C++ provides for nesting structs, you can remove most typecasts from Pd's code, including all the disguised typecasts (every use of te_gobj, g_gobj, x_obj, x_gui, as well as many uses of g_pd).
Good idea. I'll try to give it a shot next time I mess with Pd source.
Ok, I'll give you an example to be sure:
typedef struct _text { t_gobj te_g; t_binbuf *te_binbuf; t_outlet *te_outlet; t_inlet *te_inlet; short te_xpix, te_ypix, te_width; unsigned int te_type:2; } t_text;
can become:
typedef struct _text : struct t_gobj { t_binbuf *te_binbuf; t_outlet *te_outlet; t_inlet *te_inlet; short te_xpix, te_ypix, te_width; unsigned int te_type:2; } t_text;
so t_text (aka t_object) becomes a variant of t_gobj instead of just containing a t_gobj. This means you never need to cast from t_text* to t_gobj* anymore, and it means you never have to write te_g anymore, but it means you can't write te_g anymore, and that's a little downside. However it's normal that you still have to do explicit casts the other way around because even though in this case a t_text is a t_gobj, it doesn't mean a t_gobj is a t_text.
I use #ifdef to switch between the C and C++ versions of these structs, in binary-compatible ways.
I'm sorry for the repeated typo of writing te_gobj instead of te_g.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
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.
Because objectboxes and messageboxes and atomboxes have become opaque, so the stacking order of wires does matter more. They have to stay on top in order to be more visible, yet the pd architecture is not sophisticated enough to allow pd to force all of its externals to draw all boxes _under_ the wires.
Well, in that case the line in question is a band aid on the problem, not a fix.
Such a redraw call should not try to redraw all cords but only those that are visible, otherwise you get potentially excessive error outputs from tcl/tk reporting that there is no such cord/canvas (e.g. for the ones embedded in sub-patches) that bog pd down. If you have a large patch, you can get literally hundreds of those per every GUI update that eat precious cpu cycles.
There should be a loop that goes through all existing cords and checks whether they are visible and if so, raises them. Otherwise, they should be ignored.
Ico
On Sat, 21 Nov 2009, Ivica Ico Bukvic wrote:
There should be a loop that goes through all existing cords and checks whether they are visible and if so, raises them. Otherwise, they should be ignored.
Why would you need to loop through all existing cords?... I don't understand.
You need to perform only one check per canvas. Basically, if glist==glist_getcanvas(glist), then a canvas' cords are visible when the canvas itself is visible, and if this pd canvas also has a tk canvas, then it can tell the tk canvas to raise all_cords and that's all. You don't need an explicit loop and you don't benefit from one.
(unless someone found a speed optimisation in the use of tk, but then, it would involve more checks than what we're talking about here, and more accounting in order to avoid unnecessary refreshes, etc)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
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
What's the one line?
Please see previous email.
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
Except you get a profuse number of errors that do not go away in console.
Ico