The latest CDT offering has just been released. Today CDT is generally acknowledged as the de-facto C/C++ IDE in the industry. The extensive code navigation features are amongst the highlights that the framework has to offer. Not wanting to rest on their laurels, work is already well underway on the next release, CDT 6.1. In a recent blog article, CDT lead Doug Shaefer highlights that there will be a big focus on fixing up the scanner discovery mechanism.
Scanner discovery mechanism is the feature in CDT that supports code navigation by automatically discovering build information such as include paths and build macros. The build information is normally retrieved in one of two ways. The first involves running a fixed gcc command to query the known include paths and macros. The second way involves parsing the build output to identify relevant build information.
This is a great feature that enhances code navigation, and in particular creates a very good start up impression. It means users can navigate to code libraries even before they build a project. In our experience this has been a very desirable thing, particularly when our clients provide specialist libraries such as peripheral driver code. Scanner discovery means their customers can easily navigate the code and link to header files to browse the api for the peripherals. However, as it stands today the scanner discovery mechanism is both architecturally flawed and buggy. We have spent significant time fixing it up for clients in order to give the desired experience. However, there’s only so many times we can patch it up before wanting to help fix it up once and for all.
As a result we will be working with the CDT team to help fix scanner discovery for the next release. In fact we will be part of the ‘rag-tag group’ Doug refers to in his blog. The first step was to have an initial kick-off meeting, followed by all capturing the problem and trying to define the architecture. This has been done using the CDT wiki. While one or two CDT committers have put down details of what the high-level architecture should be, we have added our thoughts on the specific issues we have seen with the implementation and low-level architecture based on our experiences.
The next step will be the interesting one as we work out how best to proceed. In the meantime, Kichwa Coders will also be working on some low-hanging fruit by working on scanner-related bug fixes such as using variables in dialog boxes. All in all, it will be an interesting experience working on a relatively far-reaching feature with several other developers spread out across the globe, yet ultimately very rewarding to be part of fixing up this key feature of the CDT. In particular for us, it means yet another feature our clients can take for granted and keep focusing on their core competences.
In the Electronic Design Automation (EDA) field it is widely acknowledged that the state of the software has not kept up with the rapid advance of the hardware. At the 2009 Design Automation Conference (DAC) in his keynote speech “The Tides of EDA“, Albert Sangiovanni-Vincentelli, co-founder of Cadence and Synopsys, said “At the system level, we should look closely at embedded-software design as a great opportunity to innovate…For the past six years, keynotes at DAC pointed out the great importance of software for electronics, even for the semiconductor industry…There is consensus about the need to change the way we design software in general…”
So what is it about software tool development that has meant the tools are not up to scratch ? Here are four challenges developers have to contend with.
1. Tool complexity – the tools do a lot, whether it is dealing with routing algorithms or enabling one to build a system-on-a-chip, there is a great deal of functionality to contend with. All this has to be handled while ensuring the tool remains fast, robust and easy-to-use.
2. Short timescales and limited resources – as ever time is of the essence as the rewards are huge for being first to market. However the current economic crisis makes things worse as it means companies have to work out how to deliver in short timescales with limited resources. This often leads to compromises being made which detract from the tools.
3. Sophisticated users – today’s users are increasingly sophisticated. They have specific notions of what tools should look like and how they should work. Often embedded tools suffer from usability issues as they have not spent enough effort focusing on the end-users needs and optimizing key task flows
4. Integration Demands – an extra burden is put on developers to get integration right. Today tools cannot exist in a vacuum and must play nicely with the existing systems out there, whether they are build systems, revision control or text editors. Dealing with integration issues complicates the lives of tool developers as these requirements often arise further down the project life cycle and require a high level of adaptability.
The planning for this year’s Eclipse Summit in Ludwigsburg, Germany is underway.
We’ve put in a submission for a short talk to present the work we did at Diamond Light Source. You can view the abstract here. The talk will focus on taking Eclipse into a new scientific domain, with the potential of forming the basis of an open source platform for synchrotron data acquisition. We envisage this would meet the criteria of getting people excited and engaged at the potential for Eclipse to conquer this new territory. Whether the committee agrees with this remains to be seen. The level of talks at Eclipse conferences and summits is always very high so it would be great to make the cut. However competition is stiff and at the time of writing there were 152 submissions to contend with. The talks will be chosen by August 25th, so we await the decision with bated breath…
Back in March, Kichwa Coders was invited to participate in a Buckinghamshire Education Business Partnership (BEBP) at the Great Marlow School.
Kichwa Coders was asked by BEBP if we could provide a mentor for an Enterprise Day. I volunteered to attend the 18th of March session for year 10 students (14-15 years old). The day focussed on a brief prepared by Urban Media looking to get input from the students on a new Family Entertainment Centre to be located in South Bucks.
An Enterprise Day is a day for the students to experiment with some real life business problems. The school or a company from the community puts forward a real life challenge to the students, and under the guidance of a group of mentors they come up with a solution and then present the results back to the mentors and their peers.
In the case of the Urban Media challenge, the class of approximately 200 year 10 students were divided up into teams of 8 students each. The teams had about 4 hours to read the brief, and complete a set of tasks before finally presenting their results to a couple of the other teams. The tasks were:
- coming up with a name for the family entertainment centre,
- create an advertising campaign which included 2 posters, a radio ad script and a storyboard for a TV ad,
- develop two “zones” in the centre, a learning zone and a gaming zone, the result of which should be a diagram for the zone detailing the activities and look and feel of the zone
- come up with the concept for two additional zones and provide the same material as above
- create a presentation to explain to Urban Media, the mentors and fellow students what the team came up with.
As you can see, the students had a huge amount of work to do. I was mentoring three of the teams providing them with guidance and encouragement on these tasks. Some of the students really impressed me with the level of dedication to this task, clearly demonstrating a level of maturity ahead of their age. The result was that all the teams did a very good job, and even though I thought it was a very short time to complete so many tasks most of the teams did.
The Enterprise Days are very good days for everybody involved. The students have an opportunity to complete some real world experience, the mentors get invigorated by the unbounded energy of teenagers, and the sponsoring company gets invaluable ideas from brainstorming with so many people. I am really looking forward to next year’s round of BEBP Enterprise Days.
Moving an existing application to a new platform can be a huge undertaking, often requiring re-writing large portions of the code base to work in the new framework. However, moving a legacy AWT/Swing application to the Eclipse platform does not mean having to abandon the existing GUIs to take advantage of what Eclipse has to offer.
Take Diamond Light Source’s GUI for Data Acquisition (GDA) as an example.
Diamond’s GDA application was originally developed as a monolithic application using Swing for rendering GUIs. As the number of users and developers grew, Diamond decided that Eclipse could quickly provide new features, scalability and improved component interoperability. However, there was a problem with transitioning to a new platform: a large investment had already been made in Swing.
The Eclipse developers had already solved this problem though. They created an SWT_AWT bridge that allows a Swing/AWT component to be added as a component to an SWT composite. This bridge significantly simplified how Diamond was able to transition, by reusing existing Swing components, but still taking advantage of the new capabilities that Eclipse/SWT has to offer. A prime example of a feature that Diamond GDA users and developers desired was more control over the layout of the GUI. By embedding the existing Swing components into individual Eclipse views in a short period of time all the previously mostly static components were draggable, dockable and closeable.
The SWT_AWT bridge lowered the barriers that Diamond had to transitioning GDA to the Eclipse platform. Instead of having to re-write all the necessary component in the new framework, Diamond developers were able to take advantage of Eclipse very quickly and roll out those improvements to the users in record time.
For the technical details on how to use the bridge, see the excellent article by Gordon Hirsch http://www.eclipse.org/articles/article.php?file=Article-Swing-SWT-Integration/index.html. Unfortunately, integrating the SWT_AWT bridge has suffered from some headaches when using Xlib (as used on Linux/GTK systems). Some of the Xlib APIs are inherently not thread safe in their design. For example, XSetErrorHandler, which returns the old error handler when setting a new one. Without some application level locking, it is easy to get the error handler into a state when the currently installed error handler is incorrect. When using the SWT_AWT bridge, two separate threads are both accessing Xlib APIs. This can cause the AWT thread to have a stack overflow. The underlying problem will remain due to the Xlib APIs, however, SWT and AWT can avoid using XSetErrorHandler, and therefore avoid this issue. These issues are discussed more fully in Eclipse Bug 171432. The AWT issue has already been fixed in JDK7 build 60, but the fix has not yet been back ported to JDK 6. See Bug and Revision with fix.