More info at
https://www.aeolusproject.org/
https://www.aeolusproject.org/audrey.html

This morning when it came on I suggested to my carpool buddy that I wished a built in feature of cars was to tell me why the light came on. Seems ridiculous to make me take it to someone to tell me what’s wrong with my car. Imagine if we had to take our computers to someone any time there was an error message in /var/log/messages. What a pain.

Ha! Take that car analogies of computers! I just made a computer analogy of cars!

I know you can buy those readers that will tell you the error codes. Although, my car is a VW that takes a non-standard reader and is more expensive than the common ones. Ah, German engineering.

(For my non-linux cohorts, /var/log/messages is the system log in linux)

Enter coverage.py: http://nedbatchelder.com/code/coverage/

I’m on fedora so $ yum install python-coverage installed it for me.
To get the details suggested above you need only run two commands.

~/git/audrey git:(oauth*)➤ coverage run audrey_start/test_audrey_startup.py
……………
Ran 15 tests in 2.601s

OK

The coverage run command executes your code just as if you had executed it without coverage.py, but has generated data about the code it’s executing as it’s running. You can see here I’ve executed this code’s unit test script. Next you display the report data:

~/git/audrey git:(oauth*)➤ coverage report audrey_start/*.py
Name                               Stmts   Miss  Cover
——————————————————
audrey_start/audrey_startup          472    270    43%
audrey_start/test_audrey_startup     217     19    91%
——————————————————
TOTAL                                689    289    58%

~/git/audrey git:(oauth*)➤ coverage report -m audrey_start/*.py
Name                               Stmts   Miss  Cover   Missing
—————————————————————-
audrey_start/audrey_startup          472    270    43%   126-132, 186-216, 237, 241-243, 247, 288, 352, 379, 382, 388, 414, 456, 544, 558-559, 585-601, 609, 630, 640, 654-689, 700-730, 739, 747, 774-794, 837-847, 854-857, 907-936, 955-957, 975-1125, 1139, 1151, 1190-1195, 1203-1229, 1264-1340, 1344
audrey_start/test_audrey_startup     217     19    91%   65, 130, 384, 420-428, 505-526
—————————————————————-
TOTAL                                689    289    58%

The coverage report command will give you the percentages missing for each script. The coverage report -m command will give you the exact lines missing from the unit test coverage. I checked a few of these lines that it reported, a quick check seems to indicate these are all actual lines of code that were not executed during the unit test run. Pretty useful data for measuring the effectiveness of your unit tests.

Just a fun fact to share.

… the statement “God is Love” means that his love find expressions in everything that he says and does.

The knowledge that this is so for us personally is the supreme comfort for Christians. As believers, we find in the cross of Christ assurance that we, as individuals, are beloved of God; “the Son of God…loved me and gave himself for me” (Gal 2:20). Knowing this, we are able to apply to ourselves the promise that all things work together for good to them that love God and are called according to his purpose (Rom 8:28). Not just some things, note, but all things! Every single thing that happens to us expresses God’s love for us.

Thus, so far as we are concerned, God is love to us – holy, omnipotent love – at every moment and in every event of every day’s life. Even when we cannot see the why and the wherefore of God’s dealings, we know that there is love in and behind them, and so we can rejoice always, even when, humanly speaking, things are going wrong. We know that the true story of our life, when known, will prove to be , as the hymn says, “mercy from first to last” – and we are content.

- J.I. Packer, Knowing God, Pages 122-123

This passage has blessed me as I’ve reflected on the things around me that go “humanly wrong”. Both in my and my family’s life and the life of the people around me. More often than not we do not specifically know, and may never truly know, why a particular event happened in someone’s life. Though, whether we’re glad or scared or frustrated or upset or don’t even care that some whatever has happened, we do know that it happened because our God loves us and is bringing himself glory through his creation.

I killed one today with a kayak paddle. It was a small water snake, don’t think it was venomous. It jumped about 3 feet at my wife and son the other day as they were pulling the kayak out of the water, it struck the boat. Luckily they were at the other end of the boat from where it tried to strike. I came across it today sunning itself on a rock and sliced off it’s head. My four year old son told me I had to kill it because snakes are bad.

Other one may have been a cottonmouth but we couldn’t be certain. It gave me a chance to kill it earlier this week but I wasn’t in snake killin’ mode yet.

Next time we’re at the lake the snakes that dare to show themselves won’t stand a chance. I’ll be ready for ‘em. I talk a big game, but really I almost decided to let the one today go. My son talked me back into it. Thanks bud, our dock is a safer place because of you.

Tonight I came to some conclusions about some of the initial trouble I was having and got adb working properly with Fedora 14. There’s not a whole lot of info about getting adb on Fedora working with the nook so I’ll provide my config files.

I started with a fresh image tonight and worked through the setup I had already done. Here are my conclusions from this experience.
1. Initial performance issues seem related to the dalvik-cache. Once that’s been generated things run much smoother.
In an attempt to get the overclocked kernel working before I started again from scratch I did the rm * on the dalvik-cache referenced in the link from my last post.
This made the nook run very slow again. Then when I booted the fresh image I again got the same horrible performance. In particular the initial boot took a long time. Once booted I would select the “wait” option at “force quit or wait” prompts. These slowly thinned out in frequency. Once I stopped seeing them all together things seemed to run pretty smooth and responsive.
2. the overclocked kernel bombs after I setup my wireless.
While starting from scratch I rebooted the overclocked kernel a couple times. No problems getting the nook booted on it until I setup my wireless.
3. The wireless needs work.
I cat get the nook connected to my router (Apple Airport Extreme), but the speed is slow. I also noticed that when I was trying to initially connect that my AP would jump in and out of the available connections.

adb
There were lots of posts that talked about adding a file in the /etc/udev/rules.d directory. I also needed a file in the ~/.android directory. Here’s my final two config files:

dradez@tirreno:~➤ cat /etc/udev/rules.d/51-android.rules
SUBSYSTEMS==”usb”, ATTRS{idVendor}==”18d1″, MODE=”0666″, OWNER=”dradez”
SUBSYSTEMS==”usb”, ATTRS{idVendor}==”2080″, MODE=”0666″, OWNER=”dradez”

dradez@tirreno:~➤ cat .android/adb_usb.ini
0×2080

after I had those in place and udev bounced adb showed up in the adb devices command and I was able to use all the sdk tools as the docs suggest.

I look forward to the wireless getting more stable. I love the interface and look forward to installing some more apps to work with. Hopefully I can figure out how to contribute to making things better.