Friday 30 August 2013

Another failed patch

Whilst doing the long overdue merge of trunk into my invoke-diff-cmd branch, I spotted a deprecation warning that looked like a minor oversight, and so, I fixed it, svn compiled, the tests passed and ... the patch turned out to be a no-can-do, because APR_ARRAY_PUSH doesn't care what type you stuff in there.

I thought it did, because of this:

#define APR_ARRAY_PUSH(ary,type) (*((type *)apr_array_push(ary))) 

which *looks* like it's type-safe at least if you don't know what you're really looking at (and if you haven't bothered to check the underlying code to see what it actually does).  It of course does no such thing -- so, what does this trick that does seemingly nothing actually do?

Ask on #svn-dev and ye shall receive:

[19:32] <breser> gbb: The reason it takes a type is to avoid warnings.  The apr_array_push() function returns a void *.  Technically there's no issue with putting any pointer in a void pointer, however some  compilers will warn you about that since you may not be doing it intentionally.                                                        
                                                                      
[19:33] <breser> gbb: The array code doesn't care what the pointer is  to, it's up to the user of APR Arrays to keep their types straight.   
                                                                      
[19:34] <breser> gbb: In this case the fact that the array code is  taking a type (and casting) is hiding the errors/warnings you would have otherwise seen.                                                                                                                     
[20:30] <Bert> breser, gbb: Apr arrays can be of different kinds than just pointers. In some cases we have arrays of specific struct kinds  (e.g. for property changes in the diff handling) 

Thank you Ben and Bert, it certainly did clear things up, and made me look up the 'long answer' --- the very short answer of course is that C isn't C++, and so doesn't have type-safe templates.  Caveat coder!

Monday 26 August 2013

DIY Quoting Tutorial Kit

Here's a link to a great UNIX quoting tutorial, and some lovely harp music to study with:


You supply the tea, and when the music is over and the cup is empty, you'll know how to quote just about anything and everything.  You can quote me on that.

Saturday 24 August 2013

Does Bamboo implement the Dining philosopher's problem?

I read a paper[1] on the enigma of Bamboo's gregarious flowering and I think I have an idea for the solution to the puzzle as to why this phenomenon occurs.

1. Bamboo is wind pollinated.

2. The flowering (whilst almost simultaneous) actually 'moves' through the population like a wave.

However, what if the plants 'voted' every season by releasing a few molecules of a chemical messenger and once a critical mass of this chemical has been accumulated, those plants then themselves start the same way if they are fit enough to bloom, or send out a different 'nay' chemical messenger that neutralises the 'yea' if they are not fit.

Once enough plants are producing the the 'yea' chemical (and the 'nays' are outweighed) so that a critical mass is achieved, it would trigger the hormone that makes the plant bloom so that the wind pollination has the greatest possible effect.  And even if some plants are not ready, the substance when prolific may still have the ability to force flowering, which would explain the uniformity. 

In fact, if I was to design such a population and write a simulation for such a model, this is probably the way I'd go about it, because I can think of no better viability test for a wind pollinated species that rarely flowers to ensure optimal success than such a chemical voting system.

Note it doesn't have to be very noticeable, the actual messenger substance may just be a few molecules -- in the same way that human noses can pick out a one molecules of mercaptan in a huge space for example.  If we didn't know what smells so bad, it would be difficult to find!

[1] http://www.pdn.ac.lk/cjsbs/text/text35.2.1.pdf