Week 2

This week was the second week of our two week project designed to introduce us to our summer-long projects. My two week project consisted, very broadly, of sandboxing the process of running the domain expert Jython scripts submittied via the edit test code interface.

Sandboxing the running process is important since the compilation and running of the Jython scripts will soon be allocated to a server. Due to the fact that the server will be headless, the first step of the sandboxing process was to decouple the compiling and running of the Jython scripts from the edit test code user interface. This decoupling process intruduced me to the code involved in the edit code test interface as well as the code used to run and test the Jython scripts.

The next step in the sandboxing phase was to include an API and a class loader so that those who wish to submit scripts have a variety of methods to choose from in order to access various parts of the worlds for which they are writing the scripts. The class loader allows the user access only to the API and AST (so that they are able to access various parts of the world for which they are writing the script). An important aspect of the class loader is that it does not allow the user access to various Java libraries. Doing so could be catastrophic. The user is only allowed access to the AST and the API.

The next step was to create a new thread for the running of the Jython script and its testing on a given world. The new thread was necessary since the process of running the script will be allocated to the server, and therefore, a new thread will be needed for the networking invloved in sending information to the server.

Next, I had to figure out how to put a timeout on the script. This was a particuarly hard task, and I spent more time on it than I would like to admit, but I was ultimately able to figure it out.

The timeout is important because we would like the running process to stop if the script is, for whatever reason, taking a long time to finish. I implemented a ten-second timeout, but I feel even that may be a bit long.

I have also been able to work on some apsects of the edit code test interface, including a future GUI and a more robust API.

Next week, my work will be dedicated to working on creating a new user interface, and I am very excited for this. I do not have much experience in user interfaces, but, as with the previous two weeks, I look forward to learning new things. Currently, I am leaning towards a more lean interface, one that can actually provide a bit more feedback than the current interface. If at all possible, I would like to output the actual command line output to the interface when the user runs their script. I think this feature would be very helpful, especially with scripts that may be buggy.

As I mentioned earlier, I would also like to provide a more robust API. The current API does not do much in the way of making the script writer's job easier. At this point, the script writer would have to know pretty much exacly how to access various parts of the AST, such as the constrcuts. I think improving upon the API would greatly benefit script writers. I would like to provide methods for easy access to various constructs and statements for the worlds. I also think it would be beneficial to have some sort of API documentation that can be linked from the edit test code interface.

Overall, these past two weeks have gone by very quickly, and I jhave learned a lot in the process. I greatly look forward to next week, where I will begin to design the new edit test code interface.