Simple Motor Calculator for Linux/OS X

[Andrew Schreiber]

So some updates and questions for your Software Bug - I'm going through and have added some better command line parsing, so I'll release that as soon as I nail down this next issue.

Getting the name of a motor wrong - When this happens do you think a best guess and run approach would be preferred to a "Did you mean CIM" and exit approach (similar to git's cli when you screw up a command)? I'm working on getting some fuzzy string matching working in and was curious what would be preferred. If it were a long running command or one with side effects I can see the benefit of the git "suggest and exit" approach. But being as it takes very little time to run and changes nothing except standard out I think the "best guess" approach might work fine.

Sorry this took so long, turns out build season is time consuming.

[SoftwareBug2.0]

My general feeling is that if there's any chance of the program being wrong it shouldn't try to run based on a guess. So for example, running with the 'closest' name to a user argument might be problematic because if they typed in something that there wasn't data for you might get wrong data out. But on the other hand, a case-insensitive matching wouldn't have that problem since it's reasonable to assume that there won't be a new motor whose name differs only in capitalization.

[Andrew Schreiber]

Originally Posted by SoftwareBug2.0

My general feeling is that if there's any chance of the program being wrong it shouldn't try to run based on a guess. So for example, running with the 'closest' name to a user argument might be problematic because if they typed in something that there wasn't data for you might get wrong data out. But on the other hand, a case-insensitive matching wouldn't have that problem since it's reasonable to assume that there won't be a new motor whose name differs only in capitalization.

Ok, then I'll go with the git cli model of Exit and say "hey maybe you meant this"

And yes, the search will be case insensitive, that was an oversight... still new to Go.

[marshall]

Originally Posted by Andrew Schreiber

Ok, then I'll go with the git cli model of Exit and say "hey maybe you meant this"

And yes, the search will be case insensitive, that was an oversight... still new to Go.

Fair warning with Go if you use any external libraries and don't explicitly pull them in and instead use the functionality to just have Go update them via Git.. you can end up in a situation where your program breaks because the external library is broken. That being said, I do enjoy me some Go programming... anyone want to port it to the RoboRIO?

[Andrew Schreiber]

Originally Posted by marshall

Fair warning with Go if you use any external libraries and don't explicitly pull them in and instead use the functionality to just have Go update them via Git.. you can end up in a situation where your program breaks because the external library is broken. That being said, I do enjoy me some Go programming... anyone want to port it to the RoboRIO?

Yeah, I've found that version locking dependencies isn't quite as robust as I've come to expect from things like ruby gems and npm.

Also fair warning about cross compiling - it's fine with plain old go code, but the second you start dealing with cgo your life gets complicated quick.

I too would welcome a WPILib port of Go, but I don't know if it really gives you much benefit over the other languages out there. Python/Lua are nice because they are a very different type of language.