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

Mathieu Bouchard matju at artengine.ca
Mon Nov 23 19:44:14 CET 2009


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


More information about the Pd-dev mailing list