My Shapeoko kit arrived from Inventables while I was away at SC.
I’ve been trying to build myself a small CNC milling machine since 2009, and contemplating it for longer than that. It became clear that my original design, however educational, was a dead end sometime last year. I’d been idly watching the Shapeoko project for some time as it had similar aspirations to my design, and a couple months ago I was in a particularly mechanical mood when I saw that a batch had reached enough buyers to be produced, so I bought in for a mechanical kit to mount my existing electronics on.
The Shapeoko community is really excellent, and the kit was designed to be flexible, so I’m starting off with some suggested modifications – I’m using NEMA23 motors instead of the usual NEMA17 on the X and Y axis, because I already had some nice Lin Engineering 130 oz-in NEMA23 motors and the frame can fit them. I’m configuring for dual Y motors, which give more even force across the Y axis, and routing my belts on the outside of the frame, since I needed to buy different hardware for the NEMA23 motors anyway and this particular modification is widely recommended.
There is a gallery to document my first round of assembly below the fold (captions don’t display properly in the RSS feed).
I will be at SC12 November 10-16, with the Aggregate.org/University of Kentucky exhibit in booth 631.
I will be posting pictures and impressions through at least one of my online presence mechanisms . I fully expect it to be weird this year with a bunch of the national labs pulled out due to travel restrictions, but it should be interesting.
I picked up one of the $150 refurbished 32GB Touchpads in the last firesale on Sunday. It seems like HP has done their very best to get as many Touchpads into the hands of hackers as possible, so whether or not it is well supported by HP, the community will do something fun with it. Besides, a $150 ARM developement platform that will boot Android, various Linux chroots, AND let me play with WebOS was too appealing to pass up.
I learned some really interesting things at SC this year, and now that I’ve had a day to process, I want to share. Many of these observations come from first or second hand conversations, or justifiable interpretations of press releases, so I don’t promise they are correct, but they are plausible, explanatory, and interesting. I apologize for the 1,000 word wall of text, but there is a lot of good stuff.
I think that covers most of the really good stuff coming off the floor this year, although I am still processing and may come up with some other insights when I’ve had more sleep and discussion.
Also, Pictures! WOO! (Still sorting and uploading the last batch at time of posting).
Headed out to SC11 in Seattle, WA. for the week. Technical interest, travel complaints, booth hacks, advertising mockery, and schwag to follow.
I’ve been playing with Google+ for the last couple days, and am finding it pretty interesting. To share some observations that will be tedious to anyone not interested in plus, UI design, and such geekery:
Google is trying again with social networking with Google Plus. It actually looks pretty interesting; the group management (“cirlces”) looks reasonable, the platform-independent n-party text/voice/video chat (“hangouts”) looks spectacular, and the interest grouping (“sparks”) would make a good standalone feature. I’m going to wait and see before I deal with it, but the “Google already knows all there is to know about me” reality gives it a leg up on the competition, and if they rigged it together with standard technology (they way Google talk is a good Jabber/XMPP implementation with some extensions turned on) I might at least peer some of my “on the real god damn internet” identity into it like I do with Buzz.
A little belated because I didn’t get to plugging my camera in to a computer until today, but congratulations are in order for my housemates Tom and Cristina, who got married last Saturday in an incredibly well suited lighthearted ceremony. Best of luck guys!
I’ve spent the last several months discovering ways in which LLVM is excessive, ill-behaved, oversold, broken or simply lying in it’s documentation while working on my master’s project. In fact, that is almost ALL of what I accomplished in the past several months, and it was griding on me psychologically. Last weekend, I finally admitted to myself that, for a mixture of psychological and technological reasons, I wasn’t going to be able to finish the project using LLVM. I’ve always had a bail-out path set up to do a simpler full-custom compiler if something proved intractable, and Monday I talked to the advisor about putting that plan into action.
I’m now building a simple C-like language with PCCTS (old school 1.33MR33 emits-pure-C ANTLR and SOURCERER PCCTS, not modern ANTLR), hand-coding C for the remainder, and concentrating on the technically interesting matters. To that end, I’ve accomplished more conceptual work in the last week than the two preceding months, started laying out my new tools, and feel much better. The best “aha” moment I’ve had in months came when I sat down and worked out how the stack and calling conventions were going to work in my new system; LARs are beautiful and well-suited to real world problems in a whole host of ways I didn’t understand before.
Note that I don’t think LLVM is entirely bad; in conception, having a nice cleanly-interfaced compiler infrastructure with a library of frontends, backends, optimizer passes and other common components which snap together via clean interfaces, high level specifications, and a standardized intermediate representation is exactly how compiler tools should be structured. The problem is that LLVM has been drastically oversold, and overcomplicated. Every neat-looking interface has a mess of poorly-documented C++ that needs to be written to support it. Everything is set up with an emphasis on LLVM’s JIT/VM features, making it unnecessarily clumsy to use to produce pure compilers, or interface with external tools. Worst of all, the documentation is deceiving — much worse than incomplete, it appears complete, but is frequently deceptive or wrong. To pick one of the more egregious examples, much of the document points to the MIPS fronted as an example. This should be a good thing – MIPS is a simple design familiar to almost anyone in computing, but the MIPS backend is broken, in apparently fairly fundamental ways. The register descriptions are buggy in ways which cause it to generate incorrect code for any input containing floats, and it appears to be a high-level design problem descended from naively trusting that the register description and allocation mechanisms work as described. It is probably already a good tool for writing production compilers for established designs, but it really isn’t suited to writing research compilers.