Over Macho Grande

Fedora's 'mock' tool provides a much more convenient way to build RPMs than using 'rpmbuild'.  It creates a chroot environment for your target OS and will install required dependencies. I've been running into limitations on the version of CollectD that ships with Amazon Linux, so I thought it wouldn't be that difficult to use mock to build an updated version complete with some missing plugins.  I knew that it generally worked, as I was able to use the specfile from the project to build for EPEL6 using Fedora 26.  Man, was I wrong about how easy it would be for Amazon Linux. I won't go into details here, but it's worth mentioning that the CollectD project documentation calls out that the specfile in their contrib directory is generally out of date.  That is 100% correct, so you'll need to budget some time for tweaking it. The first issue is that there are some packages in EPEL that can't be installed in Amazon Linux.  The most aggravatin...

AWS Lambda and I have a love/hate relationship.  There is much about Lambda to like, but there are also some very sharp edges operationally. One of the cool things is that you get a new CloudWatch Log Group for every new Lambda function without any effort on your part.  Less cool is that it has unlimited retention.  If you haven't yet followed Yan Cui's advice , then you can use some Bash/CLI magic to fix retention on your existing Log Groups. First, get a list of all your default Lambda log groups:  aws logs describe-log-groups --log-group-name-prefix "/aws/lambda" | grep logGroupName | cut -d : -f 2 | cut -d \" -f 2 > /tmp/lambda_logs Read that into a Bash array:  readarray -t log_groups < /tmp/lambda_logs Then, add a 7 day retention policy to all those log groups:  for i in "${log_groups[@]}"; do aws logs put-retention-policy --log-group-name $i --retention-in-days 7; done It's a hack, but if you're going to put in th...

First of, let me start by acknowledging that you're no longer supposed to use NuGet restore (with the .nuget) as of NuGet 2.7.  Then again, to quote Mick Jagger, you can't always get what you want. The biggest problem I have with this is the "HintPath" in the project file.  It took some experimentation (and a couple of wrong turns) to work out that HintPath is relative to the project directory even when it's part of a multi-project solution . You'll know that your HintPath is wrong when the NuGet package is installed but can't be found by the compiler.  Drop into the directory containing your project and confirm that you've got a valid HintPath.  One of my wrong turns was not verifying that I had a correct path (there was an extra 'lib' in the definition. You may also see this as a busted reference in Visual Studio.

I'm in the "winding down" phase of my time here in Noumea.  One of my cornerstone achievements is migrating a buggy MS Access app into a shiny new MVC3 (and then MVC4) web application. I've been working on it off and on for most of my time here (maybe 18 months) and one of my co-workers asked me to document some of the design decisions.  The app kind of grew organically, so I don't have a software spec to point to like I would have had at my prior engagements.  I felt a series of blog posts would be an appropriate way of documenting this.  It's an open source app, so the blog posts are my defense when someone digs into the app and finds some awful hack that migrated from a short-term fix to a permanent solution. I've got nothing more today, but next time I'll dig into the choice of data access layer. TUBS on GitHub

Okay, so this is something of a rant, but given my experiences with the laptop, how can I not? Backstory:  Corporate IT maintains a list of acceptable portables, all of which are made by Toshiba.  After looking over the list, it looked like the best choice was the Portege R830.  It had the best possible CPU and it wasn't a giant clunker that looked my back-in-the-day 15 pound Inspiron 7000.  As a bonus, it was available with a reasonably priced docking station. My first conception that something was wrong when, after first boot, I checked free memory.  Physically, 4GB is installed, but windows says that only 2.7GB is available.  The Intel HD3000 video setup is eating the rest (1.3GB!).  Okay, no big deal.  I can reboot and change that in the BIOS.  Oops.  No option.  Well, maybe it's just some old drivers.  Nope.  Drivers are latest from Toshiba.  They're not particularly new, so maybe the generic Intel ones will ...

I _really_ like Twitter's Bootstrap.  It saves me from making any number of questionable content design choices.  I'm using it in an MVC3 project and one of the things that bugged me was the inability to get Microsoft's unobtrusive validation working with the fancy form control states in Bootstrap. Well, after looking around on StackOverflow and poking and prodding MVC, here's what I've got: If you correct the error, the state changes away from error and you get this: I hacked this into place by inserting a shim error placement function.  It saves a handle to the original Microsoft implementation, changes the class on the nearest div with a CSS class of "control-group" and then calls the Microsoft implementation to display the actual error text. $(document).ready(function () {             var esettings = $.data($('form')[0], 'validator').settings;           ...

I'm pretty impressed with Microsoft's System.Speech API.  It took less than 3 days to throw together a proof-of-concept application.  The hardest part was probably coming up with the grammar -- documentation for that is pretty thin on the ground. Anyways, here's the application source code on GitHub if anyone wants a look: ObserverLengthSampler project If nothing else, I'd recommend it as a starting point for someone needing a number recognition SRGS grammar in an XML format.

I just got a short side project @ work:  Use speech recognition to capture fish species and length from tuna observer samples.  I'm going to try the win7 version first but I'll probably wind up giving sphinx a try too.

I've been running GingerStreak of late and I'm not best pleased with the results. So I thought I'd try my hand at building Gingerbread for the Streak. Dell has helped out by actually releasing a working kernel. Just so I remember, here's how I put myself onto the latest released msm8660 build (gingerbread_house @ CodeAurora):   repo forall -c git checkout M8660AAABQNLZA3620   Initially I just moved the original externals to a .aosp directory (e.g. bluetooth -> bluetooth.aosp) so that I could diff them, but the default build process still wants to build 'em. Looks like I'll have to move it outside the tree.

As much as I've dogged on Python in the past (significant whitespace, really?), I've got to admit that it's got some cool features too. For example, I'm playing with libpuzzle  (a library for visually comparing images).  It has a command line utility and a C and PHP API.  Unfortunately, the CLI utility doesn't allow one to dump the raw comparison vector, and it's a PITA to write C just to play with a library. Python's native "ctypes" to the rescue! from ctypes import * class PuzzleCvec(Structure): _fields_ = [("sizeof_vec", c_size_t), ("vec", c_char_p)] class PuzzleCompressedCvec(Structure): _fields_ = [("sizeof_compressed_vec", c_size_t), ("vec", c_char_p)] class PuzzleContext(Structure): _fields_ = [("puzzle_max_width", c_uint), ("puzzle_max_height", c_uint), ("puzzle_lambdas", c_uint), ...

Not wanting to hassle with learning OpenCV and fighting with an edit-compile-execute environment, I decided to use my OpenCV project as an excuse to play around with Python. I'm still a serious beginner, but I'm beginning to understand why it gets the use it does. Anyhow, it only took a couple of days to integrate Tesseract OCR, PIL, and OpenCV such that I could open multi-frame TIFF images, perform some basic feature detection, and then use the output of feature detection to focus on a specific region for OCR. I will admit to having a few false starts.  The first was that I used an older (C++) tutorial that was using some deprecated features of OpenCV and ignoring some other features.  For example, the tutorial was using Hough Line detection to find squares on a printed page.  In order to get to that point there was thresholding, dilating, eroding, inversion, flood filling and so on.  Even then I wasn't getting the correct results. When I started over, I was...

Since the Android git repository is offline, I'm having to find something else to occupy my time. I've always wanted to learn more about OpenCV, so I'm working on a new project using that.  At work we have piles and piles of paper forms that have been filled out by hand.  I've already done some trial and error work and determined that both OpenCV and PIL can clean up the scanned copies enough that I can do OCR on the printed portion of the forms using Tesseract OCR.  This doesn't get any of the dynamic data, but it does allow me to identify what type of form it is. Running OCR on an entire document takes some time, so it would be better to grab smaller regions of interest and only OCR them.  Some of the interesting challenges are that some forms are portrait while others are landscape.  I'd also like to handle the case where a form was fed into the scanner upside down.

I've finally gotten a working build.  It turns out what I really needed was to get up @ 0630, take a shower, and just plug away. Anyhow, the source is up on github:   https://github.com/coredog64 I still need to get it to build an image for the Streak before I can actually test it.

On St. Patrick's Day, Dell released an early alpha version of a Streak gingerbread kernel.  They're working from a CodeAurora drop from last year and they're using Broadcom provided brcm4325 drivers instead of the brcm4329 drivers that support both chipsets. So, I merged the Dell alpha into the current CodeAurora tree and have something that almost builds. The last piece fell into place today when I found a streak device tree for froyo.  There have been some breaking changes in the build files between froyo and gingerbread, so I need to touch all the make files to get any further. Still, I might actually have my own gingerbread ROM right around the time Google drops Honeycomb and Dell releases their own version of gingerbread...

All the Dell files compile correctly.  All I have to do now is work out the config changes so that the correct object files are built and linked into the final kernel.

It turns out the reason it wasn't building the object files into the built-in was that I had neglected to copy the source files for them into the CodeAurora tree. I finished merging the Dell and CodeAurora board files into an appropriate version for the Streak.  It still doesn't finish building, but I'm much closer.

Mostly roadblocks tonight, although I did learn how to remove the "-Werror" flag from the set of flags used to compile a specific object. As of right now, I'm not understanding why my driver object files aren't being pulled into the built-in driver object file.  I suspect I'm going to have to dig deeper into the top level makefile.

Discovered that the "toucan" config is distinct from the "austin" config and so can dump a bunch of drivers. Unfortunately it looks like I have to merge the Dell board config (board-qsd8x50_austin.c) with the latest generic board config from CodeAurora (board-qsd8x50.c). Here's where I'm at so far: corey@patches:~/msm$ git status # On branch gingerbread_rel # Changed but not updated: # (use "git add ..." to update what will be committed) # (use "git checkout -- ..." to discard changes in working directory) # # modified: arch/arm/mach-msm/Kconfig # modified: arch/arm/mach-msm/Makefile # modified: arch/arm/mach-msm/include/mach/board.h # modified: arch/arm/mach-msm/include/mach/camera.h # modified: drivers/input/keyboard/Kconfig # modified: drivers/input/keyboard/Makefile # modified: drivers/input/misc/Makefile # modified: drivers/input/touchscreen/Kconfig # modified: drivers/input/touchscreen/Makefile # modifie...

I spent tonight working on a super secret project.  Hopefully I'll be able to say more in a few weeks.

I diff'd the Dell source release against 2.6.35 from CodeAurora.  A lot of the changes were noise -- Intel wireless driver headers that got renamed, or Zaurus support that's gone away. What I'm left with is stuff in the following directories: /drivers/i2c/chips /drivers/input/keyboard /drivers/input/misc /drivers/input/touchscreen /drivers/leds /drivers/media/video /drivers/media/video/msm /drivers/misc /drivers/misc/reset /drivers/mmc/host /drivers/mtd/devices /drivers/net/msm_rmnet_* /drivers/power/qsd_batter.* /drivers/staging/android /drivers/video/msm_austin /drivers/video/msm /drivers/video/msm_toucan /drivers/watchdog Another help is that someone else posted a mention that the Streak's codename was "Austin", so a grep through the Dell source tree turned up a bunch of files that have Streak specific changes.