WiiLi.org

[bellwethr]

Short: yes.

Longer:

Yes, but I'd make everything an expression, including loops, interpreter thread management, etc. That way, you just walk your way through the script, execute every expression. Strive for elegance. That will help keep your code sane, and maintainable.

For example:

Your LoopExpression will contain it's own set of expressions which it will loop through as appropriate. Even your termination condition is an Expression which is evaluated after each run!

Your ParallelExpression will run multiple expressions in parallel by giving instantiating each inside their own ThreadExpression, etc.

[Cha0s]

I think bellwethr is right on here. Basically, the parser is creating a tree of code to execute. If you keep everything in the tree, your life will be easier. I have some ideas about concurrent threads, though. I would definitely use Java's built-in system. I've done a decent bit of messing around with Threads. I'm assuming you want concurrent loops of code to execute all run at the same rate (i.e. once a block is created, every time it finishes a loop, the other blocks must finish their loops before it can loop again). In this case, I would use Java Threads and object synchronization. The advantage of this method is that Java will do most of the work for you. Sample code follows. Note that I name ParallelExpressions "threads" since that is what they are in concept.

Random side-note: are we using "Expression" or "Statement" for naming? We should standardize that. It's kind of weird having a Statement that only has Expressions as children. :\ Also is Statement going to be an abstract class (does it have any methods that are useful for all Statements) or an interface?

[bellwethr]

Yeah, I basically agree with you, Cha0s, regarding theading--with one exception.

The threading semantic you just described assumes a specific synchronization model--namely, that each thread progresses one loop at a time. That certainly is one type of valid behavior, but that does limit you to that mode.... You can actually keep it simpler and just spawn each ThreadExpression inside it's own thread, but provide synchronized access to the parent ParallelExpression's state. If necessary they can then synchronize using variables or semaphores inside the ParallelExpression.

This raises one issue: variable scoping. Does GlovePIE offer any scoping support? I can't seem to find a full tutorial or grammar for GlovePIE. Does such a thing exist?

[Cha0s]

Yes, I did say I was assuming that. I got that from the comment SwedishFrog made about "scheduling" the tasks. If they don't need to line up, it's rather simple: just start the threads separately and cut out the thread control center completely. Piece of cake. Now if you need some of both (synchronization and unrestricted execution), that's slightly more complicated (but not much ).

I agree with your model for the most part, but I would modify it slightly. If I understand correctly, ParallelExpressions are mostly static regarding the threads they contain (this information is determined by the parser and fixed as a Statement). I would define a class ThreadExpressionGroup that would be a variable class (a variable definable by the user) containing ThreadVariables which could be obtained by assigning them ThreadExpressions. A ThreadExpressionGroup could have various methods of synchronization (sequential, simultaneous/synchronized, unrestricted, etc. And yes, my terminology may be a bit fuzzy. It's late). In any case, a user could add/remove ThreadVariables (which really just contain ThreadExpressions) to/from a ThreadExpressionGroup at will. Also, ThreadExpressions would not be required to be in a ThreadExpressionGroup to run (ie. they would not have to be assigned to ThreadVariables), so they could be created independently (in which case they would simply begin to execute immediately). I think this dynamic setup would create the most flexibility, as you could have groups of threads that change based on conditions in the script.

Anyways, threading is probably pretty low on the list of priorities. GlovePIE only has one thread, if I'm not mistaken (though I've never used it, so I don't really know), so I think we should focus on getting its features up and running first.
_________________
Cha0s

[bellwethr]

*lol*

I assumed GlovePie already had a threading model that we were trying to emulate.

I agree whole heartedly--base functionality first.

[SwedishFrog]

On controlling everything through the tree's behaviour: I'm all for it

On general design of the Code tree: Although we could build this ourselves, couldn't we find some library that allows us to generate the code structures? A suitable one probably already exists. It'd save us alot of writing\debugging time so we could get more features "out the door"

I know .Net has a feature called CodeDOM that does simulates running code, but I think the last thing we want is to get tied into a Microsoft product. There must be another Code Generating library out there for Java -- I'll do some more googling on this, it'd be nice if others did too.

Chaos: What do you mean when you say "Expression" or "Statement" for naming? I don't understand, I always thought of these two things as separate: A statement can contain an expression but an expression can't be a statement on it's own because it doesn't seem to make sense.

On representing generic statements: I feel like the generic statement should be defined by an interface, unless you can thing of a reason it should be a generic class.

GlovePIE's Variable Scoping: I don't thing it supports any sort of scoping, and the docs don't seem to mention it. Skim through Documentation.rtf in the GlovePIE package for a basic rundown of its features.

GlovePIE's Threading: I'm pretty sure GlovePIE does have some sort of threading model, though the details are a bit fuzzy because we don't have the source. Carl does allude to it a bit about it in Documentation.rtf

[bellwethr]

SwedishFrog: So, the partner of the lexer is the parser. And like there are automatic lexer generators (JavaCC, JFlex), there are also automatic parser generators, such as CUP.

JFlex/CUP are designed to work together--while JFlex does the low level tokenization, CUP builds up your expression trees... You still have to specify rules for how expressions are built, however.

<i>Expression vs Statement</i> I've always thought of these as interchangeable. *shrug*