A work around for Linux users
 

I understand that Netbeans is available for Linux - and that it works swell for the robot programming. However, after learning that one can simply FTP files to the cRIO - which is what Netbeans does if I remember correctly - would it be possible to do the whole 9 yards through terminal? What I mean is:

1. writing the source code through VIM or another text editor

2. compiling the code (I'm not sure how far this can go due to my lack in knowledge with the WPILIB API releases and what Netbeans does exactly when it compiles the source code and creates the images)

3. FTP'ing the code to the cRIO.

If anyone could help explain the dirty details of what goes on in 2 and 3 I would be much obliged. Thanks awesome robotics community!

Re: A work around for Linux users
 

compiling in a terminal is really easy. for c++ programs using g++ and its arguments correctly takes care of everything.

This command compiles and links the code files
"thing.cpp" and "main.cpp" together into the executable program called
"myProgram".

other things to worry about are libraries

-I : Sets the path to the include files.
-L : Sets the path to the libraries.
-l : Use this library (eg. -lm to use libmath.so, -lpthread to use libpthread.so)

You can have multiple -I, -L and -l entries.
So, your final command should look like this:
info about libraries can be found with the pkgconfig command.

Re: A work around for Linux users
 

Sure it's possible, but why give up powerful tools like autocomplete, visible javadoc, Go to Source, tabs of code, quick access to the FIRST libraries, etc.? Some old time programmers consider those a crutch, but they're actually just wasting time doing things the slow way. Yes, I know some people think the command line makes you look cool, and it's probably a good learning exercise to make this happen. I still ask, why?

Re: A work around for Linux users
 

I have to agree with frasnow - Netbeans isn't a bug we have to "work around"! That said, you asked a fair question, and it deserves an answer.

Yes, it's absolutely possible. Start by downloading the Netbeans modules for FRC and extracting them. Everything you need to know is in there, you just have to find it.

To compile the code, you probably need to use Ant. This is what Netbeans uses under the hood, and all of the build processes are already written as Ant scripts. The goldmine is in FRCNetbeansUpdateV3077/edu-wpi-first-squawksdk/netbeans/modules/edu-wpi-first-squawksdk/ant.

As you said, Netbeans just FTPs the code to the cRIO. Basic details are on FIRSTForge. There's an Ant script that does the deploy, too, so that might be even easier than using FTP by itself. But we weren't asking about easy, were we? We're in this to learn... so hack on! :)

Re: A work around for Linux users
 

theNerd did say he was using Vim -- plenty of plugins exist for autocompletion, going to source, etc., and tabbing comes built in :P

Vim can be configured to do all the NetBeans magic, and in a fraction of the time it takes to load NetBeans. But that doesn't mean it is easy, or that it makes development easier than NetBeans.

As StevenB notes, for Java we are already supplied with the build scripts (.xml files) -- we just have to use `ant` to properly. Incidentally, the build scripts are rather complicated. A mentor on my team created a visualization to describe the control flow (explained further here.) But you can also get a clue as to the fields from the .xml build scripts that are being invoked, and the order of their usage, by looking at NetBeans output when you Build your code. Brief statements, such as "flashapp:," "deploy:," etc. are printed to stdout as `ant` runs the .xml build scripts.

Also, to clarify, it's not the source code itself that you would FTP to the robot -- it's a .jar file generated from the `ant` build scripts that resides in the `suite` folder of your NetBeans project.

Re: A work around for Linux users
 

Well, it seems this was 100 times easier than I thought it was!

For Java:

1. Go to the root folder of your NetBeans project, where you should see a "build.xml"
2. in the console, simply type `ant deploy` without the quotes

It's that easy! At least I think so; I need to try it in the lab on Monday. But it appears to be giving me the EXACT same output that the stdout console of NetBeans does after I tell it to Build the project!

Re: A work around for Linux users
 

Well, for the "old timer" Linux community command line isn't just something that makes one look cool. GUI tends to a). take up loads of processing power that can be spent in better places. b). restrict the user command wise c). make things more complicated then it really is. Terminal (or command prompt for you Windowers) has proven to be extremely powerful. Granted it does take knowledge to use - that is it doesn't hold the users hand, but instead requires the user to have knowledge of his or her system, terminal allows the user to hold way more power over his/her computer than any GUI system. (There are tons of sites you could go to for this argument). For example in Linux when I install a program I can tell the computer EXACTLY how I want it to be set up, download it without going through a web-browser, where it install it, what to include and discard, how I want it to interact with other programs, and much much more. I can do all of this simply by typing in a line that is <20 characters long and wait less than 1 minute to install (including very large programs). On the other hand with Windows you have to download an installer, excute the installer, click a million times, wait forever and you still have very little control over the process.

As far as the IDE, its all preference. For most Netbeans and Eclipse are great, and along many lines it is. However, for Linux, we have what's called VIM. This is a SUPERPOWERFUL text editor that gives the programmer tons and tons of options and so forth. Personally I prefer to work with VIM more than Netbeans because my hands never have to leave the keyboard, and what would take simply a click and a drag now takes two keystrokes. VIM does have scripts for autocomplete and so forth which can put it along with Netbeans.

Now, I am sure that there are tons of valid points for both sides. However, that is not the point of this thread. Therefore, I must politely ask if we can stick to the question which is not why would we do it but can we?. Thanks.

Re: A work around for Linux users
 

Could you send me the know how on how to do this? I've been trying to get my hands on how to do auto completion for any code (mainly c++ c and java), going to source, and possibly an equivalent to that error checking thing that Netbeans does. :D

Re: A work around for Linux users
 

Are you referring to "the console" as the terminal/command prompt (I'm assuming the task is being completed on a Linux/Unix based system)?

Re: A work around for Linux users
 

Haha! You have no idea how happy I am to have found a c++ person who knows about libraries :D. I used to be a Java programmer - still am - but now I would like to make c++ my core language seen that I'm going to need it a ton in college. Could you send me links to resources that greatly aided you in learning c++? and could I private message you with questions as I go through my learning curve?

Re: A work around for Linux users
 

For good autocompletion:
http://www.vim.org/scripts/script.php?script_id=2540

For going to source:
http://www.vim.org/scripts/script.php?script_id=273

For more fancy IDE-style features for Vim (but I have not gotten this to work well for me):
http://eclim.org/

I have not yet found a good preprocessor to find errors before they happen in C++/Java, although I do have one for Python called python.vim.

Re: A work around for Linux users
 

Yes.

Re: A work around for Linux users
 

sure you can PM me all you like. for the most part i learned by googling what i needed at the time. Lots of trial and error. the only specific resource i recommend is this http://www.amazon.com/C-Pocket-Refer...2730753&sr=8-3 it's purely an outline of every command and bit of syntax, no tutorials. its for when you remember your supposed to use something, but don't remember how to use it, or you know this command exists in java, and want to see how to use the c++ equivalent. c++ isn't very hard to learn especially if your coming from a different programming language.

Re: A work around for Linux users
 

I put this together quickly to see what a terminal-based FRC IDE would look like. It's Vim and ant in tmux.

http://i42.tinypic.com/wjfa7b.png

Vim is running NERDtree on the left and the bottom window is zsh running 'ant deploy'.

Re: A work around for Linux users
 

Wow! I like it! Would you guys happen to know where the wpilib is installed on a unix based system? ..... specifically Ubuntu

Re: A work around for Linux users
 

The biggest hurdle for Linux users is the FRC Driver Station. Sure, you can definitely program on any OS, but to control the robot itself... I faintly recall someone working on a portable, Python version of the driver station (barebones).

As for IDE, I'm still a GUI fan (I have an interesting aversion to vim). Nevertheless, I like my IDEs light - I use Geany for the majority of my code editing. (For Windows users, this is an amazing counterpart to Notepad++!)

I'm not sure how C/C++ can be compiled on Linux, simply because what you compile might not be compatible with the cRIO. When you compile something, you are usually compiling it for the current system. Most compilers compile for x86, which I'm 99% sure isn't the cRIO's processor! :P

If you want to, you can find the cRIO's processor target, and then build the GCC cross compiler for that particular processor target. (I have a few BASH scripts to do that - if you're interested in attempting this, free free to ask) Even then, you will also need the FRC specific headers to make things work.

It's hard, but it's possible!

EDIT: Based on the screenshot found here (my team programs in Java, not C/C++), it looks like the processor is a MPC5200 processor or similar. (This one is based on a PowerPC CPU core.) Happy hacking! :)

Re: A work around for Linux users
 

I'm surprised nobody has brought this up yet: UCPP by nikitakit is a decent way to build on Linux or Mac.

Last year I used a custom makefile to compile C++ code for the robot, but it was incompatible with this year's version of WPILib, so I switched to UCPP. Now I can program, compile, and deploy from emacs.

Re: A work around for Linux users
 

I don't have Netbeans installed right now, but my best guess is ~/.netbeans/plugins or something like that. You don't need root to install the plugin, so it's got to be somewhere in your home directory. If you just need the files, you can download them from FIRSTForge and unzip the archive yourself.

PS, locate is your friend.

Re: A work around for Linux users
 

I believe it's somewhere in ~/sunspotfrcsdk.

Re: A work around for Linux users
 

It'd be nice to be able to do all FRC programming tasks in Linux. Unfortunately, the LabVIEW-based Driver's Station, cRio Imaging Tool, and others make that difficult.

I know someone was working on a Driver's Station without these restrictions. What about the others? Could the imaging tool's functionality be reimplemented in some cross-platform way?

Re: A work around for Linux users
 

Earlier this week, we reported how the Free Agent range had difficulty using the Linux operating system due to the power management system.
A Seagate diskspinner called Nathan Papadopulos said that all Seagate and Maxtor branded external storage drives feature a power management that places the drive into a sleep mode after 15 minutes of inactivity.
::ouch::

Re: A work around for Linux users
 

With the Seagate utilities you can change the relevant settings.

Otherwise Vixie cron up a job to write or touch a file on the mounted volume.

You can also change the threshold of the write cache to flush more frequently or less frequently (in Linux you can delay the writes for 24 hours I do it all the time, just remember if you don't flush before you loose power your data is gone). Flush more frequently you keep your data and keep the drive awake (especially if you use a journaling partition). Flush less frequently you don't care if the drive sleeps, but you might loose your data.

Also, the problem is not confined to Linux. The power management on the Seagate Free Agents is especially aggressive and can shorten the drive life even in Windows. I'd recommened tinkering with it if you leave the drive connected for long periods of time.

If you need more assistance on how to do this please let me know.

Re: A work around for Linux users
 

For just the build environment you could create a build environment in Windows you RDP to and drop your source on through a network share.

All you need is a real license of Windows XP Professional, if you use XP Home you can use VNC.

You could also put the whole thing in a VMWare, Xen or KVM virtual machine and then don't even need more harware (haven't tried this in a while but it should work).

I know my team does most of it's development in Eclipse with Java on Linux and Mac OSX. They tried to port the driver's station with some success. However, even if you create that code I'm not convinced it's entirely legal for competition use without specific approval.

I can guarentee it isn't legal for competition use, I'm not sure where the rule is, but, on the inspection checklist they check whether or not the voltage shows up in the driver station. If you are using something other than the driverstation, they will definitely have a problem with it, not to mention if the FTA has to troubleshoot your connection on the field. That said, I'm trying to recreate a Driver Station from looking at packet captures, and might test it at an offseason.
- Oliver