How to arrange for tabs in your code

1. Set up a new computer downstairs.
2. Copy your messy .emacs file onto this machine.
3. Play 'catch the fish' with your cat whilst you look at the keyboard and type emacs
4. Go back upstairs to do stuff.
5. Realise that emacs's server hasn't started and don't think as to why that possibly could be.
6. Go downstairs, do M-x server-start without looking at the screen (because you're still fishing the cat)
7. Profit.

I blame the cat.

μηδέν άγαν {nothing in excess}

One of my (very patient) mentors made the following very true observation about me:

By the way, designing features based on speculation is usually not a good idea. (...)  Maybe there's a bug report in our tracker requesting such functionality? If not, perhaps you don't need to worry too much about that scenario.

I have a habit of assuming the worst case and then try to create something that (hopefully) solves for the entire range of problems/issues that might occur.

This sounds like it's a good thing, and sometimes it is, at other times, it isn't, because the sky is not about to fall.[1]

I've been thinking why that is so. and my best guess is that this probably a function of OO coding on the MUD, where anything and everything can cause surprises, because things interact whilst interactively interacting.

If you've ever replaced 20+ players lives, stats, xp points and equipment because your fun toy caused a chain reaction that you hadn't considered... you get extra careful after the umpteenth time ;-D

 "Objective-C

• You write a protocol for shooting yourself in the foot so that all people can get shot in their feet."

Contact me for a great deal on a used pair of bullet proof sandals.

-=-=-=-=-=-=-=-

[1] From the Omega game:
(you walk into the establishment)

Rampart Healers. Member RMA.

a: Heal injuries (50 crowns)
b: Cure disease (250 crowns)
ESCAPE: Leave these antiseptic alcoves.

(you hit ESCAPE)

OK, but suppose you have Acute Satyriasis?

Why checkpoint commits are a good idea...

[12:11] <gbb> idea:  [c/sh]ould merge automagically take a security diff before merging, just to protect the clumsy from their foolish mistakes?  (I merged my working copy instead of my test dir in gdb, oww, repairable but ugh...)
[12:12] <stsp> gbb, you mean something like merge --dry-run?
[12:13] <stsp> with such things, it's tricky: if we do a check by default, one set of people will complain about the additional overhead, while the other group will complain about the need to specify an option to get the safe behaviour
[12:13] <gbb> hrm dry-run would have helped but not protected me from merging over all my work.  ;(  (luckily my emacs is my handbag and most of those files were still open)
[12:14] <stsp> i think it's the type of mistake that you just need to learn to avoid over time
[12:15] <stsp> if we had checkpoints implemented, you could checkpoint your working copy before a merge, to keep a record of the pre-merge state
[12:15] <stsp> i think that would be a nice solution
[12:16] <stsp> merge could automatically create such a checkpoint, in fact!
[12:16] <gbb> not sure what check points are.  but currently you can only revert to pristine, not to pre-merge
[12:16] <stsp> see http://subversion.tigris.org/issues/show_bug.cgi?id=3626
[12:17] <stsp> or shelving, even
[12:19] <gbb> that would be the ticket :)
[13:20] <ASFBot> gbg * r1540299 (subversion/branches/invoke-diff-merge-feature/ (14 files in 6 directories)) http://svn.apache.org/r1540299 : On the invoke-diff-cmd-feature branch: Checkpoint commit (ignore, trivial).
[13:32] <gbb> as Mr. Twain remarked: "A man who carries a cat by the tail learns something he can learn in no other way."
[13:32] <stsp> :)

Even left over lunches don't come free

I keep meaning to write something about the weird experience that re-learning to code can be.  I wrote the following to a friend of mine, and I think I could rewrite it, but well, it says all that needs to be explained I guess.

My svn jutsu is pitiful, because I literally had no time yet to learn it and also, no cause (as in need-it-right-now project I need to do-right-now).

See, if you know more than a beginner but less than a newbie, the question is, what part of the universe of confusion to you de-entropy first?

If you want to do A but suddenly codus interruptus hits and you first need to figure out B, which depends on knowing C that requires you check out D... E... Zzzz(repeat ad nauseum) the best decision is to patz and just get the job done without getting sidetracked into studying properly. 

The OPW placement was great, but put a lot of pressure on me to produce something semi-decent(and, I was (and am) slooooow) and so, I didn't have much time to read into things too deeply, plus, what can I say, coding is a habit and restarting after 10 years isn't all that easy -- you need to rebuild your coding short term memory space/riffs to be reliable, fluid and have enough slots, and that takes time.   

They say you never forget how to ride a bike, that's true, but when you try after a long time, you get doms in your muscles, wobble the wheels and possibly fall off at least once. 

Is it easier to re-learn than to start from scratch?  I don't think so, it's harder in quite a few ways, because you tend to be overly critical without having the matching sound judgment.  Even left over lunches don't come free :)

Reading through a manual for general understanding is very different to needing to get from A-B, and I had a lot of A-B'ing to do.  

In fact, I didn't use svn at all (other than to stash code) until I put a lot of code in the wrong tree and had to use diff to get my work out *blush* , so I managed to contribute to svn (the gtest project) using svn the first time when I made the branch where I stashed the completed job.  Plus I had commit access and no idea how to test this before I make a (potential) mess, so it had to work the first time.  Ostrich egg omlette, anyone?

I had kittens over the merge -- I let my branch rot somewhat.  So, I somehow ended up using kdiff at first and got spammed by 30 unresolved merges I had noooo idea what they were.  In my defense, making a large svn branch with lots of code snippets in many files and letting rot (I had no idea this could be a problem btw) is perhaps not the optimal introduction to basic svn usage... 

Eventually... I r.e.m.e.m.b.e.r.e.d that svn itself has a merge program and that kdiff is actually trying to do the merge instead of just showing me the code (I'm slow I know, LOL)  and it did it all bar a couple of simple line hierarchy queries.  

And, to top it all, this one segment of code that drives kdiff is actually the *one{and only}* thing I understand in svn (because I coded it, plus I tried to code a fix in for the merge label bug which died because it broke something else, and there could only be one), but did I make the connection?  Of course not, doh.   

Maybe I should've bought a dunce cap instead of a Stetson.

----  Well, this is what she wrote. ----

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!

Life Pro Tip: svn up regularly!

I was fiddling with the --internal-diff command and when testing, svn coredumped on me.   So,  I removed my recent changes leaving the original patch I'm working on in place and... it still coredumped. 

OMG,  what did I break?  And how?  Because nothing I did should have caused this...

Just for luck, I decided to compile the original version, and the bug was there all the time.  Phew, I'm innocent(just this once...)

So, I post the fix to the dev list and --- Ben already found and patched the issue 2 weeks ago.

Note to self:

 before you do anything!

New Subversion Web Site Changes Guide

I added a Web Site Changes guide aimed at assisting contributors with submitting patches for corrections and contents for the Subversion Website.

This was my first direct commit to Subversion , and of course I had to make the obligatory mistake, mercifully it was only in the log file and not in the live website, and so, I learned on the spot how to change the log files as well :)

Your left is there where your thumb on the right is

It's perfectly possible to be laboring under the illusion that what you're doing is working and, it also may seem that way.

The patch I posted compiled, but created a new directory (see mistake 1). I have no idea why it compiled, but it did and so I just assumed that will be correct.

This time, the moments when I didn't keep a log came back to bite me.

Mistake 1) getting confuzzled and switching prefixes -- I ended up with libgtest and gtestlib. One of the worked but was wrong; the other was correct, but broken.

Mistake 2) Littering. I left an exploration hack around which added an extra 'lib' to one of the macro expansion and ended up with liblibgtest being sought. Plus I forgot I had done it and had to sleuth for 10 mins.

Mistake 3) Not changing all occurences of gtest properly.

Mistake 4) not having a test for 'correct compile', and I didn't even consider what 'done' means...

How to Mess up a Patch [Pt. II]

Failures are are a valuable part of the learning process, but no-one likes to repeatedly have failures in public -- the dev mailing list is quite a public place, and being a rookie among so many good coders is quite intimidating.

So it's easy to get stage-fright here and start to feel a little bad about your performance -- it's a totally healthy reaction.

However, don't get bogged down, but always analyze how you arrived at the failure and if in doubt, listen to Zappa:

Finally, remember, your mistakes currently are simple ones.  As you get better, your mistakes will get more sophisticated, and you'll end up thinking fondly of the time when a white space or a simple procedural error was your biggest problem.  So, enjoy this happy time whilst it lasts :)

How to mess up a patch [Part I]

Strictly speaking, this should have been [Part 15] or so. I keep making mistakes, and it is not for want of checking -- my 'spidey sense' just isn't honed and there is quite a bit odd detail to be observed. Lucky for me, the Subversion team are eagle-eyed and patient!


So what went wrong in today's patch?  Let's count the ways:

1.  I didn't take a break before proofreading.
2. My original goal was to do A, then I found that doing B was superior, but then claimed I did A instead of B in the log message.    Always check your entry and exit contract.
3. I assumed something weird and didn't question it. What I should have thought instead was: how odd! and investigated.
4. I didn't consider that two Apache sites would have uniformity in architecture, concept and appearance.

All this looks perfectly obvious in hindsight, but actually, it's not so trivial.  It's not that the individual tasks are difficult, it's just that there are so many of them!