Jul 31: Features in PHP trunk: Array dereferencing

I was writing about new features in the upcoming PHP version (5.4, 6.0?) before. Today's topic reads like this in the NEWS file:
- Added array dereferencing support. (Felipe)
Now you might wonder what this typical short entry means. when doing OO-style PHP you might make use of a sntax feature which one might call "object dereferencing" which looks like this:
<?php class Foo { public function bar() { } } function func() { return new Foo(); } func()->bar(); ?>
So one can chain method calls or property access. Now for a long time people requested the same thing for array offset access. This was often rejected due to uncertainties about memory issues, as we don't like memory leaks. But after proper evaluation Felipe committed the patch which allows you to do things like
<?php function foo() { return array(1, 2, 3); } echo foo()[2]; // prints 3 ?>
Of course this also works with closures:
<?php $func = function() { return array('a', 'b', 'c'); }; echo $func()[0]; // prints a ?>
And even though the following example is stupid I might accept this feature as one of the few places where it is ok to use references in PHP:
<?php $data = array('me', 'myself', 'you'); function &get_data() { return $GLOBALS['data']; } get_data()[2] = 'I'; // $data will now contain 'me', 'myself' and 'I' ?>
Wonderful, isn't it? If you want to test it please take a look at the recent snapshots for PHP trunk and send us your feedback! Please mind that all features in PHP trunk may or may not appear in the next major PHP release.
Jul 25: ZFS and VirtualBox
With ZFS you may not only do "file system" stuff but ZFS may also provide raw block devices ("zvol") which benefit from ZFS space accounting, snapshotting, checksumming, etc. A purpose of these is to use these zvols and exporting them via iSCSI or give them to applications which can store data on them. One application for this I'm using s VirtualBox and as I always forget the exact commands needed to create a zvol and making it available to VBox I decided to write it down.
Reasons for me for using zvols instead of regular VBox disks are that I can easily snapshot them (every 15 minutes a snapshot ...) individually and can easily clone them (around one second and barely any disk space needed to get a clone of a VM to do some experimental stuff...) and incremental backups using snapshots and zfs send. That said there's at least one - possibly - negative factor: A regular virtual disk file can be shared with other people and other operating systems, a zvol has to be dumped into a regular vmdk first.
Anyways here are the steps needed:
# zfs create -V 10G tank/some_name # chown johannes /dev/zvol/rdsk/tank/some_name # VBoxManage internalcommands createrawvmdk \ -filename /home/johannes/VBoxdisks/some_name.vmdk \ -rawdisk /dev/zvol/rdsk/tank/some_name # VBoxManage registerimage disk /home/johannes/VBoxdisks/some_name.vmdk
So first we create the zvol with a size of 10G. This won't be allocated but everybody asking for the size of the device will get this information back and this is the maximum size that will be used - as one can use compression and dedup there this often might be way less usage. Then, as I'm running VBox under my user account, I give my user all the rights needed by making the regular user the owner. The third step creates a vmdk file pointing to the raw device location which is then registered with VirtualBox so a VM can be configured for using it.
Works nicely.