Monday, October 26, 2009

Updates to the Antipasto Arduino IDE: Frickin's, Fixes, and Features

Matt mentioned a few of the issues with Apple and Java, so I thought it might be helpful to add a little technical detail on what's happening and why. The fixes are all part of the latest Antipasto Arduino IDE I uploaded last night, which can be downloaded here.

And given the situation, I chose to express myself through a series of F-words: Frickin's, Fixes, and Features.

Frickin's 1: Apple Breaks Java

Here's the bad news from Apple that was posted to a mailing list regarding Jan's broken Java app:
On Jun 16, 2009, at 7:23 AM, Jan Andersson wrote:

After the latest upgrade starting several of my Java-based applications fails
(when I have changed the plist to say 1.6+). This includes IntelliJ, Install4J
and DbVisualizer.

This is part of a change to the double-clickable app launching policy (which we explained in detail in the developer preview release notes). To enabled the Finder's "Run in 32-bit mode" checkbox for Java apps, and to make the transition to 64-bit by default easier, we've modified the JavaApplicationLauncher.framework to only launch application's in the architectures they have present in their JavaApplicationStub.

The thinking is that if you haven't rebundled, you likely haven't ever considered that you'd be run in 64-bit mode (and when users have dragged Java SE 6 to the top of their Java Preferences, they found that some of their applications stopped working). By preventing apps from being launched in 64-bit if they haven't rebundled, we can maintain the widest compatibility, with a minor impact on developers (and actually let them have a say in what their version and architecture requirements are).

Hope this explains what you are seeing,
Mike Swingler
Java Runtime Engineer
Apple Inc.

Apple Translation:
We don't care if we break all the Java applications out there...that's your problem, not ours.

So in response to this, Matt and I (and a few others - thanks esp. to Nick!) worked really hard to re-bundle the Arduino IDE as a 64-bit bit native. You're probably asking, why not just check the box in the Get Info window to run in 32-bit mode? Well, that was my first thought too, but the check box mysteriously disappeared, so that wasn't an option any more. Dang.

In any case, that means we needed to ensure everything is 64-bit compatible, including all the contributed libraries the IDE heavily depends on. Especially the infamous librxtxSerial library that provides serial connectivity to the boards. So when everything came together, I recompiled everything for 64-bit.

Fixes: Now the Arduino IDE runs on Mac OS X with Java 1.6+, as a 64-bit native application.

Frickin's 2: Apple PackageMaker Relocation Bugs

Aside from the Java issue, have you ever installed an application on your system and the .app file mysteriously disappears? If you have, like me, you've probably been the victim of a bug with Apple's PackageMaker utility that comes standard in OS X.

As it turns out, when building an installer package inside of a relative directory, like the Arduino IDE needs to, PackageMaker thinks I'm trying to relocate the installed Application on the target computer to a random directory. Installation result due to this bug: A full Arduino IDE installation with a missing file. Not a pleasant surprise.

The fix is more of a hack, and it's to scan for and manually strip out any XML in the packager maker build files that point to obscure package relocation settings.

Fixes: Now the Arduino IDE should always have an file in the Applications/Arduino directory.

Features: TouchShield Core Consolidation

A positive outcome of the getting back into IDE development was updates to the TouchShield core. The biggest thing is that the Stealth and Slide libraries have now been consolidated into a single core. This allows for easier code maintenance and allows for contributed libraries to run on both boards. As it turns out, this is the only thing I can indirectly thank Apple for breaking Java for.

Features: Reference Panel Added

I like to be able to browse reference docs, even when I don't have an internet connection. To see it, click Help Menu->Reference.

Features: Libraries and Reference Docs are now Core-Specific

Thanks to Andrew for suggesting this one. He was creating graphics libraries for Slide, which don't run on the Arduino. With this update, core-specific libraries like those can be dropped into to the following directory: hardware/cores/*/src/components/library

Each core also has its own reference html docs. These show up in the right-hand reference panel (see above). The reference html docs for each core exist in the following directory: hardware/cores/*/reference

Features: Compile and Upload is Now Non-blocking

Greg asked about making edits to my sketches while uploading or compiling, so now the IDE allows that to happen.

This is just a start, and hopefully it tackles a few of the issues that I've been getting emails about. I've put the IDE up here. Feel free to give it a spin and let me know if there's anything else I should take care of, or if you've got a chunk of code to include as well.

A very bad week for Open Source Hardware

This has been a very bad week for Open Source Hardware. First Sparkfun gets served up by Sun for sounding like SPARC processors. Guess what? No one in the WORLD would ever have made that connection. NO ONE except a set of trigger-happy lawyers whose sole goal is to increase the percentage of GDP in the US dedicated to legal transaction costs. Then, the Creative Commons tells GOSH to buzz off because they don’t want to help make an Open Source Hardware-specific license, instead they basically said, “hey guys, go learn about patents.” And now, Apple’s 64 bit update java dev team conveniently decided it was time to refactor the library base for 64 bit, leaving anyone who had coded an app for 32 bit hanging in the dark.

Basically, Apple just announced to any Open Source 32 bit coder like me and Chris: “Get lost!”

I have just spent 35 hours that I will never get back. Chris and I have been killing ourselves trying to understand what Apple has done to their installation of Java, and why it suddenly broke Antipasto Arduino IDE.

Apple is migrating to 64 bit hardware, and they don’t want to look back. I guess I don’t blame them. Apparently, that means anyone with a 32 bit application out there that relies on hardware API service calls, you’re left hanging. I guess Apple learned from their transition from 68k to PowerPC that backwards compatibility really doesn’t mean anything, because community developer’s time is free and cheap and no one cares about the community. I’m one of those community developers, and apparently Apple doesn’t care about my time… they’re ok to just say, “whatever, your fault, just recode your entire application for 64 bit Java if you want anyone to care.”

I guess it’s easier to tell the community “go build an app for that and get out of my face.”

Well, to whomever is responsible for making this decision, I HATE YOU.

Here’s what happened so far:

-Apple decides at some point that 64 bit java support is all they need

-Apple released version 1.6.0_15 of Java, switching everything around for 64 bit, rather than 32 bits

-Antipasto Arduino IDE’s use serial libraries and serial drivers to control the FTDI comm. link, which is more stable in 32 bit land

-Apple doesn’t care, so they rearranged the lib tree structure and object files, and decided they’d let us developers figure it out for ourselves. A couple other people have noticed

-On October 21st, madaerodog was the first to notice it was broken, and twittered all about it

-Chris and I started reverse engineering the problem once we figured out what java version he and I were running and why it worked on one and not the other

-Chris and I (and Nick) just pulled a 35 hour coding and debugging marathon trying to recompile all of the serial dependencies for the 64 bit java 1.6.0_15

Hey Apple! Next time you decide to refactor your platform-specific installation of Java in an effort to not support backwards compatibility, here’s a tip:


This is not going to be an overnight fix… but Chris posted up the most recent update to the Antipasto Arduino IDE. If you want to help, and you have a Mac, maybe you can try this version out, and let me know if it works - inthebitz at gmail…

Tuesday, October 20, 2009

What would Richard Stallman do?

It’s been a while since I talked about open source theory, but it comes up now and again because it’s pretty much a part of everything I’ve been working on lately. There’s been the open source Illuminato X Machina project (schematics, gerbers and software here), the Open Source Hardware Bank (and the Open Source Hardware that was produced as a result). But before I wax philosophic (perhaps something for later this week), I decided to try applying open source to a current problem.

Folks have been picking up the Portable Megapalm for one reason or another, where a touchscreen and buttonpad come in handy. But John and Glenn made an excellent point – why not have some handheld/mobile computing type software running on it? Maybe even some form of Linux? In any case, this could really go one step closer towards a truly customizable, open source, handheld/mobile computing device.

Then Matt and I looked at each other and asked “WWRSD?”, or “What would Richard Stallman do?” The phrase works just as well with Linus Torvalds, or your favorite open source hero :-)

Well, the conventional, closed-source solution would be to spend $1000’s (if not more) paying for full-time coders to develop proprietary software for such a project.

The open source solution would be to turn it around to a community of talented coders, passionate about driving their own projects and bringing open source devices one notch up versus closed source alternatives.

Nevertheless, Richard Stallman might mention something about the open source battle cry “free as in speech, not as in beer”. The classical gratis vs. libre distinction suggests that everyone is free to modify, reuse and contribute – but this does not necessarily equate to zero-cost. In the case of software with little marginal cost, however, open source has tended to mean both gratis and libre.

Despite the fact that many coders on open source project spend time on a project out of personal interest in a cause, it doesn’t mean that they couldn’t use some extra pocket cash.

It’s not the first time that someone is offering a little bit of money to help light the spark for an open source software project, though. My beloved New York City just launched an initiative called NYC BigApps, seeking software developers to create the best applications to analyze NYC’s open data sets and help improve the system, offering a $20K prize and a dinner with the Mayor.

Github launched something similar to improve its functionality. They offered up a nice ~$70 bottle of liquor in a friendly competition to solve a problem and get some new ideas and recommendations.

So I talked to Stephen, a staunch supporter of OS, and asked him what he thought of the situation. He said that he’d even redirect his I-bills towards getting some functional software written on the Slide and Portable Megapalm, on the condition that it was written collaboratively, and in an open source fashion.

Here’s what he was thinking in terms of stuff for the Portable Megapalm, all of which is open to thoughts and comments:

$1000 in funds towards folks who could develop a PDF reader
$500 in funds towards those who can get a quick JPG viewer up
$500 in funds towards functionality, features, or projects that the community votes on and is interested in seeing

Of course, it’s open source and collaborative, and shouldn’t be a hardcore competition! Hence I say “funds”, as it will be distributed across the top 5 or so contributors to each project.

What do you think? If you’re interested, or have an idea on how it could be better structured, feel free to send me a note or comment: jhuynh at gmail

On Friday, I’ll wrap up a few of the feedback that I get and kick it off next week. Looking forward to it!

Tuesday, October 6, 2009

New Haven Maker Meetup Recap

Thanks to the makers and hackers that came out to the Eli Whitney Museum last week for the inaugural New Haven Maker Meetup. There turned out to be quite a variety of projects and discussion, which is always a great source of inspiration.

Growing up in New York (and not CT), I didn’t have a chance to experience the Eli Whitney Museum as a child, so I was in for a real treat. The museum serves as a workshop for all sorts of hands-on projects, in addition to having a lot of neat historic relics. All-in-all, a great place to spend some time.

Museum Director Bill Brown kicked off the evening with a brief history the museum and the art of “making” as it existed in a different age. While the materials, medium and projects may be different, the ingenuity, curiosity, and pure interest in tinkering is timeless.

Bill ended his talk by making a favorite project of his own, on the spot: the rubber band powered car, and setting it off to the races! A shaky, full motion shot, was only fitting :-)
Here’s what they usually look like fully finished and decorated:image
We had a few neat demonstrations from Alex, Mike, and Rob. Alex brought in and talked about his crackerbox amp, which he built from parts that he salvaged from an old TV!
Mike talked a little about his experience tinkering and building the boards over in the Liquidware shop, and Rob (below) gave a demo of the Drawdio project (as well as a box full of other projects!).
Then we all split up into a mingling/project show-and-tell session, which is part of what makes meetups so much fun, and is usually where I get a lot of ideas for new stuff to work on.
And I just thought this one was really cool to see live - the RC Carduino that Raj set up on his own server:
All good, fun stuff, and a great excuse to hang out with other makers! If you’re in the area and want to be a part of the next one (tentatively for November 11), let me know and I’ll be sure to send you a reminder when it gets closer – jhuynh at gmail