API Changes for LaunchBar for Neon

The LaunchBar project that a number of us are working on is in a weird home at Eclipse for the moment, i.e. as a component of the CDT project. That makes it hard to reach everyone who’s extending it for their projects and products. Of course that’s assuming there are any, but if there are, I hope they’re following Planet Eclipse or my blog.

I have a big API change that I will be pushing tonight on the master branch. It reintroduces a concept I had a while ago but gave up when I foolishly drove IRemoteConnection as the way to model launch targets. Launch targets are the place where you want to launch. It will now have an ILaunchTarget which is a very general object, simply a name and a type identifier. And there are a few things around that to be able to match ILaunchTargets to your target management system of choice. In theory, I should be able to now push the whole launch bar to platform debug without adding weird dependencies.

The change is on the master branch which will be used for Neon. Maintenance for Mars will continue on the ‘mars’ branch. As always, let me know if you have any feedback, see any bugs, or have thoughts of where you think you could help.

Of course I need to document all of this and as I get satisfied we finally have the right APIs in place I’ll do that and help anyone who wants to use the launch bar with their launch configuration types, launch modes, and launch target types. More soon.

What a great first week for the Arduino C++ IDE

As I mentioned in the introductory note, I’ve been working on the Arduino C++ IDE for Eclipse for over a year. It started out as a very simple CDT extension to deal with the Arduino toolchain and SDK. But then the official Arduino IDE came out with a new release and a new metadata system that lets you download SDKs and toolchains for the vast array of Arduino boards and libraries. I knew it would be critical for the Arduino C++ IDE to have the same feature so I spent a lot of my personal time in the summer to get it working. And I love how it’s turned out.

But I only have two boards, an Arduino Uno and an ESP8266. Luckily the ESP8266 community has added an Arduino compatibility SDK and the ESP8266 toolchain to the metadata files so that’s let me use two really different boards to test things out. But I knew I couldn’t do it without some help so I released a Preview edition with hope it would grow a community of people with different boards and projects using different libraries and give it so much more test coverage.

And have they ever! Even before I posted the howto video I had a couple of people tweet at me thanking me for it. So I rushed out the video and since then, the feedback has been awesome. 18 bugs later, 15 have been fixed and 5 updates to the p2 repo and it’s in really good shape now. Even the Eclipse Foundation’s Mr IoT Benjamin Cabé has been helping with bugs and patches and some really good feature requests.

It’s a great start, better than I could have hoped for. And there’s more to come. So please give a try if you have an Arduino family board and a cool project to build and let me know how it turns out. The bugs and interactions with the reports have been incredibly valuable and I’ve learned a lot. And thank you in advance from me and this great community!

Introducing the Arduino C++ IDE for Eclipse

I’ve been working on this for over a year now and I finally have it in shape for people to try out. It’s the Arduino C++ IDE for Eclipse!

Why did I build it? Well really it’s because I bought myself an Arduino Uno to get familiar with the Arduino ecosystem and have fallen in love with it. But the Arduino IDE is pretty simple. What? An IDE without content assist? Anyway, I thought it would be really cool to bring the latest from our work on the Eclipse CDT project so I can use the product of my passion for tools on my passion for microcontrollers. And it helps us provide a proving ground for those ideas and an exemplary integration to show things off.

It’s up on the Eclipse Marketplace. Links to the CDT forums to ask questions and to the CDT bugzilla to report any bugs. I’ve also made a video to help users get started. The video also shows off two other components I’m hoping will be useful to the greater Eclipse community, the Launch Bar and the org.eclipse.remote Connections view and Console-based terminal. Enjoy!

Respect, it’s all we all ask for

Am I an asshole? Yeah, sometimes. I have strong opinions and I have a habit of saying the wrong thing and getting people mad at me. But it’s usually in cases where I see people treated unfairly and I try to stand up for them, usually very poorly.

We have a great group of contributors to Eclipse who work their asses off to make it better, often on their own time and their own dime. Often they have good ideas and I hate to see those ideas not given a fair shake. Everyone has an opinion and that’s what makes a community vibrant. But every idea and every contributor should be given respect. If you don’t you equally lose respect.

I made this comment on the UTF-8 default encoding bug that I hope resonates with people. Knowing how things go, I’m sure I’ll piss off just as many people.

Remember when you make decisions like this, you are making them on behalf of the
community, the entire community, not just your employer and certainly not only
yourself, and that you are doing it with respect for the opinion of those who've
commented on this bug and elsewhere. Then hopefully the respect would be mutual.
There are millions of users out there. Our products are successful because Eclipse
in the large is successful. We need to make sure we protect that.

My point is that when you make a decision when working on an open source project you have to take into consideration the entire community that’s impacted by that decision. With Eclipse, especially the Java side, it’s gigantic. And for us vendors, its a few orders of magnitude larger than the number of our customers. So when you make a decision that’s not in the best interest of the masses, it will sooner or later come back to bite you. You don’t want to go into a customer engagement and have the prospect say, “you built on Eclipse? Eclipse sucks!” That’s not good business.

It’s hard for us committers and leaders to see that. It’s miles apart from that moment of decision to where something like that could happen. But I try and keep it in mind when making design decisions I make. And if it causes a little short term pain for my customers, well that’s my problem to solve, not the community’s. If someone has a good idea, it’s my duty to treat it with respect and in the end it could make the product better for everyone, including my customers.

Launch Bar 2.0 for Neon

Screen Shot 2014-03-14 at 10.08.11 AM

I’ve been working on the Launch Bar for it seems like forever. But it’s still only used by a few people in the Eclipse world and I haven’t really made a push to get others to adopt it. I don’t think it’s quite ready for that. I’ve really been struggling with it’s place in Eclipse. It fills a missing need as far as improving the Launch experience.

It’s also filling a missing API need, the ability to specify where you want to Launch to. And I’m now thinking that this needs to be directly added to Platform Debug so that the launch target is passed on to the launch configuration delegate so it can pass it on to the launch, build for launch, etc. And if we’re going to do that, we should really put the launch bar down into the Platform Debug as well.

And if we’re doing that we should really not be using IRemoteConnection as the launch target as the Launch Bar does now. I’ve received a number of requests to generalize the target concept since not everyone gets why they need to use the new remote system. It’s funny as I actually had started with a more general concept anyway. So I’m going back to that.

But it does mean there will be API changes so the Launch Bar for Neon will be a major release, 2.0. The end goal is to contribute it to Platform Debug but I won’t have time for that in Neon. But we will get the APIs in shape so it’ll be ready for Neon + 1.

In the meantime, I have a release of the Arduino C++ IDE to put out which does use the Launch Bar. I’ll be producing a video of how to use it and I think from that you’ll see the value the Launch Bar really adds, especially when you have multiple targets where you want to launch your application.

Design like you won’t be there tomorrow

For Eclipse Neon, we’re releasing CDT 9.0. Yes, it’s a major release, the first one in a long time. It’s our chance to clean up a few things that may or may not affect APIs but gives us that option. I think it’s healthy and we’re communicating as best we can our plans as they evolve to the cdt-dev list.

One thing that’s bugged me is the CDT build system. Not the thing that builds CDT but the framework we have that manages builds of CDT projects. I think it’s ridiculously complicated for certain types of projects. It solves everything and is uber extensible, but if you are building an integration, as I am now for Qt projects, where the builds are simpler or done by something else, CDT just gets in the way. It’s time to fix that.

Which got me thinking. The people who contributed the most complicated frameworks in CDT are now gone. Even the companies they worked for have become mainly inactive. As a long time contributor I’ve seen the generations come and go and I see the poor people who come now and have to deal with these things. I really feel for them.

I don’t know how much longer my employers and my wife will allow me to be a CDT and Eclipse contributor. It could be for quite a while longer or it could be over tomorrow. As I look at the things I’m working on, I have that in the back of my mind. I want to leave behind frameworks that are easy to understand and simple. And if there already exists simple frameworks that can do the job, ask really hard whether I need a new framework there at all.

As I peel away the layers of the onion that is CDT, I have to ask why some of those layers are there and whether the requirements that drove their creation are really valid any more. If it takes longer to use your framework than it would be to build something from scratch, what value did you add? I don’t want people who come after me to ask those questions of me. I want to be kind to them and leave something that really helps them. And hopefully, I’m doing that.

Eclipse, the IDE for IoT

One of my hobbies recently has been playing with my Arduino Uno. I just love how accessible microcontrollers have become along with all the little sensors and LEDs and other hardware components. It’s so easy now to make your own “smart” electronics project. Lots of tutorials on the Web and a handful of on-line electronic shops to help you get started.

What we’re also starting to see is cheap wifi chips that you can add to your project. Not only that, but chips that have the microcontroller and wifi on the same silicon and SDKs to write programs that hook up your sensors and LEDs to the internet. Anyone can jump on the Internet of Things bandwagon.

But what is the Internet of Things that everyone’s talking about? My definition is more than just accessible hardware. It includes accessible web servers and web clients as well. I have a server I pay $5/month for and was dead easy to set up. It’s small but it does what I need for now. Web development is exploding with easy to use frameworks and mobile continues to provide open, or at least freely accessible tools.

And that brings me back to Eclipse. I’m using CDT for my devices, especially as I work to make the Arduino C++ plug-ins mature enough for others to use and then add support for my other devices, the ESP8266 and Raspberry Pi. I’ve written web servers in both node.js and vert.x. The Nodeclipse plugins have helped with node, and vert.x is just plain Java and I use m2e to manage my Maven pom files and builds. And client side, well, Eclipse needs a bit of work to better support the newer JavaScript languages like React.js’s JSX and Angular 2’s TypeScript. And I’m happy to see the Andmore project keeping the Android plug-ins alive. And, of course, I have the BB10 plug-ins we’ve built as part of Momentics so I can program my phone.

That’s why I love Eclipse. I can build my entire IoT stack from device to client with the same IDE in the same workspace. I can debug the entire stack at once. We should also have the capability to navigate code from the client to device as well. What line of C++ code in my device software triggered that React component to light up in my browser? With great static analysis that a Integrated development environment can bring you, we should be able to see that.

Eclipse is uniquely positioned to be the IDE for IoT. It’s not only the technology that brings all these environments together, it’s the community. What other community has the diversity of device developers, web developers and mobile developers all working together on a common tools platform? That’s what makes Eclipse an exciting community to be a part of.

What’s next?

The Eclipse Mars release marked a special moment for myself and our team at QNX and BlackBerry. It’s the culmination a few things we’ve really wanted to get done for our Momentics users and share with the greater Eclipse community.

It is focused around the Launch Bar and we’ve received great feedback from those who’ve tried it and those trying to adapt it for their own launch configurations and remote targets. And working with the community is why we do open source. We built it first for our BlackBerry Momentics users building BB10 apps and they loved it. But as we push forward we can learn and benefit from other IDEs trying to adapt it. It just makes the architecture better for everyone and ensures we can adapt it ourselves as we try to use it for new things. Open Source isn’t a charity so we give, but it’s also not a donation as we get a lot back in return.

Now that summer is in full force and I’ve finished off some vacation, it’s time to start planning for the next year. There’s still some work with the Launch Bar to do to clean up the rough edges and get it to the point where I would encourage all Eclipse packages to use it. I also want to continue the work we started with the PTP gang with the org.eclipse.remote target management system and make it a good replacement for the Remote System Explorer. I hope to get that in place by the Mars SR-1 release in September.

I also want to get back into improving Qt support in the CDT to make QML and qmake projects first class citizens so that the CDT is a good option to Qt Creator and let Qt developers take advantage of the Eclipse ecosystem.

That led me into the discussion about how to make it easier to add languages to Eclipse, in this case QML. There’s been some great discussion on the ide-dev list and other places with lots of ideas. I want to use ANTLR 4 for the QML work and am hoping I can generalize out of that so we can make it easier to add other complex languages like it. I’d like to extend CDT’s support to all languages supported by clang and LLVM. Even Swift if that’s the direction they take to open source it.

And it opens up an area in CDT that we really need to improve to allow us to take advantage of new toolchains and build systems. The CDT build system has always been somewhat cumbersome both for adopters trying to hook our tools up, and users who are trying to set up their build environments. We’re going to work with the CDT community to see if we can come up with a simpler architecture that takes advantage of the build systems, such as Qt’s qmake and CMake, that weren’t around or as mature when we started.

I also have my personal work on the Arduino C++ IDE for CDT. IoT is a great area of focus in open source and it’s really fun to architect an IDE for. You have a lot of choices in micro-controller (Arduino, ESP8266, and many upcoming Cortex-M* boards) and Raspberry Pi and other Cortex-A* boards. We really need to have CDT in shape for those developers.

But IoT goes beyond devices, you also have the cloud that they pass data to and get commands from, and then you have the Web and Mobile clients that hook up to the cloud. IMHO, Eclipse is the best choice as an IDE to build and debug all those components. And with my recent work at QNX, I have first hand experience at that and swear by it.

Lots to do and I’m certainly not going to get it all done when I want to, but we’ll keep plugging away and accept help when it’s offered and we’ll get there.

My Journey to Mars, Eclipse Mars

Wow, Eclipse Mars is almost finished and it’s been very busy for me and those I’ve been working with. We have a lot of exciting new features coming and I can’t wait to get them into the community’s hands and see where they take them.

I’m going to write more over the next few weeks on each of these, but I thought I’d give an overview of what you can expect for Mars. They all stem from a common theme, make Eclipse easier to use and lower the barrier to entry for new users, especially those writing C and C++ as a hobby, the new breed of hobbyist computer engineers using $10 computers to build amazing electronics projects. New users mean a growing and vibrant community.

Here are the highlights.

Serial Port Library

CDT has a pretty interesting native library that provides interfaces to native tools that the Java run-time doesn’t. This includes a Process subclass called Spawner that can send Unix signals, a Pseudo TTY interface (PTY) that can be used to set up terminal like interfaces to processes, and access to the Windows Registry.

One thing that is really common with these new $10 computers, especially the microcontrollers like Arduino is that you need to connect to them with a serial port to see what’s going on. For whatever reason, the serial port libraries out in the open were all GPL/LGPL and the main one, rxtx, has disappeared. Serial port programming isn’t rocket science, so I wrote my own library and added it to the CDT native feature. My first use is with the Arduino CDT covered below.

Remote Target Management

As I was building the LaunchBar (coming up next), I needed a way for the user to select which system to launch on. I made one that was pretty simple that adapted the targets such as those we were using for QNX and BlackBerry. I then started adding features, like a View to interact with the targets and then thought about a services architecture that would add command shells, remote launching, remote file access, i.e., a full blown target management system.

Well, that reminded me of Greg Watson (from PTP fame)’s talk from a few years ago about the fact we have too many target management systems, and none of them do everything we need. So he started one that does. I decided instead of writing my own, I’d add my vision to Greg’s and come up with an uber flexible, services oriented target management system. The beauty is that it’s easy to adapt to any existing TM system. And we’ll continue to build out features and make it a suitable replacement for RSE in upcoming releases.

Screen Shot 2015-05-18 at 1.56.06 PM

The LaunchBar

The LaunchBar has been the focus of my team at QNX’s efforts to fix up one of the biggest usability issues we see with Eclipse, the whole mechanism to launch the applications you’re building with the IDE. There’s been some work to improve that over the years, such as the launch shortcuts, but frankly, other IDEs do a much better job at this.

We felt it was important for the user to know exactly what was going to happen when they hit the run button. And that’s accomplished by showing the current selection, i.e. What you’re going to launch, Where you’re going to launch it to, and How you’re going to launch it. How is simply the launch modes we’ve had in the past but make more accessible. The Where relates to my work with the Remote TM system. In this day with embedded targets and cloud servers, we’re often building software that’s going to run somewhere else than our desktops.

The most important aspect what helping the user define What they’re going to launch. And really, my objective here was to make it so that the user never needs to go the the launch configuration dialog for the most common cases. To help with that, we have an automated system the populates potential What’s. By default, launch configurations are a What, obviously, and that makes the launch bar usable with existing launch configurations. But the system is flexible, and What’s can be anything, for example, Arduino projects.

Screen Shot 2015-05-18 at 2.00.03 PM

Arduino C++ IDE

My first foray into the hobbyist computer engineer world was with Arduino. I bought an Arduino Uno and built a little system with a sensor and a wifi shield that was a kind of Internet of Thing. But after years of using professional IDEs, the last many being Eclipse, I wasn’t very excited about the standard Arduino IDE. Also, Arduino programming is done through this language called Wiring which, come on!, it’s so close to C++, why not teach hobbyists those last two or three concepts and “Program Your Arduino in C++ Like a Pro”.

And, hey, I know this great C++ IDE they can use. So, and this is the self serving part, I set out to build an integration for the Arduino toolchain for CDT. And it turned out pretty nice and I enjoy using it for my Arduino projects. And as a bonus, I get to use the same IDE, hell, same workspace, to program the server side of my Internet of Thing project. For me, that has always been the promise of Eclipse: One IDE to rule them all!

I have the plug-ins in CDT and they’ll be coming out in Mars. It’s really only a preview at the moment and you’ll need to have the standard Arduino IDE installed for it to work. As I was wrapping up the Mars work, Arduino released their 1.6 version and with it and pretty nifty library and BSP management system with an open data format. I plan on adding support for that system to the Arduino CDT plug-ins as well and that should eliminate the need to install the Arduino IDE if you so desire.

The Journey Continues

As I mentioned, I’ll write a lot more about these features in the upcoming weeks. It’s going to be hard to try them without a little documentation and that will come here on my blog for now until things mature. There’s a lot more ahead as I get feedback from the community and people try to use these things in different configurations. I already have great feedback from the Red Hat JBoss guys who are trying to use the LaunchBar for WTP that’s resulted in a pretty big last minute change. But this stuff is only successful if people use it and contribute back so I’m more than willing to listen.

Also my journey into the computer engineer hobbyist world continues beyond Arduino. I have a Raspberry Pi B and I have been able to build an ARMv6 hardware float toolchain for it. We’ll likely make this the first official embedded target support provided by the CDT as an example for the embedded vendors to follow. We should have done that a long time ago.

I’ve also just purchased a couple of ESP8266 chips. They’re little microcontrollers inside a wifi chip with a healthy number of GPIO pins, all for $10 or less. The Chinese company that makes them has put out a pretty good SDK and the toolchain is again standard GCC. I need a CDT integration for these too :).

I mentioned in my note about EclipseCon that I think this is probably the most exciting time to be in the Eclipse community since they early days. So many new features and great work being done by a diverse team of really smart people has breathed some much needed new life into our favourite IDE.

EclipseCon 2015, the Ship Tacks

I’ve been to all 12 EclipseCon North Americas. I especially love coming to this year’s venue, the Burlingame Hyatt, because it hosted the second one in 2005 which has been one of my favourites. It was a very different EclipseCon back then. There were probably more product and marketing managers than developers and the buzz was incredible. We had two of the greats in the modelling industry going head to head, IBM Rational and Borland, and it was a fun spectacle to watch from our CDT viewing rooms on the periphery. I’ll never forget it and I always take a pause when I get there to soak it all in again.

In recent years, EclipseCon has become a developer’s conference, and frankly we developers prefer it that way. You don’t get the same numbers or the same marketing buzz, but we build some very important relationships that carry us throughout the year and we wouldn’t survive without it. I’ll never forget our last time in Santa Clara and Kai Toedter still working away at the e4 challenge as we closed the bar at 2 in the morning. We developers know how to have our own fun.

It’s been a hard few years for Eclipse though, at least for the IDE. It’s been kind of sad, but we spent a lot of time complaining and worrying as more and more of our friends from the Platform started working on Jazz and Orion and not on the Eclipse platform. Having been there, I know the business decisions behind such things and it’s pretty easy to understand the need. But it didn’t make us happy, and we were somewhat counterproductive fussing about it.

This year, though, was totally different. We talked very little about that past. It was replaced by discussions and demos of the cool things we are working on now to revitalize the Eclipse IDE that we all know and love. My feeling of worry in the last few years has been replaced with feelings of hope and energy to continue on the fight to save it. And we have new leaders in the community driving it: Lars, Mickael, Sergey on the Platform, Max on Web development, Eike providing us some Oomph, Greg and myself on revitalizing target management with a new look at the Terminal and my new LaunchBar, plus all the great stuff still happening in the DSL and modeling space. Even the Orion guys seem open to working with the JSDT guys to bring the two technologies together and provide a great JavaScript experience in the IDE.

I’ll be writing about the things I’m working on over the next few weeks, including some new energy we got out of the CDT Summit and an interesting chance meeting that will bring some interesting tooling for Arduino fans. We have a lot of work ahead and it’s important we communicate and work with the community to make it right.

Eclipse solved a problem we had 15 years ago over the need for an industry standard and open platform where we could install all our tools and have them interact with each other to make a greater whole. 15 years later, we still need that. And as Eclipse jumps back to life, I’m excited for great things again and am working with a great group of developers who are all intent on making it happen. EclipseCon gives us that much needed face-to-face and the opportunity to show the community what we’re doing and invite them to join in on the fun. I can’t wait until the next one.