Experiments

XP on NodeJS: Class constants, annotations, stacktraces

More work has been put into the XP on NodeJS experiment: The compiler now knows how to correctly emit class constants and annotations, and a couple of minor bugs have been fixed. The bigger efforts have gone into stabilizing the XP "Microkernel" (which is what I've decied to call the miniature XP Framework implementation written in JavaScript and adopted to NodeJS as well as Windows Scripting Host):

• We're finally getting inheritance right (or are we ? - )?
  
• Class path is now assembled via class.pth files
  
• Classes can reside freely inside any of the class path elements
  
• Stack traces are now shown, including method names and arguments
  
• Parent class reflection now works
  
• The entry point scripts (tools/node.js and tools/cscript.js) are now generated from a common base
  
• When these are invoked without arguments, they show version and classpath info
  

XP on NodeJS: Flow control, exceptions, loops

The XP on NodeJS experiment continues to grow, with the following now implemented:

• Flow control, via if / else
  
• Exceptions, try, catch, throw and finally
  
• Loops - foreach, for, do and while
  
• ARM blocks
  

XP on NodeJS

Following discussions with Claus and Alex, with the XP compiler's long-thought-about strategy of enabling us to decouple the framework and the platform in mind, and based on the "JSXP" experiment I had started about a year ago, I created a first draft of a write-once, compile, run-multiple approach.

This is the starting point, the XP language in a file called Greet.xp.

public class Greet {
  protected string $greeting = 'Hello';
  
  public void printGreeting(string? $name) {
    util.cmd.Console::writeLine($this.greeting, ' ', $name);
  }
  
  public static void main(string[] $args) {
    new self().printGreeting($args[0]);
  }
}

Userland database driver implementations

Following a discussion we had about software packaging for our test, qa and live clusters (most of which run Debian Lenny, meaning it brings PHP 5.2.6 with the mssql extension, unfortunately unsuitable for ASE 15 / univarchar fields), we decided two things:

1. We need to compile a more recent PHP version with sybase_ct ourselves
2. We should investigate in more independence from installed system libraries and PHP extensions

Extension methods: Swiss army knives without the anti-pattern

The following calls a method called "sorted" on an instance of the lang.types.ArrayList class. The ArrayList class doesn't have such a method, and we'll thus get a nice "call to undefined method" error shortly before our program is terminated.

  $array= new ArrayList(3, 1, 2);
  $sorted= $array->sorted();

GUI API redesign

The XP Framework's GUI apis date back to the PHP4 / GTK1 days and have not been touched since then. In desparate need of an overhaul, and following the PHP-GTK2 releases and the stability provided by its PHP5 backing, I began an experiment to redesign the API from scratch.

Watch the experiments' arena/gnome directory for more!

XP Runners in C#

The XP runner infrastructure (as described in RFC #0166) provides a flexible way to run the XP framework without having to configure PHP's system-wide include_path. Besides the already existing implementation in /bin/sh, there's now an implementation in C# (using the .NET framework 3.5). Apart from being a training project for my C# skills, it's also five times faster than using shell scripts on Windows via Cygwin:

http://experiments.xp-forge.net/xml/browse?arena,xprt,csharp

PHP 5.3 Experiments

All the experiments with the newest PHP version can be found at the XP Forge's 5.3 experiments.

Compiling the XP framework

Lately I was experimenting with the PHP extension bcompiler, which offers an API to write the opcodes generated from zend_compile() to files. For a general understanding of this you must know that PHP is a compiled language (but does compilation into memory and then executes that instead of compiling to disk and then running that). The compilation step is not exposed to the user in any way, and there is no defined serialization format for compiled PHP. This is where bcompiler comes in.

Note: Compiling PHP sourcecode does not improve runtime performance, it simply saves the (small) overhead generated by the compile step. My main focus in this experiment was not performance, though, but to test the ability to generate PHP bytecode, and if that would work transparently alongside PHP sourcecode.

HttpService

There's already been a couple of people out there implementing a web server in userland PHP. From my point of view, people are doing this for fun, or as proof-of-concept, and those experiments usually tend to fade out of sight and disappear from public interest - so my guess is that they're not seriously being used.

At 1&1, we actually have such software running in PHP - multiple instances of FTP daemons which serve the purpose of attaching functionality to uploaded files (when an image is uploaded in this directory, update the underlying database), an application server called "Peking" that stores when a customer care agent has opened a customer's contract, and a real-time-logger that stores extracts of Windows Media Server logfiles transmitted via network into a MySQL database for billing reasons. All of these process thousands of requests every day and handle database and LDAP failures gracefully, and all of them have stable memory usage.

As a word for all disbelievers, daemons in PHP are possible!

To demonstrate how this works with the XP framework, I've written a web server implementation using the peer.server package.

Subscribe

You can subscribe to the XP framework's news by using RSS syndication.

Categories