Just another lazy Sunday

Today is dedicated to reading all about svn properties, and because it's cold and I want a fire, I'm in the garden, cooking pound chicken on the grill, copying this gentleman's excellent example:

The svn dev mailing list is a lot of fun at the moment, the [RFC] Build System Documentation discussion yields a lot of surprises, some neat puzzles and many 'aha!' experiences, and I'm learning a lot :)

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 :)

♥♥ Couples who code together, stay together ♥♥

Valentines' day is a perfect occasion to snuggle up with your other half and code together.

One problem is how to do this comfortably -- computers are not really designed for two (or more) people sharing.

The solutions below of course work for friends, colleagues or people who have multiple computers around the house and want to have their workspace accessible everywhere.

How to set up a buddy programming environment

There are a number of ways to share a programming environment, but this is the most basic set-up that will work on any PC.

One Computer: 

You need a monitor that you can both see well, and two wireless keyboards.

    1) plug both the keyboard dongles into the computers.
    2) start hacking :)

Two, or more computers, everyone has their own monitor:

1) Decide which computer to run emacs on and start it:
   a) type emacs -nw
   b) type M-x server-start
   c) go out of this window, start a new terminal
   d) type emacsclient -nw --- this is your working window.

2) On the other machine:

   a) ssh into the emacs server machine on the same
      account.
   b) type emacsclient -nw --- this is your working window.

At this point, you can both type in the buffer(s) as you please and the cursor and their input will be independent of each other.

This is NOT true of the command line -- whilst you use M- C- etc, you monopolize the cursor and emacs will lock up for a moment for the other person, so you need to communicate.

Watching each other work remotely

Screen is a program which allows you control multiple shells from a single terminal window.  It is a handy tool in many ways for solo or social use.

One feature is that it allows you to show your work as if the other person is looking over your shoulder, no matter where you both are actually located.

Here is a short guide to get you started:

Person starting "screen" session:
    1) type screen
    2) type emacs -nw

Person connecting to "screen" session:
    1) ssh to the server into the account used
    2) type screen -x

You now have a session that the person on the client PC can observe and manipulate as if it was their PC. Note that this shares the cursor, unlike using emacsclient.


Like what you see?  Read the screen manual and find out more!   

Rectangles and Emacs

Being able to kill and yank rectangles in text is an incredibly handy tool -- one of those tricks you can't imagine is useful, until you learn about it, and then, your life is incomplete without it.

Say you have:

aaa  bbb ccc
aaa  bbb ccc
aaa  bbb ccc

and you want to move the 'b' block.  So you mark from the first bold b to the last bold b (this looks like you're marking the entire block, but fret not) and type: C-x r k.  This deletes the block and closes the gap.

Now you move to where you want the top left corner of the b block to go, make 3 lines of space below and type  C-x r y, to retrieve the 'b' block and the job is done.

Happy editing!

Software Debugging (CS 259)

This course is simply a must-take.  Not only does the instructor have a wicked Cheshire Cat grin, but also, he has the bestests tips and tricks:

Software Debugging (CS 259)

The videos are threaded into small chunks interlaced with small quizzes.  So it's easy to dive in and out and grab some debugging wisdom during the day, even if you're busy with something else.

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...

Build System Gtest addition, next attempt

Resistance was futile... :)

Without the excellent tip to keep a log of debug activities, that I picked up from the Udacity debugging course, I probably would have given up or would still be mud wresting this thing.  (I will blog about this course next!)

The man who teaches this most excellent course is totally correct: the moment I started keeping notes instead of jamming my short term memory full of  Vogon poetry, my brain was  freed up to do some thinking, and I was able to take a break  to snatch a few moments of real life without losing my spot.

It's amazing how much work a few lines of trivial looking code can make, and mind you, whilst it 'works' currently I had to cheat a little :)

Here is my (partial, since I forgot to keep it up at some points) log, in all it's gory:

AM_M macros do not work in autconf, try autoconf --force and that will
reset (something) and make it work once, but no more.  Removed.

configure: WARNING: unrecognized options: --enable-maintainer-mode, --enable-gtest

1 Identify how many spurious warnings are generated

2 Examine Makefile for gbg_autoconf spoor

*make optional note in configure output to inform user this error
 message is spurious* it is generated in generator/gen-py and almost
 looks like code rot, is there a bug catergory for this, should this
 be queued?

Note: build-outputs.mk still have references to gtest_LDFLAGS etc
gtest/gtest-1.la: $(gtest_DEPS)
        cd gtest && $(LINK_CXX)) $(gtest_LDFLAGS) -o gtest-1.la $(LT_NO_UNDEFINED) 

        $(gtest_OBJECTS) $(LIBS)
WHY

Considering target file `all'.
 File `all' does not exist.
 Finished prerequisites of target file `all'.
Must remake target `all'.
g++ -Igtest_hack/include -Igtest_hack -c gtest_hack/src/gtest-all.cc
Putting child 0x090799a0 (all) PID 24007 on the chain.
Live child 0x090799a0 (all) PID 24007
Reaping winning child 0x090799a0 PID 24007
ar -rv libgtest.a gtest-all.o

Currently, the build system is "improving" our link command in two
ways:

1.  it is stepping into gtest (not necessarily horrible)
2.  it is adding all the objects fromthe compilation to the command line
FIX: Remove the extra compilation targets?
DONE: Change to build.conf

idea: make gtest a "exe"
Result: no change

Removed the headers from private-includes in build.conf
        gtest/include/gtest/internal/*.h
        gtest/include/gtest/*.h

This does not affect build behaviour.  Also, it can't stay there
because gtest is optional and the script crashes when it cannot find
required headers.

Did this instead in Makefile.in: GTEST_INCLUDES = -Igtest -Igtest/include

Also added a lot of stuff into Makefile.in here is the current selection:

COMPILE_GTEST_CXX = $(COMPILE_CXX) $(GTEST_INCLUDES) -o $@ -c
LT_COMPILE = $(LIBTOOL) $(LTFLAGS) --mode=compile $(COMPILE) $(LT_CFLAGS)
LT_COMPILE_CXX = $(LIBTOOL) $(LTCXXFLAGS) --mode=compile $(COMPILE_CXX) $(LT_CFLAGS)
## I don't understand why, but I need to provide "-o ... -c" in order to get the 

  object file in the correct directory                                               
LT_COMPILE_GTEST_CXX = $(LIBTOOL) $(LTCXXFLAGS) 

  --mode=compile $(COMPILE_CXX) $(LT_FLAGS) $(GTEST_INCLUDES) -o lib$@ -c

and also

LINK_GTEST_CXX = $(LIBTOOL) $(LTCXXFLAGS) --mode=link $(CXX) $(LT_LDFLAGS) 

  $(CXXFLAGS) $(LDFLAGS) -rpath $(libdir)

(forgot to document and prompty got lost and forgot what I did...)


idea: following the thread of the remake stack trace
------ completed all in apr-util

##>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
g++ -std=c++98  -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE  -Wall -Wpointer-arith 

-Wwrite-strings -Wshadow -Wunused -Wunreachable-code -Wno-system-headers   \
-g3 -fno-omit-frame-pointer -fno-inline   -DSVN_DEBUG -DAP_DEBUG  -I./subversion/include 

-I./subversion -I/home/g/trunk/apr/include   -I/home/g/trunk/apr-util/incl\
ude -I/home/g/trunk/sqlite-amalgamation  -Igtest -Igtest/include 

-o gtest/src/gtest-all.lo -c  gtest/src/gtest-all.cc
##<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
##>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
cd gtest && /bin/bash /home/g/trunk/libtool --tag=CXX --silent --mode=link g++ 

-g3 -fno-omit-frame-pointer -fno-inline   -DSVN_DEBUG -DAP_DEBUG   -rpath /tmp/foo/\
lib  -o gtest-1.la  src/gtest-all.lo
##<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
libtool: link: `src/gtest-all.lo' is not a valid libtool object
build-outputs.mk:479: *** [gtest/gtest-1.la] Error 1

#0  gtest/gtest-1.la at /home/g/trunk/build-outputs.mk:479
#1  gtest at /home/g/trunk/build-outputs.mk:1472
#2  local-all at /home/g/trunk/Makefile:390
#3  all at /home/g/trunk/Makefile:382
Command-line invocation:

Problem:
by including "-o $@", the output is named ".lo" instead of ".o".  The reason
we added -o ... is to get the object file in the correct directory

TODO
should be building in the gtest directory
Ruby error : already at newest ruby, spurious warning?
get-deps.sh is giving an error message. Need to svn up at some point

Libtool won't link to a library not called libtool
Do we need to use libtool?
No, not necessarily, BUT the rest of SVN does and we would like to follow
their style

Ideas:
1.  Avoid libtool
Pluses: might work
minus: might be harder than libtool

2.  Hack gen-make.py
Pluses: ...
Minuses: serpents  will issue forth from the CPU

3.  Rename tree to libgtest
Pluses: Will work
Minuses: Kitten with ball of angora wool

4.  libtool is actually a svn shell script.  Is the restriction on
name inside the shell system?  Why was it put in the first place?
Hack it if it exists?

Pluses: it might just work
Minuses: it might not

5.  Get libtool compile command to add lib-prefix
Plus: right thing to do
test:
    Yes it could work, although it puts the lib in trunk
        TODO: Work out why/ask why it drops it in trunk
This involves changing the name of the targets all the way through the make
file

Plan
6: Rename target to libgtest
1.  update configure.ac, build.conf

removed getst from aclocl.m4 in orig trunk as a test...
test if svn still compiles w/o gtest.m4 .. yes it does, removed.

PLAN: patch & ship

patched copy, didn't work, failed with:

/bin/bash /home/g/projects/svn/trunk/libtool --tag=CXX --silent --mode=compile g++ -

std=c++98  -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE   -g -O2  -I./subve\
rsion/include -I./subversion -I/home/g/projects/svn/trunk/apr/include 

-I/home/g/projects/svn/trunk/apr-util/include 

-I/home/g/projects/svn/trunk/sqlite-amalgamat\
ion   -Igtest -Igtest/include -o libgtest/src/gtest-all.lo -c  gtest/src/gtest-all.cc

cd gtest && /bin/bash /home/g/projects/svn/trunk/libtool --tag=CXX --silent 

--mode=link g++  -g -O2   -rpath /dev/null/lib  -o libgtest-1.la  src/gtest-all.lo
libtool: link: `src/gtest-all.lo' is not a valid libtool object
make: *** [gtest/libgtest-1.la] Error 1
g@musashi:~/projects/svn/trunk$ cd -

patch copy of faulty compile is the same as output of working one.

changed get_dep.sh to move unzipped gtest into libgtest instead

Added in dep-get.sh: warnings about the spurious warning about the
headers in autogen.sh and the repeated spurous warnings in ./configure
--enable-gtest,

*IT COMPILES* :)

cd libgtest && /bin/bash /home/g/projects/svn/trunk/libtool 

 --tag=CXX --silent --mode=link g++  -g -O2 

 -rpath /dev/null/lib  -o libgtest-1.la

compile svn with gtest present but without flags test:
make clean
./configure --enable-maintaner-mode --prefix=/dev/null
make
PASS

compile svn without gtest present and without flags test:
make clean
./configure --enable-maintaner-mode --prefix=/dev/null
make
PASS

compile svn without gtest present and with flag test:
make clean
./configure --enable-maintaner-mode --prefix=/dev/null
make
PASS

roll patch, log & ship it.

Rain really makes everything better

...including my flimsy, easily disturbed concentration.

Amazingly, this canned thunderstorm works a treat to regain concentration quickly after phone, doorbell and cats disturb my coding peace...

...oh look..

LOTS of butterflies!!!