News

PHP 5.3.2 support

2010-03-09T20:35:26+01:00

Following the PHP 5.3.2 release a couple of days ago we now officially support this new PHP version with the upcoming XP 5.7.8-RELEASE. Also tested successfully: The 5.8 development branch.

RFC #0197: Type literals in tokens

2010-02-18T16:48:59+01:00

Scope of Change
A common way to denote type literals in generated sourcecode will be introduced.

Rationale
An example of where this is used is the type dispatching methods described in RFC #0195. Another example is generics generation, as described in RFC #0193.

Read the full RFC here

RFC #0193: Generics optimization

2010-02-18T16:47:54+01:00

Scope of Change
Generics will be optimized.

Rationale

Improve performance
Enable reflection for generics
Enable reflective creation of generics
Support primitives a generic arguments

Read the full RFC here

Command line reflection

2010-02-16T11:11:16+01:00

The xp command line tool has a new command line switch, -r, which will print reflection information about a class, interface or enum.

Output of: xp -r io.streams.FileInputStream
This feature will be available with the next XP release, 5.7.8. If you're using an SVN checkout, you will need to update the runners as follows:

  $ cd ~/bin
  $ wget 'http://xp-framework.net/downloads/releases/bin/setup' -O - | php

SVN moved

2010-02-15T18:40:04+01:00

The XP repositories "xp", "xpforge" and "xpdoc" have been moved to a new server, xpsrv.net. To fix your local SVN (development and/or anonymous) checkouts, use the following commands:

1. Find out the checkout URL

  ~/devel/xp/trunk$ svn info . | grep ^URL
  URL: svn+ssh://friebe@xp-framework.net/home/svn/xp/trunk

2. Use svn switch. The new URL is the same except for the hostname!

  ~/devel/xp/trunk$ svn switch \
    svn+ssh://friebe@xp-framework.net/home/svn/xp/trunk \
    svn+ssh://friebe@xpsrv.net/home/svn/xp/trunk

(The backslashes indicate wrapped lines and are not part of the command)
Done!

Bind server sockets to any free port

2010-02-01T16:00:15+01:00

At the company I work for, we let the XP Framework's unittest run on various different machines, including Windows 2008 server and 32- as well as 64-bit Debian Linux boxes, with PHP versions ranging from 5.2.0 - 5.3.1 (lots of permutation, yes).

On some of the newer machines we have configured Hudson to start multiple test runners at the same time. This lead to problems with the integration tests (for the FTP API, for example) where we actually fork off a standalone server in the background: The port in use was hardcoded. While this is perfectly OK normally, with mutiples suites executing simultaneously and trying to bind the same port, we were running into problems.

Merging XAR files

2010-01-30T15:05:05+01:00

With the 5.7.7-RELEASE there has a nitfy small feature been added to the xar command: merging multiple XAR files. XAR files are the archives in which XP Framework applications can ship their classes and/or resource files in a way comparable to Java`s .jar-files.

Combining multiple xar files into one can be handy one the one hand, because you can merge all dependencies and the application itself into one single file and only have to provide the one. On the other hand, for applications where startup or I/O performance is a concern, it can be useful: each xar file involved in an application comes with a startup time penalty - the file must be opened, the index must be read before the first file can be retrieved. Here, a single file instead of many files mean increased startup performance and less I/O calls of an application.

This is how it works:


Alex@mobile ~/dev/xp.public/trunk
$ xar cf one.xar ChangeLog

Alex@mobile ~/dev/xp.public/trunk
$ xar cf two.xar skeleton/VERSION=VERSION

Alex@mobile ~/dev/xp.public/trunk
$ xar mf merge.xar one.xar two.xar

Alex@mobile ~/dev/xp.public/trunk
$ xar tvf merge.xar
    58.978 ChangeLog
        10 VERSION

5.7.7-RELEASE

2010-01-26T17:55:25+01:00

The XP team is proud to announce the availability of the 5.7.7-RELEASE, featuring improvements to the web test API, support for reading and creating zip files (RFC #0175) and zip compressed streams , easy access of standard input in command line classes as well as several overall improvements and bugfixes.

XP on a Mac

2010-01-24T11:38:18+01:00

Continuing our series of trying to get the XP Framework run on as many platforms as possible, here's our newest achievement:

So far we have:

Windows: Windows XP, Windows 7, Windows Vista, Windows 2008 server
BSD: FreeBSD 5, 6 and 7
Linux: Gentoo, Ubuntu, Debian (3.1, 4.0, 5.0)
Mac: OS X 10
Other: Nokia 770

If you have XP running on a platform besides these, let us know and we'll add it here

XP Framework & APC

2010-01-24T11:20:16+01:00

Recently, I got an email from Jan, who has to websites running the XP Framework and who had upgraded his PHP to 5.2.12, asking for assistance with these sites being disfunctional and the following extracts from the web server's error log:

  [Sun Jan 17 12:46:43 2010] [error] PHP Fatal error:  Interface 'Generic' not found
  [Sun Jan 17 12:37:34 2010] [error] PHP Fatal error:  Allowed memory size ... exhausted

After some research work we found out the problem wasn't caused by the new PHP version but instead by the APC extension he had installed. We can reproduce this problem even on the command line, and it seems to be related to PECL . The workarounds suggested in this bug that work for some only relieve these problems partially, although a simple site then works the XP core unittests show that there are still problems.

The XP Framework team suggests not to use APC with the XP Framework for the time being.

Windows runners

2010-01-15T16:48:04+01:00

The Windows runners provided with the XP Framework were not shutting down PHP correctly when Ctrl+C was pressed in the shell. In Windows console windows this can be easily worked around by setting the Console.CancelKeyPress property to a delegate which will kill the executed PHP runtime. If any of the XP runners was run from inside a Cygwin shell though, this is not possible - see - Cygwin simply kills the XP runner - and we thus cannot do anything (an experiment with a WMI monitoring process seemed to work but caused problems in certain circumstances) and you will have to continue to taskkill /f /pid XXXX'ing the "left-over" PHP processes manually

A bugfix for this problem has been comitted to the XP Framework and will be available in the upcoming 5.7.7-RELEASE. If you're using an SVN head checkout (and are using Windows), you should update the runners as follows:

  $ cd ~/bin
  $ wget 'http://xp-framework.net/downloads/releases/bin/setup' -O - | php

BSD Runners

2010-01-10T18:00:51+01:00

The XP runners could fail under certain circumstances on BSD operating systems if the /proc filesystem was not mounted. This is due to the fact that the FreeBSD kernel does not keep command lines longer than kern.ps_arg_cache_limit in memory and we rely on the command line an XP application was started with including arguments being available in the lang.Runtime class.

A bugfix for this problem has been comitted to the XP Framework and will be available in the upcoming 5.7.7-RELEASE. If you're using an SVN head checkout (and are using FreeBSD), you should update the runners as follows:

  $ cd ~/bin
  $ wget 'http://xp-framework.net/downloads/releases/bin/setup' -O - | php

Reading gzip'ed websites

2010-01-08T20:44:56+01:00

To reduce bandwidth some servers have their content zipped using solutions such as Apache's mod_deflate. This is done only if the Accept-Encoding request header contains the string gzip. Combining the XP Framework's peer.http API with the new io.streams.GzDecompressingInputStream one can accomplish this compression:

 
  $conn= new HttpConnection($args[0]);
  $response= $conn->get(array(), array('Accept-Encoding' => 'gzip'));
  
  if ('gzip' == $response->getHeader('Content-Encoding')) {
    $in= new GzDecompressingInputStream($r->getInputStream());
  } else {
    $in= $r->getInputStream();
  }
  
  // Now read $in as with any other stream...

Compressing data

2010-01-06T17:09:40+01:00

The possibly easiest way to compress data in PHP is to use the string-in, string-out functions such as gzdeflate or bzcompress. For small number of bytes being passed in, this is fast and convenient, but it doesn't do well when working with large files, for example:

 
  FileUtil::setContents(
    $out, 
    gzdeflate(FileUtil::getContents($in))
  );

In one test I ran here, this piece of code used roughly 50MB peaks to compress a 26 MB input file. As of 5.7.7, the XP Framework will provide compressing output streams enabling you to compress one chunk at a time and saving more than 90% of memory:

 
  $is= $in->getInputStream();
  $os= new DeflatingOutputStream($out->getOutputStream());
  while ($is->available() > 0) {
    $os->write($is->read());
  }
  $is->close();
  $os->close();

Sure, this is more code, but it constantly uses not more than 0.5 MB while running. If you now have a look at the new io.streams.StreamTransfer class you can simplify the above code even more (and still save the memory).

FTP API Class constants

2009-12-28T10:27:53+01:00

The global constants FTP_ASCII and FTP_BINARY have been replaced inside the peer.ftp package by class constants in the FtpTransfer class. Although these resolve to the same integer values and no change to existing sourcecode is required, the class constants are the preferred and portable way.

 
  $conn->rootDir()->file('index.txt')->uploadFrom(
    new FileInputStream(new File('index.txt')),
    FtpTransfer::ASCII          // instead of: FTP_ASCII
  );