Monthly Archives: April 2004

Stumbleupon


This is probably the best web app I have seen in the past year. Select some categories and press “STUMBLE!” to view a random site. So simple yet so accurate. If you rate the sites you stumble, the system learns making your next stumble better than the last. &

Here are some CS Links I found on a recent stumble:

Unix History

Procedural over OOP

Structure and Interpretation

.GNU (C# for Unix & osx)

Wow, the Internet is fun again!

ted ;)

Python, not the snake…


In a discussion on Darron Schall’s site, I talked a bit about Python as a language. I thought I would post a more comprehensive listing of Python information for those interested. &

What is Python? (from python.org)

Python is an interpreted, interactive, object-oriented programming language. It is often compared to Tcl, Perl, Scheme or Java.

Python combines remarkable power with very clear syntax. It has modules, classes, exceptions, very high level dynamic data types, and dynamic typing. There are interfaces to many system calls and libraries, as well as to various windowing systems (X11, Motif, Tk, Mac, MFC). New built-in modules are easily written in C or C++. Python is also usable as an extension language for applications that need a programmable interface.

The Python implementation is portable: it runs on many brands of UNIX, on Windows, OS/2, Mac, Amiga, and many other platforms. If your favorite system isn’t listed here, it may still be supported, if there’s a C compiler for it.

The Python implementation is copyrighted but freely usable and distributable, even for commercial use.

Python

JPython (Python interpreter in Java)

Stackless Python (tasklets,coroutine,greenlets)

Links

Quick Reference 2.3 HTML

Why Python? (oreilly)

Why Python? by Eric Raymond

What is Python?

ActiveState – What is Python?

Guido van Rossum (Python’s Creator)

The StarShip

Python Success Stories

Vaults of Parnassus

Extending and Embedding Python

C functions in Python

Books

Learning Python

OOP in Python (PDF)

Jedi Handbook

Jpython

Libraries

Modual Index

Asyncore (Asyncronous Sockets)

Pickle (Object Serialization)

RE (Regular Expressions)

Twisted Framework

SPARK – little language framework

4Suite XML

WXPython (Cross Platform GUIs)

Users

Success Stories

Python Users

Google

Inktomi

Ultraseek (Verity)

AstraZeneca (Drug Discovery)

BEA

Rackspace

Nokia

Yahoo Groups

ILM (Lucas)

IronPort == BSD+Stackless+Email

Disney

Zope

Plone

WingIDE

Actionscript Editor SEPY


Borrowed from the Python Humor

EXTERIOR: DAGOBAH — DAY

With Yoda strapped to his back, Luke climbs up one of the many thick vines that grow in the swamp until he reaches the Dagobah statistics lab. Panting heavily, he continues his exercises — grepping, installing new packages, logging in as root, and writing replacements for two-year-old shell scripts in Python.

YODA: Code! Yes. A programmer’s strength flows from code maintainability. But beware of Perl. Terse syntax… more than one way to do it… default variables. The dark side of code maintainability are they. Easily they flow, quick to join you when code you write. If once you start down the dark path, forever will it dominate your destiny, consume you it will.

LUKE: Is Perl better than Python?

YODA: No… no… no. Quicker, easier, more seductive.

LUKE: But how will I know why Python is better than Perl?

YODA: You will know. When your code you try to read six months from now.

Python is for “Monty Python” not the snake.

Cheers,

ted ;)

Component Observations – Part 3


Picking up where I left off last month, I wanted to talk about the nature of components in Flash. Components are pre-built software that is designed for reuse. Although, in Flash, the real question is when are they reused? At runtime or compile-time? &

In Flash at runtime, components consist of 4 basic parts:

1. MovieClips (via Library Assets – attachMovie or keyframe clips)

2. Methods (typically via Class inheritance)

3. Properties (typically via Class inheritance)

4. Constructor (create classes, MC to class binding, data instantiation)

In Flash MX, Flash MX 2004, and Flex, components are packaged in an author-time/compile-time format using either FLA or SWC formats. These formats depend on a compiler toolset to properly include assets from the FLA/SWC into the end SWF using compile-time pragma, initClip and on(activate). These author-time components also provide design-time features by exposing properties and previews to the developer. With few notable exceptions, most component technology in Flash is based on an authortime model and requires a compiler that understands the component format. Binding a component format to an authoring tool is good for the toolbuilder but leaves the end developer little flexibility in regards to tool selection or tool portability. If COM was bound only to Microsoft development tools both legally (EULA) and technically, COM would not be the success that it is today.

What I find disturbing about this is that the Flash Player and the SWF format has been component-oriented since version 4 with the addition of loadMovie. LoadMovie was specifically designed to allow the player to extend itself in a nested, distributed manner at runtime. If I needed a block of content, you could load a SWF into a container movieClip that rendered the nested content. What is great is that neither clip needs to know anything other than a url and that loaded file is a SWF. From an actionscript perspective, the boundary layer between the 2 SWF files is seamless, with the exceptions of a different _url property and domain security issues. Worse still is the fact that the V1 and V2 component sets are difficult to load externally. Making this work requires an act of congress and a very deep understanding of the specific component architecture.

Looking back at my first point, components are a collection of simple parts, it makes sense to assemble parts into a component instance from an XML definition. Essentially you could build a component instance by rendering its parts at runtime from XML. There are some issues that must be overcome:

1. Class Instantiation Order (initClip) would need to be made compatible in a runtime model. Currently class instantiation order is sorted in the flash compiler via the initClip pragma. This prevents broken __proto__ references within classes at runtime. Classes can be loaded in a way to allow them to install their dependent classes automatically. If I loaded mx.controls.Button class, mx.controls.SimpleButton, mx.core.UIComponent, mx.core.UIObject should load and be instantiated in reverse order preserving __proto__ references. Also if the class is already present, the class is skipped in the loading process.

2. XML Pseudo Library – In the absence of Library assets (attachMovie failure) content needs to be created. By overloading the attachMovie method, you can build child clips inside a single attachMovie call. If I say attachMovie(com.flow.Button, ‘myButton’, 23) where com.flow.Button is an XML string, it should render the component defined within the XML document. Working in this manner also preserves existing library based methodologies that are in use in V1 and V2. A great side effect is that components are instantiated inside the attachMovie call eliminating the instantiation delay waiting for the next frame to process the newly added movieclip.

3. Instance Data – Components need to be merged with instance data to provide their functionality. Ideally there is a single constructor method for each component that merges instance data with the component properties in an organized manner. Ideally this would be compatible with XML so that higher level XML tools would be compatible.

4. Asset Loading / Preloading – It makes sense for a project to load assets in chucks to allow them to be cached in the browser. Assuming 2 applications use the same components, neither should be forced to reload embedded components that simply add to file size. Instead they should be obtained and assembled in a distributed manner. In testing it is ideal to separate a components class, dependent classes, and movieClip assets into separate SWF files. The movieClip assets become the component skin files where the skin file is loaded, class is attached and the component instance is assembled from parts. This also provides compatibility with the attachMovie SWF library rules. An interesting side effect here is that skins of many components can be consolidated into a single file or shared library. Assuming that Button, CheckBox, Tree share similar library assets (they do in V1 & V2) it makes sense to preload this one skin file and reuse it across all component instances.

Example:

What excites me about this model is that I could make changes to the component at runtime. Assuming the above was a button, I could add an icon by simply inserting a node provided it was supported in the constructor. It also makes sense that should I need a component in a project that it could be loaded via a URL into my project.

Components are not complex at runtime, but currently they are tough to create and reuse in a flexible manner (not to mention legally). I don’t think it is just me, it is time for a new component model for Flash.

More to come,

Ted ;)