Follow Eclipse's lead: while-typing code analysis (e.g. for struct member display); refactoring,

[pblase]

One of the more valuable tools within LabWindows is the ability of the editor to fill in struct elements given the struct name. I also work with Eclipse-based tools for embedded systems work, and it has a similar ability. Unfortunately, whereas Eclipse dynamically analyzes the code as it is written, and can provide stuct elements (and other variable information) as soon as the programmer types it in, LabWindows cannot provide this information until after the code has been successfully compiled. As this may or may not happen for some time after the file has been started, or major changes begun, it is almost useless.

Another useful tool that Eclipse offers that LabWindows does not is the ability to refactor variables and other symbols. Again, Eclipse dynamically tracks the code as it is written, not requiring compilation; refactoring is similar to global replace, except that it tracks the 'C' usage of the symbol and only changes the proper usage. So, for instance, if I use a local variable named "X1" in three different subroutines, and refactor "X1" to "X2" in one of them, only the variable in the particular routine gets changed.It works with any C symbol, including routine names, global and static variables, and structures.

As a matter of fact, I would encourage NI to look into the possiblity of basing LabWindows on the Eclipse platform, as Atmel did in replacing its proprietary Studio software with an Eclipsed-based version. This would enable users to take advantage of a large number of available Eclipse tools, such as source-code management.

[pblase]

One of the more valuable tools within LabWindows is the ability of the editor to fill in struct elements given the struct name. I also work with Eclipse-based tools for embedded systems work, and it has a similar ability. Unfortunately, whereas Eclipse dynamically analyzes the code as it is written, and can provide stuct elements (and other variable information) as soon as the programmer types it in, LabWindows cannot provide this information until after the code has been successfully compiled. As this may or may not happen for some time after the file has been started, or major changes begun, it is almost useless.

Another useful tool that Eclipse offers that LabWindows does not is the ability to refactor variables and other symbols. Again, Eclipse dynamically tracks the code as it is written, not requiring compilation; refactoring is similar to global replace, except that it tracks the 'C' usage of the symbol and only changes the proper usage. So, for instance, if I use a local variable named "X1" in three different subroutines, and refactor "X1" to "X2" in one of them, only the variable in the particular routine gets changed.It works with any C symbol, including routine names, global and static variables, and structures.

As a matter of fact, I would encourage NI to look into the possiblity of basing LabWindows on the Eclipse platform, as Atmel did in replacing its proprietary Studio software with an Eclipsed-based version. This would enable users to take advantage of a large number of available Eclipse tools, such as source-code management.

[Wolfgang]

---

@pblase wrote:

As a matter of fact, I would encourage NI to look into the possiblity of basing LabWindows on the Eclipse platform...

---

Of course I'd be happy to see improvements in the IDE.

However I am not so sure if I like the idea of basing it on the Eclipse platform because it is another huge installation and I am not convinced that every software installation needs to grow by adding yet another framework.

[Wolfgang]

As a matter of fact, I would encourage NI to look into the possiblity of basing LabWindows on the Eclipse platform...

[pblase]

It's just that so many tools are available for eclipse. And, it's no larger than LabWindows is already, anyways.

I've been thinking about software engineering, and comparing it to other engineering fields. The mistake that software engineering has made is in making a fundamental mistake about where the EDA tools should be applied. In mechanical, civil, and electronics engineering the emphasis is on modeling the thing being constructed before implementation, whether SPICE and VHDL simulations for electonics engineers or FEA analysis for mechanical and civil. Once the device is completely simulated and the engineer is confident in the design, it is handed over to technicians for implementation.

In computer science, however, we have - in effect - totally automated the implementation; our emphasis on compilers and languages is rather like putting dimensional tolerancing into the CNC machine instead of into the CAD system. Our emphasis should be on the editors and the IDE. I really like the LabWindows/LabView ability to exercise subroutines independently of the rest of the program. What is needed, though, is further emphasis on these tools and helping the programmers to avoid mistakes. I complained in another post about the possibility of a recursion in my software, what with a large number of set-up subroutines and setting up controls through calling their callback routines; sure enough I found one that was crashing the program. Took me the better part of a day to track it down too.

Given the potential disasters that can be caused by such things, not to mention the dire warnings found in the documentation for things like multi-threading ("you must call ReleaseThreadlock again after each call to ObtainThreadlock") tools in the editors to help track and catch mistakes would be extremely helpful. For instance, it should really not be too difficult to put a comment or macro in to note in the code the importance of calling subroutine of type Y every time that you call one of type X (perhaps using a facility similar to the" ///FN", etc, documentation system) and have the editor track them. The important thing is that this stuff needs to work in the background, before the code is ever submitted to a compiler.

I only suggest Eclipse here because it 1) already exists, 2) has such a large installed base, and 3) is relatively easy to add capabilities to.

[KavehV]

I was going to put this in as a feature request until I found this.  I strongly encourage this idea; in fact I mentioned it to the CVI team last year at NI week.  TI is a great example of a company that's moved their IDE totally into Eclipse for embedded platforms (code composer now installs as an eclipse plugin!).  It's really wonderful because you get one extremely configurable IDE that can be used to develop all your code from C to Java to Python.

I think the advantage for NI in switching to eclipse is that the IDE and UI is mostly taken care of out of the box.  They'd be able to focus less on IDE development and more on the backend.  The eclipse platform also makes it easier for NI to push transperent updates to the IDE.  Also, there are some really excellent tools (as you mentioned) on the eclipse platform like Subclipse (for complete subversion version control integration), and all that really comes for free just for basing your IDE on eclipse.

Please count my vote for switching to an Eclipse-based IDE.