View Single Post
  #7   Spotlight this post!  
Unread 24-06-2013, 11:27
rbmj rbmj is offline
Registered User
FRC #0612 (Chantilly Robotics)
Team Role: Alumni
 
Join Date: Apr 2011
Rookie Year: 2011
Location: DC Area/Fairfax County
Posts: 192
rbmj is a jewel in the roughrbmj is a jewel in the roughrbmj is a jewel in the rough
Re: What is expected of the core libraries?

My issues with WPILib are documented in other places on this forum, but they primarily are not with the library itself, but with its development process.

For the record, I use C++.

I may be alone in saying that I find reading, understanding, and making changes to WPILib to be relatively easy. I've never had real issues with it.

I do agree that there is some bloat, however, at least with the C++ version I believe that the linker will only include the object files that are necessary to resolve any missing symbols in the library and their dependencies, so I don't think that "stripping down" WPILib offers any real-world benefit - just don't use what you don't need.

However, I do think that WPILib development should be a community effort rather than a centralized effort. I think that teams should be encouraged to contribute changes and code back to the WPILib project to be integrated and used by all teams. I'm not saying that it should accept everyone's code - it would take a good core team of maintainers to weigh the pros and cons of integrating each change - but even levels of openness such as having a public patch submission and discussion mailing list and allowing anonymous checkouts would be a huge step in the right direction.

One of the biggest issues with this sort of approach would be that the different language versions of the library might diverge. However, a good maintenance team could work around this.

I think it would be more in line with the purpose of FRC to open up development of the core libraries to the teams.

Also, with regards to the feature creep of the core libraries, there's nothing stopping you from compiling real-world libraries for the cRIO and linking them into your program. Since vxWorks is (partially) POSIX compatible the porting usually isn't *inordinately* difficult for small libraries. This seems a better solution from the perspective of education than using specialized FRC only libraries for absolutely everything. I see the most potential for this sort of use in network communication, but other areas can benefit as well.
__________________
FRC 612 '12
USNA '16