Arcane Coder

Alchemy Data Manipulation Faster Than Vectors

2009-03-13T21:33:00.000-07:00

While working with Alchemy to port a roguelike library to handle field of view calculations for a 2d tile game (The Doryen Library, port is called libtcod-alchemy) I noticed some drastic speed differences between using a ByteArray in pure AS and manipulating that same ByteArray inside Alchemy. Out of curiosity I wondered how Alchemy manipulations of large data structures would compare to a native AS Array or the new (and faster) Vector.

As it turns out, Alchemy wins hands down when the data is already in a ByteArray. If you need to transfer data from an array/vector into a ByteArray to hand off to Alchemy and then transfer it back, it is slower to use Alchemy. For this test I have a collection of 1,000,000 numbers and for each iteration of the test, I loop over the numbers and add one.

Alchemy ByteArray additions are about 6 times faster than Vector integer additions and 10 times faster than pure AS manipulations of a ByteArray (when using Array notation [] on a ByteArray to manipulate a Byte - using position, readInt() and writeInt() in AS is much slower).

Below is test program that proves it:

Note that the demo above requires Flash Player 10 (required by Alchemy).

NOTE: If you want view the source, you need to go here and right click on the app (the embedded version in blogger doesn't know where to look for the source).

This tells me a few things:

There is a great deal of room for improvement in ActionScript's compiler since it should perform better IMHO. I understand some slow downs due to type safety, garbage collection, etc but I didn't expect the huge difference.
If Alchemy had native access to the same Native calls used to seralize data to AMF that is used in AS (described here), Alchemy would be blazingly fast for manipulating data even when stored in Arrays or Vectors. You would just serialize the objects as AMF into Alchemy, manipulate the data with Alchemy, and serialize it back out as AMF back to AS.
The ByteArray.position is much slower than I would expect.
If you need to process large amounts of data, seriously consider using Alchemy. Remember the marshalling tax to and from Alchemy - every bit of data passing into and out of Alchemy takes time to marshall, so you want to do it in large chunks like in my speed test.

You may notice that the first Alchemy test takes more time than normal - this is due to initialization of the Alchemy library.

In case you are curious essentially the same test takes:

GCC C Code - 1 or 2 milliseconds
GCC Lua Code - 300-400 milliseconds
Lua Alchemy - 8 seconds (might be including some of the time to get the tick count from ActionScript)

Lua Alchemy Getting Sweeter in v02a

2009-02-01T12:13:00.000-08:00

Thanks to Alexander Lua Alchemy now has sugar! What this means is you no longer need to make calls like the following in the Lua Alchemy code:

as3.call(myvar, "someCall", param1, param2)

Instead you can make calls that look like native Lua code:

myvar.someCall(param1, param2)

This includes chaining calls like a.b.c().d

Below is a preview of the release:

Note that the demo above requires Flash Player 10 (required by Alchemy and my use of the local file system to allow opening/saving files). It is also hosted here where it can take up a full browser screen and is much easier to read.

You will notice in the demo code a great number of calls to as3.tolua(xxx). These calls convert ActionScript types into Lua types where possible. We removed all automatic conversion from AS3 to Lua types for performance reasons - each time you cross the Lua<->C<->AS3 boundary you have to pay the Alchemy wrapper performance tax.

For more information on the upcoming release of v0.2a (official downloads available in the next few days) see:

HISTORY for v0.2a

Lua Alchemy Homepage

Lua Alchemy v0.1a Released

2008-12-21T21:45:00.000-08:00

The first release of Lua Alchemy has been released; the library SWC, demo, and code can be downloaded from here:
http://code.google.com/p/lua-alchemy/

Since my preview post (which is now running the same demo code) we have

Added many Lua scripting samples.
Fixed some memory leaks.
Cleaned up function callbacks created in Lua which would typically be used for event listeners.

Below is a preview of the release:

Note that the demo above requires Flash Player 10 (required by Alchemy and my use of the local file system to allow opening/saving files). It is also hosted here where it can take up a full browser screen and is much easier to read.

The next version will include syntax sugar so instead of calling as3.call(var, "function", param) you could call var.function(param) and similar calls to make calling ActionScript code look the same as calling Lua code.

LuaAlchemy Project v.1a Preview

2008-12-15T11:18:00.000-08:00

Since my last post my experiment to make Lua a runtime scripting language in Flash using Alchemy has become a full open source project located here:
http://code.google.com/p/lua-alchemy/

I even have a partner named Alexander Gladysh whom I met on the Lua boards.

We are approaching a V.1a release of the project. Using LuaAlchemy you can now create any ActionScript class available at runtime, get/set properties, call functions, and set event listeners (actually you can return a Lua function to use as an ActionScript function). The Lua to ActionScript interface is a little raw right now but we plan on adding some Lua sugar to make accessing ActionScript objects, classes, and namespaces in Lua look and feel like using Lua objects.

Below is a preview of the release:

Note that the demo above requires Flash Player 10 (required by Alchemy and my use of the local file system to allow opening/saving files). It is also hosted here where it can take up a full browser screen and is much easier to read.

Along the way to this release we have encountered a few problems which I will discuss. The first problem was speed. Although the Alchemy V.4a compiled code was fast enough for our purposes, it was about 30 times slower running a life simulator written in Lua than natively compiled Lua. The release of Alchemy V.5a has made life run 4 times faster so progress is being made (v.4a had some debug code compiled in that slowed things down).

The second problem has been gluegen. Gluegen is a tool to help you create wrappers around C code that takes a mix of C and ActionScript code to generate C and ActionScript wrappers. Unfortunately this seems to interfear with CLibInit.setSprite() which we wanted to use to provide a sprite that Lua could use for stdin, stdout, and stderr. Glugen created code creates and inits CLibInit as static members and you seemingly need to call setSprite() before init(). We worked around that problem by providing an output TextArea in the demo below, but we plan on writing the wrapper ourselves and not using gluegen at all.

The third problem is related to garbage collection in Flash and Lua. To make Lua functions usable as an ActionScript function we call AS3_Function() to create an ActionScript function that calls a C callback function passing in some contextual data. This data includes some Lua references in a malloced structure and we would like to know when it isn't needed anymore so it can be released. We haven't figured out any way for Alchemy to tell us when the object is no longer needed. A future version will do some cleanup when the lua_state is closed.

Overall our experience has been a positive one and Alchemy is still in Alpha.

Lua ActionScript Alchemy

2008-12-02T19:26:00.000-08:00

At Adobe MAX 2008 San Francisco, Alchemy was released. Alchemy was once known as FlaCC or Cassava and is a C/C++ to ActionScript compiler.

Alchemy works by translating C/C++ code to ActionScript through a LLVM compiler which instead of producing machine or bytecode produces ActionScript. The translated C/C++ code uses a big ActionScript ByteArray as the C/C++ heap and stack. The performance of alchemy is slow if you martial data from C/C++ code to ActionScript or back but faster (supposedly up to 10 times faster) than ActionScript code you write yourself for data intensive actions where everything operates in the C/C++ memory space - speed improvements over AS code are also due to LLVM doing code optimization which is missing from the normal AS compiler.

After downloading and setting up Alchemy, I started trying to port over a few C/C++ libraries. The following libraries have given me some trouble mainly with needing to adjust makefiles or the ./configure script: Angband, Nethack, guile, Python, Ruby, ARToolkitPlus, SDL, and Squeak. I haven't given up on them but I wasn't in the mood to do battle with Makefiles; I wanted to learn Alchemy.

My success came with compiling the scripting language Lua 5.1.4 and embedding it into a Flex application. The following proof of concept can run a Lua script which returns one or more values and are shown in the Lua Stack Panel. Lua can make the following calls into Flex:

getTextAreaProperty(property_name) - Returns the given property of the text area in the lower left hand corner.
setTextAreaProperty(property_name, value) - Sets the given property on the text area in the lower left hand corner (must accept string values).
callTextAreaFunction(function_name[, param1, ..., paramN]) - Calls a function on the text area in the lower left hand corner (must accept string values).
average(value1, ..., valueN) - Returns the average and sum of the given values.

Note that the demo above requires Flash Player 10 (required by Alchemy and my use of the local file system to allow opening/saving files). It is also hosted here.

Should I continue working on this library, I'd want to allow Lua to create and call functions on any arbitrary ActionScript class. Alchemy is still in beta and does have its own problems - not everything builds easily and while pure Alchemy code can be faster than ActionScript, marshaling from ActionScript to C/C++ code and back can slow things down - for example life.lua takes 4 seconds with the standard compile of Lua and 13 minutes! with the Alchemy build. Still it works quite well for my purposes of embedding a runtime scripting language into my Flex applications.

For more information check out the following blog posts:

Edit: Created a google code project to share efforts in using Alchemy to embed Lua in ActionScript. Uploaded the proof of concept:

FlaCC (C/C++ to Flash Compiler)

2008-10-05T17:51:00.000-07:00

More news on the C/C++ to Flash compiler, now called FlaCC. With this tool developed by Scott Petersen at Adobe would allow almost any arbitrary C/C++ code to be compiled down to ActionScript bytecode to run on the Flash player. I first heard of this at MAX 2007 and there will be a session at MAX 2008 on this (plus hints it will be in keynotes).

While we wait here are a few links to some more recent news:

The MAX 2008 Session is "Using C++ Libraries in Flash Player and Adobe AIR" Monday, November 17, 2:00 pm - 3:00 pm. I'm looking forward to that session.

360|Flex

2008-07-27T06:11:00.000-07:00

This coming August, I'll be heading out to San Jose to attend the 360 Flex conference:
http://www.360conferences.com/360flex/

I'm new to the Flex scene (almost a year now) and came from a background of 14 years of C++ cross-platform application development so it is exciting and different to immerse myself in the new culture. This is the first 360 I will have attended and only the second conference related to Flex (the first being MAX 2007 in Chicago). I'm now fortunate enough to be working for Universal Mind (as a contractor) and when I saw all the people taking vacation to attend 360, I knew I had to attend.

Of particular interest to me are sessions teaching frameworks, component building, design patterns, process (I'm a big process geek - how you do something is very important for maintainability), and low level programming. There are so many sessions that appeal to me at the same time that I'm going to have to make some rough decisions. Here is a list of the appealing sessions (fortunately I work with some of these people so I can pick their brain later):

Pre-Conference stuff I cannot attend because my plane doesn't land until 2pm
- James Huang - The R1-RPC/J Toolkit and the D.eval API
- Ben Stucki/Ryan Campbell - OpenFlux
Adam Flater - How to make your AIR app blow up with Merapi
Alex Harui - Versioning Support for Large Applications and Portals
Andrew Powell - Implementing BlazeDS
Axel Jensen - Project Workﬂow (trac,svn,ANT,XML...)
Ben Clinkinbeard - Concepts and Strategies for Creating Reusable Components
Ben Stucki - How to Build a Framework
Brad Umbaugh/RJ Owen - Diving Deep with the Flex Component Lifecycle
Brian Weisenthal - Architecting real-time and collaborative applications in Flex
Chet Haase - Filthy Rich [Flex] Clients
Chris Scott - Introduction to the Swiz Framework for Flex
Eric Ko - Reﬂective Programming
Jacob Wright - Advanced ActionScript APIs
Jeff Houser - How to Build Flex Components
Jeff Tapper - Unraveling the hassle with Drag an Drop in AIR
Jonathan Branam - Improve your programming by reading the Flex source code
Josh Tynjala - Polishing Components for the Unwashed Masses
Laura Arguello - Decoupling Flex Applications with Mate Framework
H. Paul Robertson - Advanced AIR and SQLite: An optimization conversation
Ryan Campbell - PlexiGlass (OpenFlux 3D Components)
Samuel Asher Rivello - Creating an MMO from Scratch with Adobe Flex 3… in 59 minutes.
Tom Gonzalez - Data Visualization and Dashboards with Flex
Troy Gardner - Advanced State management, the Heirarchical State Design Pattern

PS: The 360|Flex team sent me a 1GB flash drive with content from 360|Flex Atlanta and Europe. I could pass it on to a lucky commenter.

Best new Flash 10 Feature: File Access

2008-05-16T06:24:00.000-07:00

The new Flash 10 Beta is out. While all the graphical improvements are fantastic, for me the best new feature is file access. I've written a few applications where I wanted to load or save files directly from Flex. Having to write a server just to upload the file to and then send back to Flash was pretty ridiculous just to preview an image that the user may or may not want to really upload. As long as the user is asked to load or save a file it should be safe.

ActionScript Cross Compiler Theories

2008-05-11T17:18:00.000-07:00

This post is a bit late coming, but I'm trying to be good and post once a week.

Last year after Adobe MAX 2007, I posted a bit on the preview of a C++ to ActionScript compiler. This year there has been a little more buzz buzz on the subject. I've been curious how this might be done and have a few theories:

Create a C++ parser/compiler to either produce Flash bytecodes or ActionScript. C++ is notoriously hard to parse so this would be quite a pain without something to get you started. There is a partial ANTLR grammar for C++ here.
Create a gcc backend to produce Flash bytecodes. All gcc languages compile to intermediate languages called GIMPLE and GENERIC. Target platforms "merely" translate this intermediate form to the target platform. See this link for more information. This path would be the most generic solution and allow any gcc language to be compiled to flash.
Leverage PyPy (a python VM generator and more) to create an ActionScript or Flash bytecode target. Of course this would only really help you use python unless you created a translator for C++, but flex-pypy is cool enough to mention.

Overall I think the gcc solution is the most likely and most powerful. I'm looking forward to the cross compiler and hope it will be included in Flex 4 as part of the broadening horizons theme.

Not Using Source Code Control is Insane!

2008-04-29T21:59:00.000-07:00

"Like skydiving without checking your parachute or having sex with a stranger without using a condom." -- me, earlier today

I've worked for a few places that didn't use source code control properly or even at all before I started. But today, I met a new PHP programmer who didn't know what I was talking about when I mentioned source code control. He recently migrated over from writing and graphic design and has no background in computer science or software engineering so it isn't his fault really. The fault lies with those that brought him into the fold.

As far as I can tell, I'm somewhat strange - I'm passionate about source code control (now noted as SCC) and have tried a few new ones just to see if I like them. Process is important and while I don't believe in crazy ISO-9000 level of process (then most of your work is to maintain the process rather than produce value) but you need some or there is only chaos. Go check out "The Joel Test", I'll wait.

I don't necessarily believe that all of them are necessary or sufficient. But what is #1? That's right SCC. SCC is so important, many word processors (like word) embed version tracking into the software.

Why do people insist on using nothing or tarballs/zipfiles to ensure the safety of business/personally critical data? One place I worked used zip files but also required you comment out changed code with a reason plus add comments for the new code. This resulted in files where there were pages of code with ocassional live code (it was unreadable). SCC systems do this for you.

What is SCC?

In essence, a SCC tracks changes made to files and directories and allows users to (among other things):

Checkout (aka get) the current version or some version from the past of those files/directories.
Check-in (aka save) your current changes to the SCC to be saved for posterity.
Revert changes you don't like.
Find out who made changes and why.
Do differences on what exactly has changed either between past versions or with what you have done since the last check-in.
Manage multiple people working on the same files and directories.
Give the ability to mark and later retrieve files/directories related to some important event like a release.

There are several main paradigms for SCC:

Locking vs Merging - Some SCC tools require you to mark a file for editing such that it is locked and no other user can commit changes until you release the lock. Other SCC tools don't require locking but will require (or do it for you if simple) merging if there are conflicts. I have found the locking model interrupts my workflow because I may not know all the files I'll change ahead of time, stopping to lock a file gets in the way, and someone might lock the file I'll need and then need a file I have locked (classic deadlock problems). Merging might sometimes be a pain, but it is better than the alternative.
Client/Server vs Peer to Peer - Most SCC has a server that holds the "one true version" and all clients must submit to that server. A few systems use a peer-to-peer structure where the only "one true version" is decided by social convention not technology.

For more information check out:

Wikipedia on Revision Control
This introduction to subversion screencast.

SCC and the Individual Developer

Even if you work by yourself for work or fun you should use SCC. The few times I haven't, I often regretted it. The first reason is that this helps develop good habits. Secondly, this makes it so much easier to undo mistakes should they happen.

Imagine you are making some changes to a game you wrote. The changes, while simple, are invasive and touch numerous files over the course of a day and you were interrupted numerous times. Sadly you made an error that causes saved data to become corrupted but the error could have been introduced anywhere and you can't remember exactly what you changed. SCC allows you to quickly find out what files changed, what the changes were, and if necessary revert back to good code and start over. Without SCC, you might be debugging for a long time.

SCC Tool Recommendations

This is based on tools I've used for long periods of time for production code with the exception of Git (many tools are omitted):

Perforce - This is a commercial product I used long ago. It can use locking or merging. I don't use it now because it costs money, I'm cheap, and there are great open source alternatives.
Visual Source Safe (VSS) - This pile of steaming... rubbish is given away by Microsoft. It uses a locking model by default. The problems with VSS are that it often corrupts large codebases and Visual Studio integration (up too 2005 I believe, or beyond) puts little snippets in your project files to handle integration. If you are ever kidnapped to a tropical island by a criminal mastermind with a claw and a cat and are told you must use VSS or be given to a bunch of cannibals, choose the cannibals because it will be less painful. I have heard from some insiders that Microsoft doesn't use VSS. If the producer of software doesn't use their product (and they could), then I don't feel it is wise using it either.
Vault - A VSS commercial clone (plus bonuses) of VSS. While this tool never corrupted my code like VSS did on a regular basis, I dont' much like how Vault works, so I don't like using it.
CVS - An open source merging SCC used for years by many open source products.
Subversion - A newish SCC that is much like CVS but it offers atomic commits (everything goes or nothing - so you don't have partial commits), versioning directories, better brancing/merging, and other improvements. If you want to use a client/server SCC, I'd recommend this (despite what Linus says).
Git - This is the only distributed/peer-to-peer tool on my list. I've only been using it for a few weeks, but thus far I like it. Git was quick and easy to setup and does everything I expect in a SCC with the added bonus of being really fast (partially because there is no server to talk to) One of the selling points is better branching/merging but I have yet to do much of that.

Closing Comments

I'll end with a few recommended best practices:

Use source code control
Check-in as often as possible without breaking the build.
Keep your commits small.
Add a useful (but short) message to each commit on why you made the commit (not what you changed since the SCC handles that). This should include a bug number if available.
Tag all your releases in SCC

This brings my SCC rant to a close. I feel much better now.

Using ANTLR to create an Excel Like Formula Parser in Flex

2008-04-20T15:53:00.000-07:00

Introduction
One of my first Flex programming projects was to write an Excel-like expression parser. This parser was written using the “shunting yard” algorithm by Edsger Dijkstra to transform infix notation to a reverse-polish notation (postfix) stack which is easily processed. That code isn't publicly available but the algorithms are described in a paper I wrote here.

I decided to re-write the expression evaluator using ANTLR. ANTLR is a parser generator that takes BNF-like notation and generates code for a target language. The default target language is Java, but there are many other target languages including an ActionScript target in the upcoming 3.1 version.

Flex Formula Evaluator
The actual Flex application is available here with source available. This is an example of a formula that can be evaluatedl feel free to copy and paste into the evaluator below (variables are noted in "[variable_name]"):
(1+2)*sum(9-8,5,17.5,[numarray])/if(or([string]="hello",1>5),2,99)

How Does it Work?
The formula parser begins with the ANTLR grammar found in Formula.g and FormulaTree.g (in src com.arcanearcade.antlr). ANTLR has 3 types of grammar rules:

Lexer - Used to transform the character stream into a series of tokens. Lexer rule names are written in all capital letters. For example, the following code describes how to recognize variables which are any characters except [ or ] found between [ and ].

VARIABLE : '[' ~('[' | ']')+ ']';

Parser - Walks though the tokens to form sentences in the grammar. Parser rules begin with lower case letters. The following example shows how to recognize a percent token, which is a number token followed by the percent sign (both described in the parser grammar). The '^' in the grammar is a special token that shows what the head of the created tree grammar looks like. So "50%" is transformed into a tree with an s-expression notation of "(% 50)" and will be evaluated to the value "0.5" by the tree grammar.

percent: NUMBER PERCENT^;

Tree - This optional grammer taks the tree that can be created by parser grammar and with the help of native code snippets interprets the tree to produce output. While you can use code snippets directly in the parser, using a tree grammer allows you to reuse the lexer and parser for other languages and write a (usually simpler) tree parser for each target language. The following tree grammar shows how to evaluate addition where "6 + 7" was turned into "(+ 6 7)" by the parser and is evaluated to the number "13" by the ActionScript code between the {}

operation returns [Object value]
: ^(ADD a=expression b=expression)
{ $value = Number($a.value) + Number($b.value); }

The ANTLR tools parse the grammar files to produce native code as shown in the diagram below:
Code in FlexFormula.mxml evaluateFormula() takes a string, feeds it into the lexer, takes the output of the lexer feeds it into the parser, and then finally feeds that into the tree to evaluate the result. FormulaTree#addFunction() adds new spreadsheet functions like "sum" and "if" and FormulaTree#lookupVariable sets the function callback to retrieve variables.

What Next?
The expression parser isn't as friendly as it could be (it is just a demo). To improve the formula engine to the point it could be used in a spreadsheet the FormulaLexer, FormulaParser, and FormulaTree in a class that would:

Add all the common function.
Setup binding to watch for changes to the formula string and only call the lexer and parser when the formula changes.
Setup a public and bindable variable for the result value.
Add binding for all variables in an expression so when they change the tree can be re-evaluated.
Improve error handling

C++ to ActionScript

2007-10-05T08:55:00.000-07:00

One of the sneak peeks at Adobe MAX 2007 Chicago was a C++ to ActionScript translator by Scott Peterson. This was the most interesting of the sneak peeks for me in part because I was a C++ developer for 12 years (until 3 weeks ago) and because of the implications of the translator.

First check out the video here:
http://youtube.com/watch?v=0hX-Uh3oTcE

During the demo he showed:

A C++ XSLT library turned into ActionScript
A fractal program from C++ to ActionScript simulating green threads using ActionScripts asyncronous calls.
Doom 2 running in Flash.

How does it work:

C/C++ code is translated to ActionScript 3
AS3 code is compiled into a SWF
Run the code on Flash/AIR

What does it mean:

Easy porting useful open source C++ libraries/programs to ActionScript to run on the browser.
Porting interpreters for languges like Ruby, PHP, Lua, Python, Smalltalk. ... to run on Flash.
Writing your own DSL using ANTLR and porting the C code to ActionScript without having to write an ANTLR target language. I recently wrote a shunting yard algorithm Lexer and RPN parser in ActionScript for an Excel like language where this would have saved me some time (but not the fun of writing my own Lexer/Parser).

Scott Peterson, if you ever read this and want an alpha/beta tester I have two projects in mind:

An AIR Subversion client.
Porting the Squeak Smalltalk core to AS to match the Vista Smalltalk in Silverlight project.

What is Thermo?

2007-10-03T06:41:00.000-07:00

Yesterday at Adobe MAX 2007 in Chicago, I had the pleasure of seeing a sneak peak at a potential future product of Adobe's codenamed Thermo. I'm a developer and not a designer and have never worked with a designer, but I can see the appeal of the product. Plus it is technically cool.

During the demo they took a UI mockup drawn in Adobe Photoshop with layers. Thermo converted that mockup int MXML. The converted MXML had new "graphics" tags that will be added to the language. The graphics tags draw (as you may guess) graphics primitives (boxes, lines, etc), text, images, etc. While not interactive yet, the mockup can be compiled as a Flex application.

Then the magic comes in. Graphics items are selected and turned into controls. For example a box with some text in it was turned into text input. Relatively simple yes, but the compiled Flex app was now interactive. Next they turned a row of Album images with a drawing of a scroll bar in it into a scrollable list of albums. Thermo took the images given to populate the list and could add data, import new images, or just duplicate the images so there was something to scroll.

Interaction was added to the application in the form of a rollover on the albums that zoomed in and showed the title and artist. Overall it was an impressive show of the transformation of graphics to an application.

The "Flex Roadmap" session shed some light on what might be going on behind the scenes in MXML for Thermo (and any other Flex development). From what I hear skinning a control isn't easy (I haven't done so) but the future version will make it easy. They will split the controls into a MVC like architecture with a Skin, Controller, and Model.

The Model encapsulates data, the controller behavior, and skin all of the UI. The skin is all done in declarative MXML using the graphics tags (including transitions). During this demo they showed how to skin a list control to look like a standard list, list with icons, behavior, turning a list into tabs, turing a list into an accordion.

I'm looking forward to the future of Flex.

Shifting Gears to Adobe Flex and C#

2007-09-04T20:01:00.000-07:00

Times change and so do jobs. I'm starting a new job in two weeks working with rich internet applications - Microsoft SQL data store, C# middle-ware, and Adobe Flex GUI. None of which I have any professional experience but I'm eager to learn.

So what this means is that Squeak, Erlang, and Rails take something of a back seat while I learn the technologies for my new job. I plan on dabbling in Erlang and Rails for being the middle-ware for my own personal projects.

Meanwhile, I wrote a Sudoku solver in Flex for my algorithm analysis class.

http://www.arcanearcade.com/Flex/Sudoku/Sudoku.html

Overall I really like the Flex framework thus far. It is nice to know that Flash 9 has a 90% browser penetration, so it makes for a reliable platform for distributing my own Flex applications. The applications look really nice as well - as a Windows application developer I've always found most web applications not quite up to snuff.

New Life For Squeak's UI

2007-08-29T07:10:00.000-07:00

One of my sole complaints about Squeak is its ancient looking user interface and a lack of a standard GUI interface builder. There are a couple of the latter and the community knows about the former and is working to correct things. A squeaker named Gary Chambers is poised to commit some excellent UI improvements:

Go here to see more images.

There is a UI mailing list for Squeak discussing this and other UI improvements.

Reflections on the Demise of Dolphin Smalltalk

2007-08-11T15:13:00.000-07:00

The Smalltalk community lost one of its vendors this week. Dolphin Smalltalk threw in the towel. While reading this post, I reflected on Dolphin's developers and lucky13's comments on Dolphin and open source.

This all reminds me of my first encounter with smalltalk over 10 years ago. I had been a professional C++ developer for a little while and was curious about the origins of object oriented development. After doing a little digging I became interested in learning Smalltalk... until I saw the price tag.

At the time the only Smalltalk implementations I could find on a quick internet search cost hundreds or thousands of dollars. I was interested but not that interested, so I dropped the idea and it has taken years for me to return.

It is hard to win over developers to a new language and even harder when they have to fork over vast sums of money for the privilege. Look at the popular languages for the last few years (Ruby, Python, PHP, Java, Erlang, even C/C++), with all of them the first hit is free. Even Microsoft seems to have caught on in recent years; you have been able to get free versions of Visual Studio for a while and before that there was a command line C# compiler available for free.

While I have often paid for a development tool or library, it has only been after my first free hit. The only reason I have purchased Microsoft Development tools is because of the market pressure for a developer to work in that environment (it is where I make my living, even if C++/MFC/etc. aren't the "best").

I don't think that Smalltalk will die but there are lessons to learn in gaining the hearts of alpha geeks that Smalltalk can learn.

Squeak Smalltalk First Impressions

2007-08-07T09:04:00.000-07:00

As mentioned before, I decided to learn Smalltalk and was interested in Croquet and Seaside. This made the choice of Smalltalk implementations clear - Squeak. So I head on over to squeak.org and download the latest version.

The first thing I notice is that the color choices in the UI are... unexpected and the UI appearance is circa 1980 (I opened a few windows and menus as an example, this isn't what you see at first):

It doesn't bode well when your first impression of a development environment leaves you not wanting to make anything that looks like the environment. But I press on and start playing with the environment.

Smalltalk/Squeak isn't like other languages. Instead of getting a compiler and using your favorite text editor, you are given a whole environment to learn all at once. Squeak is your IDE and just about your whole OS. Smalltalk doesn't use the file system in a conventional sense. Instead everything is stored in the .image file that is essentially a snapshot of the running virtual machine.

Here is a brief translation of the tools you need to know:

Code Editing - Class Browser, there are several to choose from (default, Refactoring Browser, OmniBrowser, Whisker Browser, etc). The default squeak image
Saving Code - Not needed, everything is saved in the image and changes file. You can file out/in code.
Source Code Control - Monticello (or digging out the changes)
Unit Testing - SUnit
Basic Tools

Here is a good place to start for more information on squeak: http://wiki.squeak.org/squeak

Here is a nice programming tutorial in Squeak: http://squeak.preeminent.org/tut2007/html/index.html

Here is an excellent tutorial:

Which Smalltalk?

2007-08-06T05:02:00.000-07:00

There are many Smalltalk implementations to choose from but because of an interest in both Croquet and Seaside, my primary choice would be Squeak. Squeak runs on many platforms (I'm on Mac OS X 10.4), is one of a few implementations of Smalltalk that runs Seaside and is the only one (that I know of) that runs Croquet.

Here is an abbreviated list of Smalltalk environments available:

Squeak - A free cross-platform Smalltalk environment. That I'll talk about more in a later post since I'm using it as my development enviornment.
VisualWorks (Cincom) - A cross platform Smalltalk environment with a free community and commercial editions. They support Seaside (in a big way), look better than Squeak (IMHO), provide great community support with tutorials documentation and screencasts, and have visual GUI editors. The only thing stopping me from using them is that Croquet runs on Squeak and I just want to learn one Smalltalk environment for now.
Dolphin Smalltalk (ObjectArts) - A Windows only Smalltalk environment. There is a free community edition and commercial editions. The product looks nice and has a native look and feel.
Vista/Silverlight Smalltalk - Smalltalk running in Microsoft's Silverlight. Pretty cool and cross-platform through Silverlight.
GNU Smalltalk - POSIX version of Smalltalk. Unlike the others in this list, GNU Smalltalk is less an all encompassing environment and working with it should be more familiar to most developers than the standard Smalltalk way of doing things.
Other versions - There are several other versions of Smalltalk available.

Why Smalltalk?

2007-08-05T06:43:00.000-07:00

In my first post, I mentioned interest in Ruby, Erlang, and Smalltalk. It is easy to understand why the first might be of interest given the large amount of press they have been getting lately. But you may get to the last and ask:

"Why on earth would you be interested in Smalltalk? That ship set sail 30 years ago and hasn't been popular since the 80's. Think you can find a job using that language buddy?"

Popularity and finding a job aren't my motivators for learning Smalltalk, but I do have several other motivations:

Historical - Smalltalk was one of the first object oriented languages (Simula beat it) and as such forms the foundation of much many modern languages. I might learn Lisp for the same reason.
More dynamic than even Ruby - As well as having the equivalent of Ruby's duck typing (you send "messages" to objects in Smalltalk), Smalltalk programs can be changed while the program is running.
Seaside - An interesting web development framework.
Croquet - A peer-to-peer 3D environment similar in concept to Second Life. I'm planning on writing my master's thesis on "Peer-to-Peer Collaborative 3D
Content Creation" using Croquet.
Interesting Environment - Smalltalk is more than a language, it is a complete environment and closer to an IDE or even an OS where you can reprogram everything including the compiler on the fly. More on this later.

I may never make a living (or even a single penny) with Smalltalk, but I think it has valuable lessons to teach me.

Introduction

2007-08-05T06:15:00.000-07:00

I've put off making a blog for a long time, mainly because I didn't have anything I wanted to talk about. Now that I'm embarking on a voyage of discovery on the shores of software development, maybe I can find something interesting to talk about. At the very least I can use the blog as a development log of sorts for my own use. But first, a little about me.

Software development isn't new to me, I've been a professional code monkey for 12 years now. My paying gigs have mainly mainly been in C++Windows, Linux, and Mac OS X programming with a few ventures into Java based web development. In my private time I have played with Perl, Python, and Ruby. I've dabbled in other areas of the industry including technical support, product management, and plain management. I even got an MBA before I learned that management really isn't for me because my passion is programming.

My voyage began recently with a rekindling of my love for development. First I taught a class on software specifications at the local university and then I decided to go get a Masters in Computer Science. These events in turn have ignited an interest in dynamic, functional, and concurrent programming languages; mainly in the forms of Ruby, Erlang, and Smalltalk. More on these in more focused posts later.

My intention is to post at least once a week to capture what I have learned or thought about. I have some catching up to do since I started over a month ago, so there will be a flurry of initial posts.