WiiLi.org

[SwedishFrog]

I'm posting this thread so we can figure out how we're designing the OpenPIE Engine. No code has been written yet because we need to discuss and decide upon the design before we can begin. Sorry this is such a long post, but it just has to be.

What you see below are the ideas we've come up with so far -- they're subject to change and open to suggestion.

The engine is responsible for executing the java code that corresponds to the OpenPIE scripting code. It has the following design goals:

- Handle the flow control of the script.
- Support looping. The script must start again from the beginning once it reaches the bottom of its task list, so that it continues to work as intended until the script is stopped. It should also be able to loop smaller parts of the script in the same way.
- Support concurrent (simultaneous) execution of code
- Allow for non-interruptable blocks of code. There are situations where, when running multiple simultaneous threads of code, you want a specific procedure to not be interrupted by other threads until it is finished. The engine should support this

After reading Carl Kenner's post on how Glovepie wrks, and talking about the issue with Luis, we came up with a basic idea of how to implement this. It works like this.

Each piece of code from the script is translated by the parser into an object which can perform the task described by the original script code. Once the whole script is translated into a set of objects, the engine executes the objects in sequence by using an iterator that points at the objects in order.

So when it runs, the iterator points at the first object, then runs it's .execute() method to perform the operation the the object represents. The iterator then moves on to the next object and executes that, repeating on and on until it reaches the end. Once it hits the end, it points at the first object and begins anew.

Concurrent code blocks are handled by spawning a new iterator to run through the loop again and again until it's stopped. This new iterator takes turns executing objects alongside the other iterators on a controlled schedule. Alternatively, we could use just one iterator for all code blocks and make it run on a schedule to control the concurrent operations, but right now I think I prefer the first method

The major hurdle of this approach is generating the objects with the arbitrary code injected into them. I'm not a crazy java programmer so I've never done anything like that before, although it looks like you would need to use reflection (http://en.wikipedia.org/wiki/Reflection_%28computer_science%29)


----------


I discussed this idea with my good friend Karl (wiili user: AmaDaden) who is much more experienced in Java than I am. He said that there are built in threading techniques in java which are well established and could be a good way to go for implementing flow control. This could simplify the programming of the iterator scheduling part of the engine.


What do you guys think about all these ideas? Is this a good way to go about it? Are there alternatives that we're not considering?

Please leave your input.

[para]

It seems like you are trying to reinvent the wheel.

Let me ask you this, are you:

1. Writing this program as a hobby project and thus want to use it to learn how scripting engines are built, or
   
2. Writing this program to be functional for the community?
   

Almost every program I've written falls under #1, but if you are going for #2 you should research and consider using a scripting engine that is already well established and maintained. Not only would this be much easier to write (the lexical parser alone would probably take a good bit of time unless you already have experience with that) but it would also be easy for people to pick up since they may have already had experience with that language and are already support communities for them.

Here are a few that are out there:

• Python
  
• TCL
  
• Lua
  
• AngelScript
  

Choose one of those, throw in a wiimote library that's already out there, and encapsulate it within a nice polished GUI. Okay, so with this route you didn't get a chance to write a lot of the cool functionality behind GlovePIE, but at least you pumped out an open source alternative that I'm sure plenty of people would be interested in using.

Just a thought
_________________
wiiuse C wiimote library - http://wiiuse.net/

[luis_villase]

[bellwethr]

I don't really think you need to use reflection here.

Typically, when you build an interpreter, you build an Expression object out of a statement. E.g.,

3 + 2 ==>
Expression E {
Op = "+";
Param1 = 3;
Param2 = 2;
}


So your script becomes a set of expressions, executed either sequentially, or in parallel, depending on the threading semantics.

This is the whole point of using a parser/lexer. The lexer tokenizes the raw text, then your parser turns your tokens into your expression data structure.
3 + 2 can tokenize to:
{3,NUMBER},{+,OPERATOR},{2,NUMBER}
or
{3 + 2,ADDITION}

depending on how much you want to put into your lexer grammar.

[SwedishFrog]

@bellwethr: You're right about all that, of course. This is a strange problem to describe. Maybe you can help clarify this for me.

This recipe calls for a parser that doesn't behave like most. Most parsers would tokenize string "3 + 2" and generate java code to do the addition. The above design is more abstracted than that.

In this design, The parser would instead generate an object. The object inherits a class called Statement that has a method called execute(). In the code for the execute() method is where you'll find the "3 + 2" being evaluated. It's structured this way because it makes it trivial to point the iterator at a Statement object to execute its embedded code.

So given that more detailed explaination of the problem, do you think we can avoid use of reflection when creating these objects? I'd really love to avoid it if I could.

[bellwethr]

How is this different from any other interpreter?

In an interpreter, the parser builds your expression tree for you.


For example, our AdditionExpression class might look like:

class AdditionExpression extends Expression {

Number term1;
Number term2;

public AdditionExpression(Number t1, Number t2) {
term1 = t1;
term2 = t2;
}


Number execute() {
return term1.value() + term2.value();
}

}


The lexer reads 3+2, builds the {3,NUMBER},{+,OPERATOR},{2,NUMBER}
The parser walks through this --- hits the 3--this limits us the either add/subtract/multiply/divide (let us suppose), we hit the +--now we know we're adding. We read in the next term, and we can complete the expression. We build a:

new AdditionExpression(new Number(3), new Number(2));
and add it to our list of expressions.

To generalize, after you tokenize, your expressions will already be built for you...

all you have to do is iterate through them, and call their execute() methods. No reflection necessary, since you've built the expression tree using the appropriate classes.

[SwedishFrog]

Simple and Beautiful. It's looking much clearer now.

Now, for the bigger question: Do you think this statement-object\iterator model seems like a good idea in general?