Let me tell you a story.

I got into work today and found an e-mail in my inbox from my boss. A customer was having an issue and he wanted me to look at it. He included in the e-mail a link to the JIRA. I clicked on the link and it opened up.

The good news is that the JIRA included an analysis from our fault analysis AI engine. I clicked on a link and it brought up the report.

The engine had seen the same crash the customer reported a few times and analyzed my source to pinpoint where it was wondering if a value passed into the API was not being handled properly. OK, let me try this in the simulator with the debugger. I click a link and git checks out the corresponding version of the software stack used in one of the crashes.

Running it in the debugger, I see, that yes, the engine was right. One of the clients was passing in a value that I wasn't expecting. So I added code to handle it and ran it with the simulator again. Worked there, but to make sure I changed the target selector and to run it on some real hardware. A VNC session opens up and I can see that it fixed it there too.

I then click commit. All the relevant information from the investigation so far is automatically added to the commit comments and I add a quick line apologizing for missing this scenario and click submit to Gerrit. The review opens up and I do a quick check to make sure everything I wanted was there. I then see that the verify job has started up on Jenkins and I go for a coffee.

When I get back, I have a notification that the verify job has failed due to one of the tests failing. I click through to see the test and click another button for git to checkout the test and to start it running on the simulator under the debugger. A breakpoint is hit at the failure and I see I messed up the handling for the value it was passing in.

I make a quick fix, run the test again. It passes. I run the test I was doing for the original scenario and see it's working too. I amend the commit and resubmit. The Jenkins build passes and I do the final commit to the branch.

A few days later, I get a notification from our fault analysis AI engine. It has noticed that since my change, the crashes no longer happens. With that confidence, I mark the JIRA as verified and the customer is happy.

This is what I want from my IDE. I didn't use the term IDE in the description because everything I interfaced with to solve the customer's problem was the IDE (yes, even the mail client). We have all of this already, except maybe the AI engine, but that will come. What we're missing are the little things we get from these tools knowing about eachother. It's the "I" in IDE!

Mik Kersten envisioned this many years ago when he invented Mylyn. And I've seen a lot of this in IBM's Jazz. I think a lot of those ideas were ahead of their time and on a platform that struggles with being this complete environment. Workflows start with the cloud for the analysis phase, then meander into the desktop code and debug environments to test and fix the problem, and then back into the cloud for verification and closure.

The next generation IDE needs to seamlessly blend these tools so you don't even notice where things are running or even when you've switched between them. You know you're using a great IDE when you don't even realize you're using it.

As I was putting together my slides for EclipseCon, I occasionally like to bring up the forum post from John Duimovich, the Tools PMC lead, that announced the changes QNX was bringing to the CDT project, the birth of the new CDT project.

CDT started out as this remote development thing built by the mainframe tools team at IBM, with the remote parts of that evolving into RSE. With the reboot of the project, QNX brought what we have today, essentially a JDT look alike that added C/C++-things like calling ‘make’ to do builds and a gdb integration called CDI.

Below is link and excerpt of that post. What hit me now was that happened in the summer of 2002. That makes CDT officially 15 years old! Happy Anniversary CDT!

Huge thanks to everyone who has helped us over those years grow this thing into the best industry leading community built C/C++ IDE we all know and love.

I have to give a special thanks to the original team that started it here at QNX, some are still at the company, some moved on, and to Sebastien Marineau who was our first project lead and a great community builder who I still struggle to live up to 😊.

And a huge thanks to everyone who is helping today and are thinking of coming on board to help us take CDT into the next 15 years. It doesn’t happen without you!

https://www.eclipse.org/forums/index.php/t/11372/

From: "John Duimovich"
Newsgroups: eclipse.tools.cdt
Subject: [ANN] - CDT project changes Date: Fri, 7 Jun 2002 17:20:34 -040

The Eclipse Tools PMC is pleased to announce some exciting developments to the CDT project hosted on eclipse.org. First, QNX will be contributing some C/C++ core technology from their recently announced product to eclipse.org. We believe that this will enhance the value of the technology hosted on eclipse.org and bring some industrial strength technology into the CDT project.

In addition, the Eclipse Tools PMC has been working on getting additional cross-company project participation on the C/C++ project (www.eclipse.org/cdt). There has been lot of interest from many of the eclipse member companies and the community at large on this project and we've been working with many of them in helping them get involved with the C/C++ project at eclipse.org.

As part of this additional participation we're excited to be able to announce that there is a new project leader, Sebastien Marineau from QNX who has agreed to lead the C/C++ IDE (CDT) project on Eclipse.org. In his role as project leader, there will be a re-plan of the V2.0 CDT deliverables to include the new technology.

When I started my blog almost 12 years ago, I chose Blogger. For the time it was really cool, being able to easily create content on-line and publish with a click of a button. It served me well.

A couple of years ago, I decided I needed to upgrade my skills and learn more about web development. With servers at Digital Ocean only $5 a month, I dove in. Everyone seemed to be throwing love at Wordpress so I chose that and started cdtdoug.ca importing all my posts from Blogger. PHP and MySQL can be pretty taxing on a $5/month server but I managed to find settings to make it work.

As things tend to go, we started doing real web development at work and I ended up using a lot of those skills I gained working with my own server. I learned a lot about AWS and quickly fell in love with the power of it. I chose to grab a free year and I migrated cdtdoug over to an AWS machine. I love how developer friendly Digital Ocean is, but AWS is, well, AWS.

Well, the free year ran out and I was running on a $10/month server. And I really wanted to do other things with this server and Wordpress was taking a lot of juice. Googling around for alternatives, I ran across Ghost. Ghost runs on node instead of PHP and when run with the SQLite option, it's very lightweight and fast. If I become super famous, it probably won't scale, but I don't think I need to worry about that.

So I set up a new server, a $5/month t2.nano and migrated my Wordpress blog to Ghost with Disqus for comments. I used mainly this guide (click) and the Ghost docs themselves. It went pretty smooth and I'm pretty happy with it so far. It force me to learn Markdown (what was so wrong with WSIWYG?). And it leaves a lot of room, even on this tiny server, to do some IoT things I've been meaning to try. It'll do for now, until I get the itch to change it yet again.

Remember Eclipse Two? Yeah, that was a lot of fun. Not sure anyone cares what happened to it. It made quite a splash back at the beginning of the year which proved to me that there is interest in a new tools platform for the desktop. Well, it’s been an interesting journey since then and I thought I’d give you an update.

First, I do firmly believe that Electron as a combination of Chromium for UI and node.js at the core will be a great tooling platform for the future, if not sooner than that. You look back when Eclipse started, and I think Mike mentioned this in a recent article, Java was the cool new kid on the block. Everyone wanted to learn it and use it and with SWT, it finally became performant and good looking enough to build the next great IDE platform that we have today.

You look around today, and ask that same question. What is the cool kid on the block that everyone wants to learn and work with? Well, I think it’s obviously HTML5. There’s no doubt there’s lots of hype to it. And with hardware accelerated rendering in Chromium and the native look and feel you can get with Electron, I think it’s ready to be the next next gen.

But a funny thing happened along the way. We released our latest QNX Software Development Platform with the culmination of all the work we’ve done the last few years with our Eclipse-based IDE Momentics. And our customers like it. They like it a lot. CDT is still the best C/C++ IDE in the industry and the user experience improvements we and the rest of the Eclipse community have delivered is paying off for us and them.

As much as I’m interested in seeing the next generation IDE platform, it has to be as good or better than what we have today. And personally, I think we’re a long way from that. Knowing how much work that has gone into the CDT to have it’s great static analysis engine and it’s clean debugger integrations and the clean up of launch workflows that we’ve achieved with the Launch Bar, you would need a very strong community to duplicate that. And you would need community leadership to bring all the different interested parties together to work towards a common goal. I struggle to see how that comes together and I look forward to discussing with fellow CDT’ers at EclipseCon Europe to understand where their visions lead.

For now, along with working on improvements to Momentics and CDT, I am continuing to work with Electron on some other tooling ideas. I think we have something cool in the works for system tracing, an area that a lot of us embedded systems vendors have struggled with in Eclipse and SWT. A lot of custom code has been written to make our System Profiler and Eclipse’s Trace Compass look good and navigate well. That could be an area where we could grow a community.

It will take us a long time before we know where to go next and I’m convinced that’s a good thing. If anything my work on Electron-based tooling has taught me is that we have a lot to learn with these new technologies. They are so new and constantly changing. It’s tough to build an IDE platform for the next twenty years when JavaScript frameworks come and go every couple. But the good news is that we have time. Eclipse is still going strong and giving our customers the great user experiences and the productivity improvements we promised them. We can afford to be choosy on the next one that will give them the same.

As a veteran tools architect working for a veteran embedded systems platform vendor, we’re getting pretty good at building cross development environments. You get all the speed and integration with other native tools that today’s rich host platforms can provide. Combine that that with a good installer and software maintenance tool, and it’s super simple for users to get setup and keep their installs updated with the latest fixes and patches. It’s worked for many years.

So of course, I was a bit taken back with recent talk about delivering development environments in containers and distributing them to users for use with cloud IDEs. The claim is that the installation process is simpler. But I have to ask, while yes it is simpler for the provider, is it also simpler for the user?

I work with embedded software engineers. Their systems are complex and the last thing they want to do is fight with their tools. That doesn’t pay the bills. And that’s why we work so hard to make that management simpler. And if you don’t have the experience creating cross development environments, it is certainly appealing to only have to worry about one host platform, 64-bit Linux, as you do with Docker which, BTW, just happens to be the easiest to support especially relative to Windows.

But do I really have to teach my embedded developer customers about Docker? How to clean up images as updates are delivered? How to start and stop containers, and in the case of Windows and Mac, the VMs that run those containers? And that’s not to mention cloud environments which are a whole new level requiring server management, especially as the developer community scales. Embedded development tools require a lot of horsepower. How many users can a server actually support and how do customers support the burstiness of demand?

So, while I get it, and as vendors take this path and as users do get used to it, I do need to be prepared to support such environments. I’ll just feel a bit sad that we are giving up on providing our users the great experiences that native cross development tools provide.

If you haven’t heard of the Language Server Protocol and the language servers they inspire, take a Google around. There’s something very interesting happening here. The direction the LSP starts, and we’ve had discussions around a Debugger Server Protocol as well, opens the door to the componentization of IDEs.

And this is quite different than the plug-in model we have with Eclipse. Instead of creating a UI platform and having plug-ins add menu items, preference pages, editors, views, etc., build your IDE from the other direction. Take a collection of components that don’t have UI, that implement IMHO the hard things about IDEs, language parsers, build systems, debugger frameworks, and wrap them with your own custom purpose IDE “shell”.

Eclipse suffers to a significant extent the “Tragedy of the Commons”. There is a large amount of inconsistency between plug-ins that do similar things but do it in different ways. Why is there a Perspective for every language? Because each language plug-in developer has different ideas on how the “Code” perspective should be laid out. And maybe, for their users, they’re right.

An alternative reality has language plug-in providers provide APIs that allow IDE builders to provide their own user experiences. Yes, that would be a lot more work and probably not practical. But as the doors open to a new generation of IDEs, language plug-in providers need to think about how they’d plug into many of them. It’s not clear which one will be the winner or even if there will be a winner.

It’s a brave new world. And we have a way to go before we figure it all out. But it’s a great time to think outside the box and see what sticks to the walls, or in my case, what I don’t erase from my whiteboard ;).

It’s no secret that the modern developer’s favorite tool is Google. See a compile error you’ve never seen before, hell, cut and paste it into google.com and see if someone else has seen it and figured it out. It’s crazy how many times that works. That information sharing via blogs and forums makes the Internet an everyday part of a developer’s lives.

And, of course, it doesn’t end there. The Web makes it very easy to build services around shared data and artifacts. We put our bugs in Bugzilla or JIRA, our code in Github or some other git repo on a server somewhere, run our builds in Jenkins, code reviews on Github or Gerrit. These web based tools are indispensable for developers.

Now, it’s not entirely without merit that you would want to put your IDE up on the Web as well. It could be just another tab in your browser that you already have open for these other tools. But people who know me know that I’m not sold that that’s a good answer for everyone. And I especially look to embedded developers who have boards hooked up to their development machines and have installed a bucket of tools, as old as they may be, that do a great job helping build software for those boards. That, and you’re laptop has a lot of power that you own and can do what you want with without sharing with dozens of other developers who want to do whatever they want to.

For me the best solution for now would be to find a way to merge all the great tools on the Web with all the great tools on your desk into seamless workflows where you forget where the tools reside and you just do. And that’s where my experimentation with Electron and my Two IDE are showing a lot of promise. Let’s walk through an example with Github.

Have you ever opened up a Github page and clicked on the “Clone or Download” drop down? It’s pretty interesting that one of the choices is “Open in Desktop”. Click it in your browser and it takes you to a page to download Github’s developer tool. I’ve never used it but it sparked a similar idea I had for Two. It would be really cool to have a button that triggers the clone and sets it up in the IDE all in one click and a quick wizard for local settings.

So how would we go about that. Looking at the HTML source for the page, I was able to find the elements that created the Open In Desktop button. What I’d love to do is munge it somehow to say Open in Two IDE and add a click handler that would trigger the rest of the clone action.

One of the coolest things about Electron is that it has Chromium built in. And you can take full advantage of that and use the special features that Chromium has that the other browsers don’t. One of those is the webview element. It essentially creates a new rendering process that renders into an element managed by another process. I use it in Two to add a Github browser.

One of the attributes of the webview element allows you to specify a preload script. This script is run by the new rendering process before anything else in the new context. And this script has full access to the node.js environment. It lets you do some crazy things, like this:

import { remote } from 'electron'; window.onload = () => { const box = document.querySelector('.mt-2'); if (box) { const a: HTMLAnchorElement = box.children[0]; a.textContent = 'Open in Two IDE'; a.href = '#'; const input = box.previousElementSibling.children[2].children[0]; a.onclick = () => { remote.dialog.showMessageBox({ type: 'info', message: Cloning ${input.getAttribute('value')} }); }; } };

Now, this is TypeScript. But what I’m doing here is ‘require’ing the electron node module with the import statement which gives me access to the Electron remote API to call back to the main process. Whenever a page loads, I search the page for the element that contains the “Open in Desktop” element. I essentially hijack it and change the text and href and add a click handler to it. I get pretty sneaky looking for the URL for the clone by walking around the DOM a bit. I finally show that URL in a dialog box by calling the remote API to do that. Only the main process can open native dialogs.

Of course, I’ll eventually ask the user for a destination file path and any other arguments and then call the local git to make the clone happen and add it to the list of paths to show in the FIle Explorer. But for now, this is what I see:

Of course, you should be quick to point out that this is very fragile. If the Github gang redo the layout of the page, this breaks. But my theory is that if this type of integration becomes popular, you have a bit more leverage to go to them and create APIs, by having fixed classes or element ids that are more robust. Then any IDE trying to do this would benefit.

At any rate, this was a pretty early experiment that I haven’t spent a lot of time with. But it shows the path. By manipulating the content of the pages provided by web services, you can create workflows that span those services and the local development environment. And the user sees one tool. Click the Open in IDE button and it all magically gets set up and the IDE can switch automatically to the Code page to let you start working with it. Imagine what else you can do like this…

It’s been a wild few weeks on the journey I now simply call “Two”. (Until it becomes an Eclipse project, I can’t call it one. And rightly so). The feedback I’ve received, especially as it hit the presses, was fantastic. It’s driven a lot of traffic to my github repo. I’ve even received a few pull requests from people cleaning up my mess as I plow through it. At the very least, people are intrigued by idea of an IDE built with Web UI technologies running locally under Electron.

As I work through the vision, I don’t think it’s fair to simply call it yet another Eclipse IDE. It’s much grander than that. For me, Two is about that vision. It’s more than a code editor. It’s more than just taking the existing Eclipse IDE and implement it in HTML5 running locally. It’s about a whole new way for developers to work with their tools and access the resources available to them on the web.

Developers today have access to many powerful web services. Github is a huge one. At Eclipse we use Bugzilla for bug tracking. A lot of companies use JIRA. People may be using Gitlab as their private Github. You may be using Gerrit for code reviews. I notice LLVM is using Phabricator for code reviews. And there’s the venerable Review Board still active today. Jenkins for continuous integration. And don’t tell me you don’t cut and paste error messages into Google searches to find others who’ve seen the same problem and worked out a solution. The Web is a critical tool in the developers belt.

I was intrigued by an article written by the creators of a tool called Ship. It’s a Mac native, i.e. Cocoa, app that integrates with the Github issue tracker. This quote hit me:

“A point of pride for us is that many people we have shown Ship 2.0 haven’t been able to tell where the web-based content ends and the native Cocoa stuff begins.”

That’s exactly it. If we can say the same for Two, where you can’t tell where the web ends and integration with local tools begin, then we’ve hit a home run.

Integrated Development Environments provide the most value when they have integrations between tools, which the developer has had to do manually for years. The IDE’s role is to automate workflows that transgress all the tools the developer has to use, where the workflow becomes the key, not the individual tools themselves. This focus makes it much easier for them to accomplish their objectives, so they don’t have to learn all the intricacies of underlying environments, but provide a unified language.

And that’s what Two needs to be, a tools integrator that includes not only the tools the user has installed locally, but also integrates with these super powerful web resources in seamless workflows.

The other important factor with IDEs that so many forget, is that experienced developers will always have a bit of mistrust in their IDE no matter how good it is. They need to be able to get close to the iron and run the underlying tools manually at a place where their trust is higher. An IDE that hides that, or makes those tools hard to get to, will struggle being universal. That’s why I’m not a fan of Cloud or Docker hosted tools. In making deployment easy for the provider, they make it hard for the user to touch the bits they’re creating.

The main reason I don’t want to call this Eclipse Two is that this isn’t just about a next generation Eclipse IDE. That IDE was my One, the first IDE that I’ve had a hand in creating. I want to rethink the whole developer experience and create an IDE that works well in the modern world, now almost 20 years after One. This is Two.

I know a lot of people didn’t like how 2016 turned out, especially Americans, but for me it was a year of reflection and renewal.

As the state of the art for user interface frameworks gel around hardware accelerated graphics, I have been worrying for the future of Eclipse. It’s age is really starting to show and it’s getting harder to find tools developers that want to work with it. And with the murky future of JavaFX and Java as a desktop application technology, It’s time to start looking for the next thing in desktop IDE frameworks.

I also spent a lot of the year learning more about what embedded software engineers do. I’ve been building tools for them for many years but haven’t had a chance to use them myself. As Arduino and Raspberry Pi become cheap yet powerful and accessible devices, I bought a few of them and am starting to see how fun it is to program these devices to interact with the real world.

There are a few areas where I will be focusing my time in 2017. Here are some quick highlights. One New Years resolution I definitely have is to write more so I’ll be adding details as the year progresses.

Eclipse Two

Those who follow me on Twitter will notice me working on a new project that has grown from my fascination with Electron. Electron is the combination of Chromium and node.js in a desktop application framework. It’s what Visual Studio Code is written with along with many new and upcoming desktop applications, like Slack. It’s given me a fun opportunity to really learn HTML, CSS, and JavaScript and think of how I’d build an IDE with it. I have a couple of things running and you can follow along here on my github account.

Of course people have asked why not just extend one of the many text editor frameworks, like VIsual Studio Code, for what I need. There is a big difference between text editors and IDEs. Text editors seem to focus maniacally on being just text editors. IDEs add different types of visualizations and graphical editors that abstract away some of the more complex aspects of systems development. Web developers may not appreciate it much (yet), but embedded software developers really need the help that these abstractions provide.

My hope is that this work with an Electron-based IDE bears fruit and attracts IDE developers who are excited about the same idea. I’ve called it Eclipse Two (and it’s not e2, BTW, it’s Two), since it’s my full intention that if the Eclipse community is interested, we’ll bring it there. As it was in the days Eclipse One was introduced in 2001 and CDT in 2002, we can’t build this by ourselves. It only succeeds with a strong community and with strong architectural leadership that Eclipse is famous for.

CDT and the Language Services Protocol

The Language Services Protocol (LSP) is quickly becoming the accepted architecture that enables IDE’s to acquire language knowledge users expect as well as allows us to experiment with new IDE front ends, like Eclipse Two. Since it’ll be a few years before a new desktop IDE enters prime time, we’ll need to keep Eclipse and the CDT alive and thriving.

One thing we’re starting to see, thanks to Dr. Peter Sommerlad and friends on the C++ Language committee, is the C++ language continuing to evolve and modernize with new language constructs introduced every three years. It’s going to be very difficult for the small CDT team to keep up.

We need to look for alternative language providers and work with other IDEs, possibly leveraging the LLVM project’s libclang or some other parser that we could hook up to the LSP. That will likely be a lot of work since we rely on the CDT’s parsers for many features that the LSP doesn’t currently support but I think it’s a long term direction we need to investigate and a number of us CDT committers feel the same way.

Arduino and the Electronic Hobbyist

I am still fully committed to the Arduino plug-ins I’ve built for CDT and will continue to enhance them as the Arduino community and the mainstream Arduino IDE evolves. I am still hoping that members of the community will help with code along with their fantastic bug reports. The feedback has been nice to see and I’m glad the plug-ins have been useful.

The more I look at the work that embedded software engineers do and the incredible complexity of the systems they are working with, the more I am reassured that these developers do indeed need the help a good IDE can give them. Of course, it has to be a good IDE and I continue to work to understand what that means and help make it happen.

BTW, I had started on some plug-ins I was using to program the ESP8266 I used in my demos in 2016. Since then I’ve been in conversation with the ESP32 community and it’s been great to see that they are already adopting Eclipse and the CDT. Instructions are here if you’re interested. The good news for me is that it’ll give me a chance to stop working on my own plug-ins and to give me more time to focus on the other things in this list :).

Use an RTOS for your Real Time system

Programming the ESP8266 gave me some experience with FreeRTOS. In the demo, I have an ultrasonic sensor that I use to trigger different colors in the NeoPixels I also have attached to the chip. All of this is very real time sensitive. I need to measure the time between two interrupts to calculate distance from the sensor, and the NeoPixel communications depend on sending a serial stream of data at a very sensitive clock rate. Real time matters.

As part of the demo, I was showing CMake and the Launch Bar and how easy it was to switch from building and launching for one system to another. I took the real-time code for the ESP8266 and pretty much ran it as is on my BeagleBone running the QNX Neutrino RTOS, including the interrupt handlers and the NeoPixel code. I can’t imagine doing that on Linux. I know I work for the company, but it really helped me appreciate the Neutrino microkernel architecture and how easy it is to build an embedded system with the tools and APIs we provide.

The problem is, not enough people know about Neutrino and what a good RTOS can offer. Too many people are using Linux in real-time systems because it’s easier to get started, because it’s what they know, not because it’s the right architecture. One thing I hope to do is to help with the cause and spread the word and make it easier for the community to try it out. What that means, we’ll have to see in the upcoming months.

Beyond the IDE

I’ve made my career as a tools developer to do what I can to help other software developers build systems. But tools alone isn’t enough. Tools need to be combined with education through demos and tutorials and other types of instruction. Now imagine combining the two, a tutorial you access on the web that drives your desktop IDE as you learn.

And with that we come full circle as that’s one of the use cases I hope we can achieve with Eclipse Two! An IDE that not only helps you write and test code and build systems, but teaches you how best to do that as well.

Happy New Year and all the best in 2017!

It’s going to be a great year for the Eclipse community and technology and I look forward to helping where I can.

MSYS2 is a relatively new distribution to support the MinGW compiler on Windows. It’s actually grown beyond that and has a pretty rich set of packages that include CMake, clang and gcc, and a huge set of libraries including Qt and SDL. It’s kept reasonably up-to-date and I’m sure if we can grow the community even more, we could get things even faster (e.g. Qt is one minor release behind).

On Windows, the CDT loves MinGW and MSYS. As Eclipse is a native application, it really expects things like path names and such to be native Windows things. Cygwin, being a Linux emulation layer, and the recent Bash for Windows are actually hard for CDT to integrate with because they hide away the native.

For Eclipse Neon, CDT has added support for automatically detecting the MinGW compilers in an MSYS2 installation. This article will give a quick guide on how to set up MSYS2 with the proper set of packages to start building C++ projects on Windows.

First a quick rant about their choice of package manager, pacman. I’m sure people who use Arch Linux love pacman. It’s pretty powerful. But I worry that it’s a tough fit for Windows users. The problem gets worse as there are actually three sets of packages, msys (common), mingw32 (for 32-bit tools), and mingw64 (for 64-bit tools) and some packages are in multiple of those. pacman makes you pick each time you install a package. And it gets worse installing the toolchain since mingw32 and mingw64 each have toolchains that target 32-bit and 64-bit. Now you’re up to five combinations.

But it’s what we got so we’ll have to make due. Hopefully we can simplify this a bit.

First, most people are on 64-bit Windows these days and for that, just select the mingw64 packages and the x86_64 toolchains. If you are on 32-bit Windows, go mingw32 and i686 toolchain. If you are targeting both 32 and 64 bit, simply add the other toolchain. But also make sure you add all the libraries for that architecture too.

MSYS2 starts with a pretty decent installer. It’s available from https://msys2.github.io/. The instructions on that page are a good description on how to do the initial setup. After finishing that, you still have no toolchains or libraries. To set up your development environment, run the following command. This gives you gcc and make, enough to build a hello world project.

pacman -S make mingw64/mingw-w64-x86_64-gcc

A couple of quick notes on that. The toolchain comes from the mingw-w64 project which produces both 32-bit and 64-bit compilers. Confusing? Yes. Also, pick the make from the default package set since it’s a more full featured make than the mingw32-make that comes with the mingw64 package set.

That should be enough to get started. Feel free to poke around and add library packages you’d like to use. Qt projects should just work with CDT’s new (and still very young) Qt plug-ins.

More later as we figure out the right configuration for CMake and for other libraries.

I spent a good chunk of the week trying to figure out the last time I was at EclipseCon Europe. The last thing I remember was spending a night in the Nestor bar until 5 a.m. with a handful of attendees, including Torkild, with the honored presence of Dave Thomas, the spiritual founder of Eclipse. That was 2008! It’s been eight years! I’ve missed so much. But I’m so glad that things in my life have cleared up to enable me to attend and I don’t expect I’ll miss another one for a while.

My biggest take away from the conference is simply the diversity of the people interested in Eclipse and the diversity of things happening at Eclipse. There’s still a large chunk of it related to the RCP platform and the IDE we build on top of it. But there’s really cool things happening with the Science and IoT groups as well. And the OSGi lego train display was mesmerizing but really showed off OSGi’s roots in the industrial space.

The week started with the CDT Summit on Monday. We had a good representation from different companies who build tools based on the CDT. We had a mini demo camp where they had the opportunity to show off what they’re doing. There’s some really cool stuff happening. It’s great to see them trying to make the complex world of embedded development simpler to understand through some great visualizations. We also noticed a couple of areas where the different vendors are building the same functionality. Those are great opportunities to collaborate in the open and the CDT project is very welcoming to new things. Finally it was very interesting to see how all the vendors really rely on our managed build GUI to simplify compiler and other build settings for users. That’s something we’ll need to carry forward into the new Core Build system (which I still need to blog about, stay tuned for that).

On Tuesday, I had my talk where I showed off Eclipse for embedded. It’s really a showcase of all the hard work we’ve done to simplify CDT for embedded development and to support open frameworks that users are using today, including Arduino, Qt, CMake, ESP8266, etc. It also shows why Eclipse is so important to us in the embedded world. IoT is a marketing buzzword, but it’s also an architecture that many of us have used in the past and which is growing thanks to accessible cloud platforms. These days, you need to program both your Arduino and your cloud service and Eclipse lets you do those things with a single IDE.

The rest of the week was spent chatting with my open source collegues, building relationships, getting a feel for the current state of the Eclipse IDE and where we need to go in the future. The Visual Studio Code keynote from Dirk Baeumer we very eye opening. I’ve been studying VS.Code for a few months trying to get a sense of what it’s appeal is and whether a desktop IDE based on a Web frontend is the new modern way of building IDEs. Now VS.Code isn’t an IDE, or at least it’s not as much an IDE as the Eclipse IDE is. We have a lot of tools that render different sorts of data visually in Eclipse and those high value things need to carry forward in any new world. But it’s food for thought and I’m going to invest some time to see what can be done there.

As Mike loves to say in his keynotes, Eclipse is many things. I think first and foremost, it’s a community. Technologies come and go, and individual people come and go, but there always seems to be a great energy when we come together. The task for us is to carry that energy forward into our day-to-day work and keep momentum going on all the great things we talked about. It’s not easy, but it’s why we need to be there.

It’s been a crazy week if you follow the ide-dev mailing list at Eclipse. We’ve had many posts over the years discussing our competitive relationship with IntelliJ and the depression that sets in when we try to figure out how to make Eclipse make better so people don’t hate on it so much and then how nothing changes.

This time, though,  sparked by what seemed to be an innocent post by Mickael Istria about yet another claim that IntelliJ has better content assist (which from what I’ve seen, it actually does). This time it sparked a huge conversation with many Eclipse contributors chiming in with their thoughts about where we are with the Eclipse IDE and what needs to be done to make things better. A great summary of the last few days has been captured in a German-language Jaxenter article.

The difference this time is that it’s actually sparked action. Mickael, Pascal Rapicault, and others have switched some of their focus on the low hanging user experience issues and are providing fixes for them. The community has been activated and I love seeing it.

Someone asked why the Architecture Council at Eclipse doesn’t step in and help guide some of this effort and after discussing it at our monthly call, we’ve decided to do just that. Dani Megert and I will revive the UI Guidelines effort and update the current set and extend it to more general user experience guidance. We’ll use the UI Best Practices group mailing list to hold public discussions to help with that. Everyone is welcome to participate. And I’m sure the ide-dev list will continue to be busy as contributors discuss implementation details.

Eclipse became the number one Java IDE with little marketing. Back in the 2000’s developers were hungry for a good Java IDE and since Eclipse was free and easy to set up (yes, unzipping the IDE wasn’t that bad an experience) and worked well, had great static analysis and refactoring, they fell in love with it.

Other IDEs have caught up and in certain areas passed Eclipse and, yes, IntelliJ has become more popular. It’s not because of marketing. Developers decide what they like to use by downloading it and trying it out. As long as we keep our web presence in shape that developers can find the IDE, especially the Java one, and then keep working to make it functionally the best IDE we can, we’ll be able to continue to serve the needs of developers for a long time.

Our best marketing comes from our users. That’s the same with all technology these days. I’d rather hear from someone who’s tried Docker Swarm than believe what the Docker people are telling me (for example). That’s how we got Eclipse to number one, and where we need to focus to keep the ball rolling. And as a contributor community, we’re working hard to get them something good to talk about.

It’s been many years since I’ve been to EclipseCon Europe. It hasn’t been from a lack of desire. There’s just been a few personal and business reasons that made it difficult. But this year, the road is clear and my talk, “Arduino, Qt, and Iot with the Eclipse C++ IDE” has been accepted as one of the early bird selections. I was really proud of that and can’t wait to get there.

This last year or so has been a very active one for me and the team here at QNX with our contributions to Eclipse. The Launch Bar, which proved popular with BlackBerry 10 developers, has been made more general and is now hosted at Eclipse for all projects to use. It greatly simplifies the launch and build experience, especially when dealing with remote machines.

We are actively working on support in CDT for Qt, which has proven popular with QNX customers and other embedded systems developers. The highlight is the addition of a QML editor which we will continue to add content assist and other features expected of good Eclipse editors. While these things are good for QNX users, we think these things will be good for all users of Eclipse and also support Qt on Windows, Mac, and Linux.

I have switched my personal focus on embedded real-time systems and working on making Eclipse and the CDT much easier for developers making software for those systems. My Arduino C++ IDE bridges the gap between professional embedded developers and the hobbyist working with Arduino boards. It’s a great exercise in providing a user experience that can satisfy both and I think we’re making strides there.

My talk will attempt to cover all of that. It’s a tall order, but I have a simple, yet somewhat contrived example that shows an Arduino board with sensors and lights talking to a BeagleBone board running QNX with a touchscreen showing status from the board. The BeagleBone then communicates with a MQTT server which is watched by a vertx.x Web server to show the same information on web page. All of that is built with Eclipse and the massive ecosystem we’ve built over the years. It’s a great showcase.

It should be a great time. It’ll be good to see a lot of my European friends I haven’t seen for years or have only met on mailing lists or who I’ve never met but have an interest in the CDT and other Eclipse IDE projects. We have a CDT summit planned for the Monday and I hope to see everyone there and share what we’re planning and to see what you’re interested in.

It will be a great week. And now I really can’t wait!

Back in October, I released the preview edition of the Arduino C++ IDE and the response has been fantastic. I had something like 50 bug reports and lots of questions on every forum imaginable. That great feedback gave me a lot of incentive to fix those bugs and get a release out based on the work we’ve done in CDT for the Eclipse Neon release. And that is now done and available on the Eclipse Marketplace.

What’s new in this release? Well, a name change for one. I wanted to highlight that this is an Eclipse CDT project effort, not necessarily an Arduino one, so I’ve renamed it to the “Eclipse C++ IDE for Arduino.” This fits in with our strategy moving forward of providing more vertical stack support for different platforms. Expect another marketplace entry for the Eclipse C++ IDE for Qt in the next release or two, for example.

But what matters to users is usability, of course. The main new feature in this release is the Arduino Download Manager available in the Help menu. It provides a dialog that guides you through download and install of Arduino Platforms and Libraries. The metadata provided by the Arduino community has been hugely beneficial in letting me build Arduino support into CDT in such a way that new boards and libraries can easily be added. And this new dialog is your gateway into that community.

I’ve also done a video as an introduction. It’s only 11 minutes but walks you through installation to having an Arduino sketch running on your board outputting to the Serial Console.

As always, I love to hear from users either through forums or bug reports, especially bug reports. I have things set up to quickly get fixes to users through it’s own p2 update site. Always try Help -> Check for Updates to get the latest.

I’ve been working on the Eclipse CDT project for a really long time now. It started in 2001 when I fell into an opportunity to pursue my dream to work on a C/C++ IDE and, in particular, coming from the modeling world with ObjecTime Developer and Rational Rose RT, create a C++ parser that can build up a model of user’s code. I have been extremely lucky do that and to represent my various employers over the years on the project and am very proud of what we in the community have built and continue to build in the CDT.

Over the last couple of years, I started to get curious about what our users were doing with CDT. One of the ironies of working on a C/C++ IDE written in Java, you actually don’t get to use C++ very much other than the odd hello world tests. So I started to get deeper into the world of embedded systems. It started with Arduino and the world of microcontrollers. These are amazing little devices that let you build systems that interact with the real world with inexpensive hardware that brings me back to my youth and the 8-bit processors of the day. And, of course, being the CDT guy, I started working on a plug-in for CDT that helped you program these little things while showing off CDT’s latest features, the Arduino C++ IDE.

I recently bought a Raspberry Pi 3 to take things up a notch. It’s a little powerhouse that’s really not much more expensive than an Arduino and I’m thinking it would make a great platform for robotics. I can imagine putting some ultrasonic sensors on the sides and a camera on top and doing some image processing so the robot can drive some motors and find it’s way around a room of obstacles. But the thought of doing such real-time processing using Linux made me gag. I work for a real-time operating system company and I guess I’m really believing in what we do and really should be using QNX for that.

Well that has me now deep into the world of creating a Board Support Package, BSP, that will let me run QNX on the Raspberry Pi 2 and 3. It’s been a blast and I’ve learned so much about the operating system I’ve been writing an IDE for all these years. And it’s about time. It’s a very different world and have even had to learn ARM assembly language.

Being the blogger that I am, I’ve decided to spend more time writing about that experience and to share it with developers working with QNX, or interested in what we do, or simply learning about real-time software development and maybe a little IoT. I’ll still blog about the Eclipse IDE pieces I’m working on and will share those with the Eclipse Planet. But if you want to follow along the QNX side too, I invite you to subscribe to my blog using the form on the main page.

It’s a new chapter for me. But it fits well with everything I’ve done over the years, doing what I can to help developers make better software with great tools but now also expanding that embedded systems and their run-times. I have some really cool projects, like my robot, that will help me focus on a specific group of developers who are also working on some really cool projects and I can’t wait to get started.