CorFlags.exe JetBrains.ReSharper.TaskRunner.exe /32BIT- /Force
public class Something
{
//use this
public Something(IUnityContainer container)
{
Container = container;
}
//or this
public IUnityContainer Container { get; set; }
}
Found here
Type type = typeof(Type); Type[] nonInheritedInterfaces = type.GetInterfaces().Where((ifc) => !ifc.IsAssignableFrom(type.BaseType)) .ToArray();*Yes, if you are still on 2.0 you could rewrite it to loop.
// initialize, just once per JVM please JarJarURLConnection.register(); new URL( "jar:jarjar:file:/C:/mylibs/Outer.jar^/Inner.jar!/tested/robots/Ahead.class" ).openStream();Or create and configure ClassLoader this way
// initialize, just once per JVM please
JarJarURLConnection.register();
new URLClassLoader(
new URL[]{new URL("jar:jarjar:file:/C:/mylibs/Outer.jar^/Inner.jar!/")}
).loadClass("tested.robots.Ahead");
If you need something more sophisticated or user friendly One-JAR is the solution I think.
My colleague at work mentioned that there is some puzzle where we have 33 holes in shape of cross and 32 bullets in all the holes but central. To move you should skip one bullet with it's neighbor into empty hole and remove the skipped one. The goal is to clean all but last bullet. He mentioned that it would be interesting to find solution with computer.
And we didn't knew the name of the game. Now it took me almost an hour to find it out for purpose of this article. So now when you know the name of the puzzle, you can easily find the solution on Internet. Actually quite interesting reading.
But I enjoyed brute force search for solution. Below is solution I found after few hours of coding and 6 minutes of intensive computing.
XXX XXX XXX XXX XXX XXX XX0 XX0 XXX XXX 0XX 0XX 0XX 0XX 0X0 0XX XXXXXXX XXXXXXX XX0XXXX 00XXXXX 0X00XXX 0X0X00X 0X0XX0X 0X0X00X XXX0XXX X00XXXX X0XXXXX X0XXXXX X0XXXXX X0XXXXX X0XXXXX X0XX0XX XXXXXXX XXXXXXX XXXXXXX XXXXXXX XXXXXXX XXXXXXX XXXXXXX XXXXXXX XXX XXX XXX XXX XXX XXX XXX XXX XXX XXX XXX XXX XXX XXX XXX XXX XX0 XX0 XX0 XX0 XX0 XX0 XX0 XX0 0XX 0XX 0XX 0XX 0XX 0XX 0XX 0XX 0X0X00X 0X0X00X 0X0X00X 0X0X000 0X0X000 0X0X000 XX0X000 00XX000 X0XXXXX X0XXXXX X0XXXXX X0XXXX0 X0XXXX0 X0XX0X0 00XX0X0 00XX0X0 XXXX0XX XXXXX00 XXX00X0 XXX00XX XXX0X00 XXX0000 0XX0000 0XX0000 XX0 XX0 XX0 XX0 XX0 XXX XXX XXX XXX XXX XXX XXX XXX XXX XXX XXX XX0 XX0 00X 00X 000 000 000 000 0XX 0XX 0XX 0XX 0X0 XX0 XX0 XX0 00XX000 00XX000 00XX000 00XX000 00XXX00 000XX00 00X0000 00X0000 00XX0X0 00XX0X0 00XX0X0 00XX0X0 00XX0X0 000X0X0 000X0X0 000X0X0 0XX0X00 0XXXX00 0XXXX00 0XX00X0 0XX00X0 0XX00X0 0XX00X0 000X0X0 XX0 X00 X00 X00 X00 X00 X00 X00 XX0 X00 X00 X00 X00 X00 X00 X00 000 000 000 000 000 000 000 000 XX0 0X0 0X0 0X0 0X0 0X0 0X0 000 00XX000 000X000 000X000 00XX000 00XX0X0 0000XX0 000X000 0000000 00000X0 00X00X0 00X00X0 00000X0 0000000 0000000 0000000 000X000 00000X0 00000X0 00X00X0 00000X0 0000000 0000000 0000000 0000000 X00 X00 000 000 000 000 000 000 X00 X00 000 000 000 000 000 000
And there is the code. I renamed it to peg solitaire afterwards. I used C5 library for HashDictionary, but I'm not sure whether it was really necessary. And yes it takes some memory to compute the results as do breadth-first search. I don't even try any clever heuristics or cutting the tree.
We just released Robocode 1.6.1 Beta for community testing. While we are waiting for at least one email with feedback (we really miss it), I will present detailed list of tasks for next version 1.6.2.
Each robot has it's peer which takes care about the real truth about that robot. Things like energy, velocity, direction and also intentions (settings or commands) are stored there. Battle is reading them each turn and modifying according to rules. Robot is accessing that location using RobotAPI. This location is represented with class RobotPeer.
There are two problems currently. First is that both threads battle and robot's are accessing RobotPeer, so data there need to be synchronized. Current implementation does that per call. So subsequent calls could return different values. And as it is, we couldn't do any better, because bigger granularity could lead to deadlocks or at least to slowdown.
Second problem is that there is fixed cost per call for such synchronization from both sides, robot's and battle's.
What we plan is that we split RobotPeer class to two separate parts. First will serve to robot and second will serve to battle. They will be synchronized once per turn. Let's call first part RobotProxy and RobotPeer the second part from now on.
Great moment for such synchronization is when robot calls execute() method. As everyone knows, robot is blocked till next turn there. We could gather all settings and commands set by robot from last turn and make message from them. Then we could send such message to battle's part.
During processing of turn facts about robot are changed, also new events are produced. Such data need to be sent back to robot during resuming after call to execute(). That data will be merged to information set hold by RobotProxy. RobotProxy will serve as local cache for such info.
We may also wish to decompose hosting of the robot from actual battle logic.
As preparation for modularization in 1.6.3, we could do some of the steps earlier. The difference is that in 1.6.2 we will not move implementations in namespaces and we will not break compatibility. My guess is that full modularization will need such non-compatible changes. I'm not talking about RobotAPI, but ControlAPI. So we might even need to release it under 1.7 version instead of 1.6.3.
It will be big change. So some of the work ahead could help us manage it better.
My Linkedin profile
