Cold Electrons

As part of my recent gearing up for working on our super secret game project, I’ve been decking out my Vim installation with useful scripts.

During part of this process, I found that the OmniCPPComplete script is almost completely unusable when working with the Boost libraries and STL. OCC uses exuberant-ctags to gather information, but the tag files it generates are…rather large (in the case of Boost), and doing autocompletion with STL requires a set of specially modified headers.

While both those problems are not exactly unsurmountable, the main problem I had with OCC is that it is very stupid. Using it with the libraries I wanted to use produce a lot of tag pollution – autocompletion on anything produced an extremely long list of stuff that was nothing near what I wanted. Also, it was completely static: I didn’t get completion on instances, or even of tags in my current file.

So, I discarded OmniCppComplete, and embarked on a quest to use Clang_Complete.

Clang_Complete is an interesting project. Some professional IDEs use the actual compiler to generate the Abstract Syntax Tree of the code – actual living, breathing information about the code as you type it. However, due to some paranoia in the world of the Gnu, gcc does not export it’s AST. Thus, clang_complete uses…clang! Clang is a compiler based on the LLVM.

Luckily for me, even as I was working on this, Debian brought up-to-date packages of LLVM and Clang to my doorstep

However…

As I am working on a multithreaded project, and I’m endevouring to use as modern and as cross-platform code as possible, I hit a stumbling block when trying to use std::atomic:
error: Non-inline namespace cannot be reopened as inline

Clang doesn’t like the nested-namespaces technique used the gnu standard libc++ to version and control what ABI gets inlined. I wrested around for a while, trying to coax clang into getting past this. Nothing was working, so I started looking at it like a platform problem. One platform being actual compiling, the other being clang_complete.

Since my goal was NOT to compile with clang, but only to make autocompletion work nicely for me – and since this so far seems to be only in the files where I want to use atomic operations, I start putting this in the tops of those files:

 // headers like you'd normally expect 
#include <iostream>
// Now for the conditional stuff
#ifdef __clang__ 
#include <clang_complete_compat/atomic.h> 
using namespace std::atomic; 
#else
#include <atomic> 
#endif

Then, I took the regular <atomic>, and started butchering it into something to forward declare what I wanted. I know I could do better, because I’ve missed some detail that entails using the extra “using namespace”. However, for the moment, it works.

…masturbatory.

Occasionally, we linux users are bitten by the bug.  Usually, it is when we are in larval stage, and the better of us gain wisdom and avoid it later in life.  Others (such as myself) are locked in a chaotic attractor, spiraling in a love/hate orbit about this amazing system that fascinates us.

The bug-bite I’m referring to is the obsessive upgrading/updating of one’s computer system.

“Dang, my hardware is not supported right now.”

“Ah, there’s support in the latest kernel.”

“Dang, that broke this other software I use. Let’s see if there’s a fix…”

“Ah, bugger…”

Ah, that ‘ah, bugger’ stage of things, where your system teeters on the knife edge of developement. It’s heady stuff, building up your system.

I sometimes do things that are risky.

As an electrician, I’ll sometimes work on things while energized. As a driver, sometimes I’ll go over the speed limit. As a computer user, I’ll sometimes browse *coughporncough* while on a wifi hotspot.

As a debian user, I’ve tried putting my root filesystem on LVM/RAID.

As with all things, the risk is calculated, and there are certain conditions under which I would never do them – for instance, I only speed during fair weather, and never speed in adverse weather conditions.

However, risk, no matter how small, is still a chance for things to go wrong.

So, my root filesystem just…went away.

At some point in the past couple weeks, during the upgrading of my desktop, the configuration for my RAID and LVM simply evaporated. I still not even 100% certain that this is the cause, as it was a power brown-out and my UPS shutting down that brought this to a head.

Upon reboot, my kernel and initrd (in /boot) knew nothing about my configuration. I reassembled the raid with mdadm. Most worrisome, the RAID10 array took several hours to resync.

Perhaps it was my fumbling about in the boot shell that caused the data loss, but after the resync, my Volume Group and Logical Volume information was gone.

After a crash (haha) course in lvm/raid/etc, I’ve come up with a little script, that will hopefully get me back my /home directory, with the terabyte of music and ebooks that reside there. I’ve tried it out in a virtual machine where I manually broke an LVM configuration, and it found the filesystem again.

I’ve made a small test sample:

What you see in the picture is a small layout I made.  The left side, I started with a 1mil trace, and increased the size by 1mil as I went down.  The right was an isolation test, with the bottom isolation starting at 10mil, and decreasing as it went up.  I exported the gerber from PCB, and then imported it into a project in GCAM.  Using and initial offset of 0.003″, stepover of 0.004″, feedrate 6ipm.  The board was held down on an aluminum plate – I applied double-sided scotch tape first to the aluminum, and then to the board, smoothed out air bubbles, and then put the board down on the plate.  After I pried the board off, I stoned off the little bit of copper burr with a stone, and washed it as I was doing so with acetone.  I then scanned the board at 600dpi for this post.

Actual dimensions?  Due to variation in my setting the Z height, the 1mil trace turned out to be about 2~2.5mils.  Because variation will occur in every setup, I need to plan on a minimum size that will suffice at the maximum variation.

The 1mil trace didn’t hold up, but 5mils looks possible.  However, the isolation routing was cut off at about 6mils by GCAM’s algorithm.  With 10/10, SOICS and other SMT are possible.  BGAs might be possible, but I’m currently limited by the smallest drill size (24mil) I have.

Of the three available pieces of software available for isolation routing – Eagle’s pcb_gcode.ulp, pcb2gcode, and GCAM – GCAM impresses me the most.  It’s an actual geometric offsetting algorithm, not a raster-conversion-pixel-offset hack.  It is a bit buggy yet – It sometimes produces spurious arcs and lines with bad gcode syntax.  However, it is fairly easy for me to edit those out.  I’m already looking into the code.

My cutters I purchased from Drewtronics, and I’m using a new spindle I purchased from CNConaBudget.