Scripting Flash apps: scanning the input file

Here we go. I know that probably I should have started this new topic talking about the grammar of the language we are going to implement, but as long as I see grammar strictly related to parsing, I’ve preferred to talk about scanning first.

We will go back to the grammar the next time, when talking about how to parse an input file.

I wrote about scanning (or lexing if you prefer) a while ago, when blogging about expression evalution in ActionScript. Scanning an input file is quite always the same (although some languages might require unusual features), and what I wrote about expressions works also for a general language.

The goal of the scanning process is to group some characters together, skipping the ones that have no meaning for the language like spaces. Each group of characters is usually called token. So a Scanner converts a textual input into a stream of tokens, each one rappresenting a possible valid word for our language. While scanning you don’t take care about the meaning of what you are grouping or about the fact that a sequence of tokens is meaningful. This is a task for the Parser as we will see.

When talking about expressions, I showed a manual implementation for a Lexer. Now I want to take a different approach and show you a possible implementation for a simple dynamic scanner. This scanner will be based on regular expressions: each regular expression will rappresent a given token, and we will be able to assign callbacks to the scanner that will be executed each time a given token is extracted from the input.
Writing a general and reusable scanner is usually a good practice. A common approach is to use some scanner generators, that are usually regular expression based too but are able to generate the code for a scanner at compile time. Our approach is different (and generates slower scanners) because regular expressions are evaluated at runtime; but it is fine for a test project.

You can download the source code for the regular expression based lexer (RegexLexer) here, as long as a simple usage example. Let’s see this example together so we can briefly discuss it (PBLexer.as):

Continue reading

Scripting Flash apps: design the language

Finally I had a bit of time to go back to the discussion I started about a month ago: scripting your flash applications. I spent a bit of time thinking which is the best approach to start discussing this kind of topic; it is not as easy as it seems because the risk is to fall into a too complex discussion that a lot of people won’t benefit from.

So I decided to start with a simple example that is somehow related to what I’m doing in these months; more examples will come and I’ll analyze different aspects of scripting trying always to keep the discussion as simple as possible even if this may bring me to do avoid some hard to discuss approaches or optimizations.

Our first scripting language will be an extremely simple language that will be used to manipulate images (like Pixel Bender does). Obviously the goal is not to write something that can be compared with Pixel Bender, but at least we would like to provide an implementation that will lead to scripts as fast as native code (at least we hope so :P).

The first step is to design the language, and to do that we need to do the step zero that is to define the goals we want to achive with the first implementation:

  • The language must be extremely simple to design and implement (it is a didactic stuff indeed!);
  • The language must be as simple as possible to learn and use: we won’t be an alternative to Pixel Bender (because we can’t … yet ;P)
  • The language must be quick to compile and execute.
  • A script must accept some parmeters to control its behaviour.
  • We must support comments!

Now that we decided which are the goals, let’s start definign some limitation or features we must include to quickly reach a solution:

  • The first implementation of the language will support a sigle data type: Numbers. We will move further adding more data types later – I don’t want to focus on type checking yet.
  • We will add support for basic expression operators, basic control flow. No support for functions yet.
  • The language will provide some useful operators or builtin functions to manage common operations like packing/unpacking color components and peform some mathematical operations.
  • Arguments to a script will be only Numbers at first.
  • A script will be defined as a simple sequence of arguments followed by a function definition. This function will be applied sequentially to every pixel of one or more source images.
  • We will provide to implementations for the language: a simple (and slow) interpreter at first, then we will generate native SWF code to speedup the performances.

Even if briefly, it is quite important to define the goals of our language and then the features, because a lack of design (even if extremely simple and poor as the current one :P) may lead to unexpected issues during implementation.

Now that we defined those basic pointers, let’s see how the language will look like:
// Simple crossfade filter
// The crossfade intensity
argument intensity;
/**
* A quick explanation of the used builtins:
* - in( id, x, y ): gets the ARGB color at x and y of the image identified by id (there can be more than one image as input);
* - out( id, x, y, color ): sets the ARGB color at x and y for the output image identified by id;
* - argb( a, r, b, b ): build an ARGB color from its components (clamping and rounding the values as required);
*/
evaluatePixel( x, y )
{
// this kind of assignment is similar to the python unpack assignment
// but extracts the 4 components (ARGB) from a color.
a1, r1, g1, b1 = in( 0, x, y );
a2, r2, g2, b2 = in( 1, x, y );
out( 0, x, y, argb(
( 1 - intensity ) * a1 + intensity * a2,
( 1 - intensity ) * r1 + intensity * r2,
( 1 - intensity ) * g1 + intensity * g2,
( 1 - intensity ) * b1 + intensity * b2 ));
}

As a side not, I must say that the language may change during implementation because of unexpected limitations we will find during development.

Next week we will move forward start implementing the language. Stay tuned!

Scripting your Flash applications …

As someone of you may know, I really like studying programming languages and sometimes implement for fun (or for work) simple scripting languages that help me out during development.

The fight between scripting and programming languages will probably never end. Well, it is not really a fight but more an infinite race where the first position is exchanged continuosly between the two participants.
We need flexibility first, and so we add to our complex applications a way to support scripting to be able to easilly perform changes without the need to run the long time taking compilation process a low level language might take; then, the more the scripts became complex, the more we need an increase in performances, and so we rapidly move to compiled plugin egines; plugins offer a bit of flexibility and usually a good speed. Then we grant other users the permission to write plugins and so we need a sandbox to run the plugins in and to be sure every single line of code that is executed doesn’t harm our application. And so we revert back to scripting … and so on.
The race will never end but the technologies will continue to increase in speed and sometimes in complexity.

All the introduction is to say that its not the point to choose if scripting is useful or not for Flash applications, but to say that someone might need it for reasons we cannot think about right now, and someone else might not need it because they are fine with recompiling everything from scratch at each single small change.

I don’t think there are some many Flash applications that support scripting. I built myself a few of them for my company but they are for a particular purpose and probably the same motivations that made me decide to implement a scripting language are hard to find for other kind of applications.

As far as I know, the most of the applications that need to be flexible use a plugin system (more or less complicated – as Aviary for instance and Hobnox) and are fine with it because – we must say that – ActionScript is itself a scripting language and a SWF file is nothing more than a bunch of instructions (more or less) generated by compiled ActionScript.

But sometimes security comes into account, and it is hard (even if possible) to limit the funcionalities used by a plugin if this plugin is created by a 3rd party developer.

And so it comes into account scripting. With scripting we have full control over what a developer can do an how he can do that. We can limit it, provide builtin functionalities … But everything costs something, and building a fast/flexible/powerful/useful scripting languages is not that easy as it might seem.

This is why I decided to spend a bit of time in explaining the basics to implement a scripting language in actionscript to be able to script our applications. I’ll walk through all the passes – from lexing to bytecode generation and maybe a quick look into Virtual Machines – with the aim to provide someone (maybe in the far future) a bunch of documents to use as reference to build their own scripting language.

I’ll try to give an in depth look, but as far as the argument is quite complicated and full of facets, you may not find here the right solution for you. Nor the fastest or the most flexible. But it is better then nothing so if you are interested in that keep reading the blog 🙂

Expressions evaluation at (almost) native speed

Finally I found a bit of time this weekend to do some other tests with expressions evaluation.

The results are pretty interesting, even if obvious from some point of view. I took the ExpressionEvaluator I wrote as example for the first post about this topic, and then I edited a bit the code adding just in time AS Bytecode compilation.
Thanks to that, expressions evaluation is much more fast and always safe because it runs in its own ApplicationDomain.

You can download the sources here, that includes the edited code and a test file. The test file runs 1 milion of iterations and may hang your browser or at worst case your system. Reduce the value of the ITERATIONS constant if you are not sure about the power of you machine.

If you want to read a bit more details about that, click on the link below to continue reading.

Continue reading

Top Down or Bottom Up for Expression Evaluation ?

Last time I wrote about Top Down parsing, a technique for parsing that can be easilly implemented manually using function recursion.

Today it is time to talk about one of the other ways of parsing, called Bottom Up parsing. This technique try to find the most important units first and then, based on a language grammar and a set of rules, try to infer higher order structures starting from them. Bottom Up parsers are the common output of Parser Generators (you can find a good comparison of parser generators here) as they are easier to generate automatically then recursive parser because they can be implemented using sets of tables and simple state based machines.

Writing down manually a bottom up parser is quite a tedious task and require quite a lot of time; moreover, this kind of parsers are difficult to maintain and are usually not really expandable or portable. This is why for my tests I decided to port bYacc (a parser generator that usually generates C code) and edit it so it generates ActionScript code starting from Yacc-compatible input grammars. Having this kind of tool makes things a lot easier, because maintaining a grammar (that usually is composed by a few lines) is less time expensive than working with the generated code (that usually is many lines long).
I will not release today the port because actually I had not time to make sure it is bugfree and I’ve only a working version for Mac, but I plan to release it shortly if you will ever need it for your own tasks. My goal for today was to compare the speed of the parser I wrote with an automatically generated bottom up parser, to see which is the faster approach.

I created a bottom up parser which is able to execute the same expressions accepted by the expression evaluator I wrote last time. There are anyways some differences that – as you will probably and hopefully understand in the future – that make those parsers really different. Some will be disussed shortly here.

To do that I created a Yacc grammar and some support classes.
The parser grammar is really simple and really readable:
%{
%}
%token NUMBER SYMBOL
%left '+' '-'
%left '*' '/'
%left NEG
%%
program
: expr { Vars.result = $1; }
;
expr
: expr '+' expr { $$ = $1 + $3; }
| expr '-' expr { $$ = $1 - $3; }
| expr '*' expr { $$ = $1 * $3; }
| expr '/' expr { $$ = $1 / $3; }
| '-' expr %prec NEG { $$ = -$2; }
| '(' expr ')' { $$ = $2; }
| SYMBOL '(' expr ')' {
if( Vars.SYMBOL_TABLE[ $1 ] )
{
$$ = Vars.SYMBOL_TABLE[ $1 ]( $3 );
} else
{
trace( "can't find function" );
}
}
| SYMBOL {
if( Vars.SYMBOL_TABLE[ $1 ] )
{
$$ = Vars.SYMBOL_TABLE[ $1 ];
} else
{
trace( "can't find symbol" );
}
}
| NUMBER { $$ = yyval; }
;
%%

Continue reading the extended entry to see the results. Continue reading

Runtime expression evaluation in ActionScript

Finally I have a bit of free time to write down this post.
Some days ago a guy on the forum asked about how to evaluate at runtime simple mathematical expressions with support for symbols and function calls.

Now that the eval function have been removed from the language for reasons I’ve not enought time to talk about, we need to parse and execute those expressions manually.

I built a simple Actionscript library that can be used to parse mathematical expressions: it has support for function calls, for variables and it is able to convert the expression into a postfix rappresentation if you may need it. The expression parser is quite simple and have been built manually following some concepts related to programming language compilers; it includes a Scanner (or lexer – however you want to call it) to tokenize the expression, a Parser that convert the expression into an Abstract Syntax Tree and a simple routine that evaluates that AST using a Symbol Table as evaluation context.

There are no comments inside the code right now; I hope to find a little bit of time to write an in depth discussion about this topic. In the mean time you can continue reading the entry for a general explanation about how does the code works and for some examples that may be useful.

Here is a simple example that shows how does the code works:

import it.sephiroth.expr.CompiledExpression;
import it.sephiroth.expr.Parser;
import it.sephiroth.expr.Scanner;
public class Example
{
public static function run(): void
{
var expression: String = "sin( x / ( 8 / 2 + (-0.12 + 2.3) * x / x ) ) * 100";
var scanner: Scanner = new Scanner( expression );
var parser: Parser = new Parser( scanner );
var compiled: CompiledExpression = parser.parse();
var context: Object = {
x: 100,
sin: Math.sin,
cos: Math.cos
};
trace( 'Postfix:', compiled.toString() );
trace( 'Result:', compiled.execute( context ) );
}
}

Before I forgot, you can download the source code here with a simple example included.

Continue reading