RoboRumble/GUIDevelopment

I have modified the RoboRumbleAtHome?.java file, and no others, to provide the beginning of a basic GUI. However, in order to keep the modifications to only this file, it doesn't do anything graphical yet. I hooked system.out and display it in a debug window on a desktop pane. This is unfortunately based on alpha 2, during the few hours this took me to do alpha 3 was released. I'm going to try and apply the alpha 3 updates manually I guess, in the mean time I will upload and link the alpha 2 version. Please excuse the slopiness and lack of creativity in the code, I am currently suffering the after-effects of a mild concussion, and it shows in my work :p

Note that any updates to any other files aren't effected, only the RoboRumbleAtHome?.java file was modified, and that's all I'm uploading, if this file wasn't modified at all between versions, then we're in business already. You'll need to recompile the code with this new file in your home dir, however. For PEZ and the rest of you on 1.3 I have gone to some lengths to ensure 1.3 compatibility, however, there is one thing I feel is important to include that 1.3 does not support, thus you'll have to command the following line: robo.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); There may be more to comment, but I hope that's it. -- Kuuran

For alpha 3: [http://www.geocities.com/kuuranca/RoboRumbleAtHome.java] -- Kuuran

Last note (promise) this is just to get the ball rolling on a GUI and similar interfaces. I encourage anyone else who wants to make it useful to do so. -- Kuuran

For me I would get enough Java 1.3 compatibility if you make the gui optional. I can't see where a gui should be needed for this anyway. I just love the simpleness of just running the command and then forget about it. Is the GUI for setting parameters? If so, maybe a standalone app would be a better choice. This standalone app could also start the roborumble run and display the results and such if you like. -- PEZ

Cool. I'w add it to the deployment file. PEZ, is it working in your system? Also, I made a little change to make the Debug window resizable. Is there any way to make it scrollable? When the debug output is long, I can not read it :-( Also, it rises 3 warnings about an "ambiguous reference". Is it normal? -- Albert

It doesn't work all that well. Running it with Java 1.4.1 ends with a bus error. Using 1.3.1 spews out a lot of thread access errors. In both cases things got far enough for me to see the GUI. I can't see thee point of this GUI at all. Please make it a seperate app and keep the roborumble app as a console app. -- PEZ

The GUI is in my mind essentially for setting parameters, repeat running of leagues, and generally automating stuff that would otherwise require hacking at files or setting up a load of scripts for. As for the problems, it runs completely clean on my system, I'll start modifying it to actually be useful and somehow arrange with Albert so it can be developed seperately from the core systems. Let me know precisely what problems it causes? -- Kuuran

Since when did automation require a GUI? But if you like a GUI for setting parameters I can live with it. I still think it should be an app of its own, but as long as the GUI isn't required for running roborumble I will stop complaining. =) -- PEZ

It all runs fine (Alpha 4), i didn't check the downloads, as i didn't delete the bots from last time. However, the GUI doesn't scroll automatically, and doesn't let you scroll manually, so the only way to see things printed low down is the enlarge the window, and that can only be made as big as your desktop, which means the bottom is still unreadable. There is also a tiny typo, you have it downloading "missing bots list", and it isn't a list, it is the bots themselves, unless i'm much mistaken. I like the results being printed as it goes along. I'm not sure why it prints the results file after it says it's failed to upload it, and i couldn't see what happened after that because the window wasn't big enough. -- Tango

Yes, in all my lucidity I overlooked the scroll pane. That's already been fixed. What I want to know now is who wants to see a GUI as a standalone app that hooks into roborumble and who wants to see it integrates but with an 'off' flag? If the majority would rather have a standalone expansion app then I'll develop it like that and leave whoever wants it to get it. -- Kuuran

Does it might a lot of difference beyond the coding side of things? Isn't the difference pretty much invisible for the end user? -- Tango

I think it would be better if it is an standalone app. From RoboRumble/Testing2 it seems it causes some crashes even if hidden. Also, it will allow a simpler development because they will be loosely integrated, so changes can be made independently. In fact, this kind of modularity is something I had in mind when I started coding RoboRumble (note that different modules pass the parameters in files, not objects, so you could create a separated application for each one in minutes).

Also, I think it would be a good idea to control which part of the application is run (pe. if you are not connected to internet, you don't want to download bots). The gui would be a good way of controlling it. -- Albert

Indeed, I suspect I jumped the gun. Ok, then what I'll do is develop a seperate RoboRumbleAtHome?.java equivalent and maintain all of your classes for doing the actual work. When I was thinking over security implementations I was thinking we'd have a customization file anyway. For now let's focus on your pure-text version and I'll do the GUI privately, then release it when we have a working core. Need any help? -- Kuuran

Thanks for your offer. Right now I can cope with the client (right now is almost finished - for the moment - and the only missing part is the one to upload results, that is not tested), but someone will have to take care of the server (I have no idea about it). It would be great if you could colaborate. Also, if you develop a gui, don't keep it private, so we can stay coordinated. -- Albert

I'm happy to hear you are considering a standalone GUI. As a Unix dude I am very fond of command line tools. The standalone GUI app could manipulate the paremeters file and then either go via Runtime.exec() (which I tried, but lacked the knowledge to complete) or maybe some class-loader way to run the text-only rumble app. But just so you don't take a descision in this way on the wrong premises. The error I encountered in /Testing2 where it failed in a non-GUI environment I got with a pure non-gui alpha3, so it had nothing to do with Kuuran's GUI addon. Robocode itself assumes a GUI, wether this is fixable or not I don't know. -- PEZ

I'm back at work on this GUI idea and finding several uses for it. However, there is a small hangup I've found: the client thread would finish normal processing and just hang. I blew a great deal of time investigating this, and finally figured it out.

I considered forced termination, but just thinking about detecting /when/ to do it made me look for another route :P. Besides, when running another process through java it's difficult to force it's termination - you can, but it takes awhile and gives it a very long time to terminate gracefully. This is great if I'm force-terminating the RoboRumble process the GUI is using, this is godawful if it's exiting normally and I'm forcing it to terminate just to kill the process.

Eventually I realized that the system itself will force a process to exit with the equivalent of System.exit() when the class ends, but if I'm calling the process through java from another program, this doesn't happen (apparently).

So the problem is that the process isn't truly exit()ing. The solution is to put an explicit System.exit(0); at the end of your main() class in the RR client. If you could do this for me in the next release (whenever you have enough bugfixes to justify one) I'd greatly appreciate it :) -- Kuuran

Does disposing the window onWindowClosing? work? -- Kawigi

Nope. I even tried outright dispose()ing the window at the bottom of run(). Even a System.exit() in my app didn't do anything, all of my stuff would disappear, but the client processes would invisibly continue running. Adding the System.exit() to the bottom of my RR client fixed everything, however. Also, explicitly killing the process using Process.destroy() works after some time delay, but it's difficult to tell when the process has finished execution (and thus when to use it) since it doesn't signal in any way. -- Kuuran

When running the RR client standalone on my Mac it never give sback the command prompt. This is probably due to the same problem. Strange that it should need an explicit exit() though... -- PEZ

I'w add it to the client. -- Albert

Unfortunately my robocoding activities have been nonexistant lately, and I haven't exactly been fair in giving notice of that. Some of it was caused by an accident I had involving my head and a fast-moving car, but my robocoding had already gone south before that, so I can't use that as a complete excuse in good faith. Recently I've had time to go back and look at the GUI code I had written, and complete it. I'll submit it for the use of anyone who might be interested. The executable jar contains classes and source. It currently has the following issues or is lacking the following features that I'd like to add given time:

• When saving the edited properties file, Albert's comments are removed. For this reason I suggest maintaining a backup for reference if you need to check what a given field does.
• I'd like to set up a system where the above comments are read into a hash table or similar structure from a user-maintainable database and displayed in the properties editor, thus fixing the above problem.
• Currently I cap at one RR@Home thread at a time, though it was my intention to allow concurrent processes and the framework for this is entirely in place. However, concurrent file access can break the score files.
• I'd like to allow multiple RR@Home instances by allowing the user to attach different properties files and even robocode installs to each thread, but I haven't had the time to do this. (It would actually be pretty easy given some time)
• In the same vein as the above, I'd like to allow SMP machines to select which processor each thread runs on, but I'm not aware of java support for this.
• What was I thinking when I made that error dialog?!

-- Kuuran

The all-important [clicky]. -- Kuuran

I've gotten robocode to run on different processors in Windows by running one with java and one with javaw and setting the affinity of java to one processor and the affinity of javaw to the other. Not really the same thing you're wanting to do, but a hack that has the same result (of course, you have to run the program in two seperate instances). -- Kawigi

Though, if the OS is any smart about it it should learn quick enough to try to place two jvm instances on different CPUs, shouldn't it? Speaking as a totally non-SMP expert that is! =) -- PEZ