User talk:Jdev/Questions

RhinoScriptEngine - it's fair play or not?

I find out today, that there're embed script engine may be used, to reduce codesize. Example:

package lxx.test.js;

import robocode.AdvancedRobot;
import com.sun.script.javascript.RhinoScriptEngine;

import javax.script.ScriptException;
import javax.script.ScriptContext;
import javax.script.SimpleScriptContext;

/**sure
 * User: jdev
 * Date: 11.11.2009
 */
public class JSTest extends AdvancedRobot {

    public void run() {
        RhinoScriptEngine rse = new RhinoScriptEngine();
        try {
            ScriptContext ctx = new SimpleScriptContext();
            rse.eval("var a = 100;", ctx);
            Double i = (Double) ctx.getAttribute("a");
            ahead(i);
        } catch (ScriptException e) {
            e.printStackTrace();
        }
    }
}

so i can rewrite most part of my code on js and only call it it nanobot. but i don't sure, that it is fair. What do you think about it? --Jdev 16:37, 11 November 2009 (UTC)

I think it was generally agreed that using interpreted languages to bypass the codesize utility isn't exactly fair, so although you can put your bot in the rumble to see where it would score, it would be better if you didn't leave it there, because based on the amount of code you have, it probably isn't a nanobot anyways. Look at White Whale and Talk:White Whale for more discussion on this =) It's quite cool that there is an included script engine in Java, I didn't even know about it =) --Skilgannon 17:19, 11 November 2009 (UTC)

Why i so honest?=) I glad, that i give something new in java=) there're also interpreters for php python, as i know. And i'm sure that there're also engines for other languages. --Jdev 17:28, 11 November 2009 (UTC)

Aside from what Skilgannon said... I'm very doubtful it can be used to reduce codesize actually for the following reason: I'm 95% certain that Robocode does not let robots access packages that are not part of the core java standard, in particular, I'm pretty certain you can't access the com.sun package from inside robots, maybe not even the javax package. Nice trythough, hah. --Rednaxela 17:35, 11 November 2009 (UTC)

I check it before publishing - it works=) --Jdev 17:55, 11 November 2009 (UTC)

I'm running OpenJDK, which doesn't include Rhino. So I can't compile this bot, and any bot based on this would get 0 on my system =) --Skilgannon 19:15, 11 November 2009 (UTC)

Yes, you right=) I try to use

new ScriptEngineManager().getEngineByName("JavaScript")

, but "Preventing lxx.UltraMarine 1.0 from access (java.lang.RuntimePermission createClassLoader)" appears. So question is closed=) --Jdev 19:29, 11 November 2009 (UTC)

It's not possible to get around it by going the other way either:

   package jk;

   import robocode.AdvancedRobot;

   import javax.script.*;
   import java.util.*;


    public class JSTest extends AdvancedRobot {
   
       public void run() {
         ScriptEngineManager manager = new ScriptEngineManager();
         List <ScriptEngineFactory> l = manager.getEngineFactories();
         ScriptEngine engine = null;
         for(ScriptEngineFactory sef:l){
            engine = sef.getScriptEngine();
            System.out.println("Engine found: " + sef.getEngineName());
         }
      
      	
         try {
            Double i = (Double)engine.eval("var a = 100; return a;");
            ahead(i);
         } 
             catch (ScriptException e) {
               e.printStackTrace();
            }
      }
   }

throws

jk.JSTest: Exception: java.security.AccessControlException: Preventing jk.JSTest from access: (java.lang.RuntimePermission createClassLoader)
java.security.AccessControlException: Preventing jk.JSTest from access: (java.lang.RuntimePermission createClassLoader)
    at robocode.security.RobocodeSecurityManager.checkPermission(Unknown Source)
    at java.lang.SecurityManager.checkCreateClassLoader(SecurityManager.java:611)
    at java.lang.ClassLoader.<init>(ClassLoader.java:242)
    at org.mozilla.javascript.DefiningClassLoader.<init>(DefiningClassLoader.java:54)
    at org.mozilla.javascript.ContextFactory.createClassLoader(ContextFactory.java:352)
    at org.mozilla.javascript.Context.createClassLoader(Context.java:2262)
    at org.mozilla.javascript.SecurityController.createLoader(SecurityController.java:143)
    at org.mozilla.javascript.optimizer.Codegen.defineClass(Codegen.java:142)
    at org.mozilla.javascript.optimizer.Codegen.createScriptObject(Codegen.java:101)
    at org.mozilla.javascript.Context.compileImpl(Context.java:2409)
    at org.mozilla.javascript.Context.compileString(Context.java:1359)
    at org.mozilla.javascript.Context.compileString(Context.java:1348)
    at org.mozilla.javascript.Context.evaluateString(Context.java:1101)
    at com.sun.script.javascript.RhinoTopLevel.<init>(RhinoTopLevel.java:72)
    at com.sun.script.javascript.RhinoScriptEngine.<init>(RhinoScriptEngine.java:92)
    at com.sun.script.javascript.RhinoScriptEngineFactory.getScriptEngine(RhinoScriptEngineFactory.java:74)
    at jk.JSTest.run(JSTest.java:21)
    at robocode.peer.RobotPeer.run(Unknown Source)
    at java.lang.Thread.run(Thread.java:636)

--Skilgannon 19:59, 11 November 2009 (UTC)

The improved security manager is partly my fault, as I awhile ago demonstrated hackbots which staticly accessed the internal classes in robocode. I also took the route of showing I could access parts of the JDK which allowed web access (which I later tested by downloading a file from my server), this in turn caused FNL to beef up the security manager, which for the most part is for the best, as running one of the built in script engines in your bot could allow it to run unsigned or hazardous code which could get around the security manager. --Chase 20:42, 11 November 2009 (UTC)

---

What of fire situation attributes (like lateral velocity, distance, near wall etc.) you use for segmentation you data?

I understand, that it may be "professional secret", but if any of top bot authors share this info - it will be cool=) Thank you=) --Jdev 10:32, 19 February 2010 (UTC)