Strange Clocks is a set of Home Screen Widgets, each of which calculate and display time in an unusual way:

1. Binary Clock – Displays the time in Binary, by converting H:M:S into “Binary” values. (3×3 Widget)
2. Decimal/Metric Clock – Displays the time using a Decimal clock – the day is split into 10 hours, which have 100 minutes. Each Centiminute has 100 seconds. (3×1 Widget)
3. Hexadecimal Clock – displays the time in Hex (base-16) format. (3×1 Widget
4. Octal Clock – Displays the time in Octal (base-8) format. (3×1 Widget
5. Percent Clock – Displays the percentage of the day passed. (3×1 Widget
6. Reverse Percent Clock – Displays the percentage of the day left. (3×1 Widget
7. Backwards Analog – A standard Analog clock, in reverse. (3×3 Widget)

There’s a Free version and a Donate version (50p / 99c). Both are fully functional, but the Donate version contains several skins to change the colour of the LCD (Blue, Green, Dark Green and Red) and Text/Foreground (White, Black and Green).

One annoyance I have found to be somewhat of a show-stopper is that the Shell seems to crash on a fairly regular basis. I’m still trying to work out what is causing the crash – it could be one of the few extensions I have installed and modified to get the system looking and feeling the way I want, or some other bug related to the Shell, ATI Graphics driver, Xserver…

Unfortunately, when the shell crashes, the application windows remain, but all the panels and shell related stuff vanishes. It’s also not possible to use Alt-F2 to bring up the Run command widget, from which it’s possible to simply run “r” to reload the shell. Instead, I have had to find a couple of alternative methods to reload the shell. One is particularly drastic, and involves killing the whole Gnome session – not good if you have work to save etc. The other just replaces the shell.

The “Nice” Method

This method will replace the Gnome shell using tty1. As a result, all output from the gnome-shell command will be output to standard output on tty1, although this can be redirected to /dev/null or somewhere else if desired. To use this method, press Ctrl-Alt-F1 to change the display to tty1, and login if necessary. Then run:

DISPLAY=:0 gnome-shell --replace

This effectively tells the system to redirect the gnome-shell –replace command to tty7, i.e. the Xserver.

Once done, press Ctrl-Alt-F7 to return to Gnome.

The more aggressive method

This method will completely restart the Gnome session, killing any open applications in the process. This really is a last resort, and rather horrible method. Once again, press Ctrl-Alt-F1 to change the display to tty1. Once there, run:

ps aux | grep 'gnome-session'

You should see a few lines of output. What you’re looking for is (most likely the first line) the line similar to this:

username 4321 0.0 0.1 00000 00000 ? Ssl 09:48 0:00 /usr/bin/gnome-session --session=gnome

Where “username” is your username. Look specifically for “/usr/bin/gnome-session –session=gnome”. The number in the second column (after the username) is the value we’re after – in this case “4321”. This is the PID (Process ID) for gnome-session, and the value required to kill the session:

sudo kill -9 4321

This should kill the crashed Gnome Shell session, and start a new one. The display should also be returned to tty7, and the Login screen (if not, press Ctrl-Alt-F7).

If anyone else has any alternative, or better methods, please feel free to comment below.

for dir in `ls`;do cd $dir; tar -cvzf $dir.tar.gz *;mv $dir.tar.gz ..; cd ..;done

This will run an ls command, and temporarily save the output for use in the For loop. The code loops through each part of the ls output, moves into the current directory (assuming it is a directory), creates the archive and moves the archive file to the parent directory, before moving itself to the parent directory to begin again with the next part of the ls output.

So, for example, if you have the following directory structure:

/home
--username
----stuff_to_archive
------dir-to-archive1
------dir-to-archive2
------dir-to-archive3
------dir-to-archive4
------dir-to-archive5

and you wish to archive dir-to-archive1 through dir-to-archive5, and all the contents therein, you would run:

cd /home/username/stuff_to_archive
for dir in `ls`;do cd $dir; tar -cvzf $dir.tar.gz *;mv $dir.tar.gz ..; cd ..;done

The code will loop through each directory and archive its contents into a file named after the directory (e.g. dir-to-archive1.tar.gz), leaving you with:

/home
--username
----stuff_to_archive
------dir-to-archive1
------dir-to-archive1.tar.gz
------dir-to-archive2
------dir-to-archive2.tar.gz
------dir-to-archive3
------dir-to-archive3.tar.gz
------dir-to-archive4
------dir-to-archive4.tar.gz
------dir-to-archive5
------dir-to-archive5.tar.gz

If you want to use ZIP instead, then run:

for dir in `ls`;do cd $dir; zip $dir *;mv $dir.zip ..; cd ..;done

or replace the archiver command with whatever you want to use to compress the directory contents.

You’ll need to register to post, but anyone can read them. I’ll eventually be on the look out for moderators, and the forums may possibly even lead to enlisting future guest writers for 64 Bit Jungle too.

They’re obviously looking a little sparse at the moment, since they’ve only just opened, but please don’t let that put you off registering and posting to kick things off.

Enjoy!

sudo apt-get install kcachegrind

Anyone who has installed KCachegrind on a Gnome system before, or who has just run the above command, can see that it takes approximately 250Mb (after installation – about 80Mb worth of archives to download) of additional libraries and packages in order to install. I still have it installed, and use it for more detailed analysis of profile data, but I recently stumbled across a fantastic alternative called Webgrind.

Installing Webgrind

Webgrind implements a subset of the KCachegrind features, and is great for a quick preview, or simple analysis of profile data. It’s written in PHP5, and as such leaves a very small footprint, and can be installed on any platform. To install, download the latest package (1.0 at the time of writing) – as usual I downloaded to my cluttered Desktop, which by now is brimming with things I’ve forgotten about, and whose purpose I no longer have any idea… Once downloaded, the package needs unpacking, and moving to the root web directory (/var/www in my case)

cd ~/Desktop
unzip webgrind-release-1.0.zip
sudo mv webgrind /var/www

Once installed, Webgrind can be accessed by pointing your web browser to http://localhost/webgrind

Profiling

In order to profile an application, the Xdebug profiler needs switching on. This can be done by editing either the php.ini file, or in my case, a separate ini file specifically for Xdebug. Either way, the following line needs adding, so open up the ini file in a text editor, and add:

xdebug.profiler_enable = 1

Save the file and restart Apache:

sudo /etc/init.d/apache2 restart

Your PHP web application will now be profiled by Xdebug. By default, profile data will be saved in /tmp/cachegrind.out.%p (where %p is the pid). This can be changed by editing php.ini and adding the following directives:

xdebug.profiler_output_dir = /desired/output/directory/path
xdebug.profiler_output_name = desired.name.specifier

(See http://www.xdebug.org/docs/all_settings#trace_output_name for possible specifiers). To switch profiling off, simply edit the php.ini file, set  xdebug.profiler_enable to 0 and restart Apache.

Viewing Profile Data

Once profile data is available, Webgrind will automatically detect the latest profile, and give the option to display it. Point your web browser to http://localhost/webgrind. At the top are three pull down menus – the centre menu allowing us to select which profile data file to view. By default, it will automatically select the latest file, but others can be manually selected based not only on Xdebug’s default filename, but also by the actual PHP file profiled. Clicking the Update button will begin the analysis process (which may take some time depending on the size and complexity of the profile data) resulting in data being displayed in tabular format, which allows for drill down and sorting:

KCachegrind can be used for more detailed analysis, but for a quick view of potential bottlenecks in code, and considering its size, Webgrind is a fantastic starting point, which for me, picks out the most relevant data I need to analyse, which is sufficient 90% of the time.

64 Bit users have a little more work to do, but the process is not too difficult. First, we have to download the relevant packages, and all the dependencies:

• Eclipse gtk 3.5M6 200903130100 (64 Bit)
• PDT 2.1.0M6 Runtime
• EMF 2.5.0M6 S200903161215
• DLTK (Core) R1.0 1.0M6 200903161640
• DLTK (RSE) R1.0 1.0M6 200903161640
• GEF 3.5.0M6 S200903161602
• WTP (WST) 20090318020101 R3.1 3.1M6
• XSD 2.5.0M6 S200903161215

I downloaded them all to a directory called “Galileo” on my Desktop. The rest of the process uses the command line, so open up a Terminal, and navigate to the directory containing the downloaded files:

cd ~/Desktop/Galileo

The first task is to extract the main Eclipse package, and optionally move it to a new home – I chose to install it in ~/galileo/eclipse

tar -zxvf eclipse-SDK-3.5M6-linux-gtk-x86_64.tar.gz
mkdir /home/[USERNAME]/galileo
mv eclipse /home/[USERNAME]/galileo

Eclipse has utilised the p2 Installer, and a “dropins” directory – which is scanned by the p2 Installer whenever Eclipse is executed – since Ganymede 3.4M6. If p2 finds any Features or Plugins, they are installed upon startup. The p2 Installer also allows placing plugins into their own directory structures within the dropins directory, making installing, organising and testing plugins much easier. Of course, this isn’t as easy as using the Update Manager, but it’s very convenient for our purposes of testing pre-release plugins, since they can easily be deleted/upgraded etc. Anyway, I digress – my original point was that we need to extract, and organise each of the packages downloaded above, then move them into the dropins directory:

DLTK Core:

cd ~/Desktop/galileo
unzip dltk-core-sdk-S-1.0M6-200903161640-incubation.zip
mkdir dltk-core & mv eclipse/ dltk-core

DLTK RSE:

unzip dltk-rse-sdk-S-1.0M6-200903161640-incubation.zip
mkdir dltk-rse & mv eclipse/ dltk-rse

EMF:

unzip emf-runtime-2.5.0M6.zip
mkdir emf & mv eclipse/ emf

GEF:

unzip GEF-SDK-3.5.0M6.zip
mkdir gef & mv eclipse/ gef

PDT:

unzip pdt-runtime-2.1.0M6.zip
mkdir pdt & mv eclipse/ pdt

WTP-WST:

unzip wtp-wst-sdk-S-3.1M6-20090318020101.zip
mkdir wtp & mv eclipse/ wtp

XSD:

unzip xsd-runtime-2.5.0M6.zip
mkdir xsd & mv eclipse/ xsd

Finally, we need to move all these new directories containing the plugins, to the Eclipse dropins directory:

mv dltk-core dltk-rse emf gef pdt wtp xsd /home/[USERNAME]/galileo/eclipse/dropins/

That’s the installation complete. We now just need to run Eclipse with the -clean option. This may take a while as p2 scans the dropind watch directory for the new plugins:

cd /home/[USERNAME]/galileo/eclipse
./eclipse -clean

Since it’s the first time we’re running Eclipse, it’ll also ask where the Workspace directory is located. I just chose /home/[USERNAME]/galileo/workspace to keep everything together.

Once Eclipse is loaded, click the “Workbench” button, then go to the Window -> Open Perspective -> Other menu, and select PHP.

The same method can be used to install and test the Nightly Builds of PDT 2.1 – just visit http://www.eclipse.org/pdt/downloads, expand the latest link under the 2.1.0 Nightly Builds heading, download the latest build and the required dependencies, and install using the same methods outlined here.

So, on to the code itself, which is actually rather embarrassingly simple:
<?php
//Set the Image source variables
$backgroundSource = "http://www.64bitjungle.com/wp-content/themes/openbook22-en/images/rss-subscribe.jpg";
$feedBurnerStatsSource = "http://feeds2.feedburner.com/~fc/64BitJungle?bg=151515&fg=ffffff&anim=0";
//Create new images
$outputImage = imagecreatefromjpeg($backgroundSource);
$feedBurnerStats = imagecreatefromgif($feedBurnerStatsSource);
//Grab width and height of the FeedBurner image
$feedBurnerStatsX = imagesx($feedBurnerStats);
$feedBurnerStatsY = imagesy($feedBurnerStats);
//Merge the two images
imagecopymerge($outputImage,$feedBurnerStats,156,50,0,0,$feedBurnerStatsX,$feedBurnerStatsY,100);
//Output header
header('Content-type: image/png');
//send new image to browser
imagepng($outputImage);
imagedestroy($outputImage);
?>

Now for the breakdown of each line. First, I put the source images into a couple of variables – the background image, located at http://www.64bitjungle.com/wp-content/themes/openbook22-en/images/rss-subscribe.jpg:

and the FeedBurner badge, located at http://feeds2.feedburner.com/~fc/64BitJungle?bg=151515&fg=ffffff&anim=0:

$backgroundSource = "http://www.64bitjungle.com/wp-content/themes/openbook22-en/images/rss-subscribe.jpg";
$feedBurnerStatsSource = "http://feeds2.feedburner.com/~fc/64BitJungle?bg=151515&fg=ffffff&anim=0";

The next significant lines, tell GD to create two new image link resources from the sources above:

$outputImage = imagecreatefromjpeg($backgroundSource);
$feedBurnerStats = imagecreatefromgif($feedBurnerStatsSource);

The FeedBurner badge is delivered as a GIF, hence the imagecreatefromgif function, and the background image is in jpeg format, so we call the imagecreatefromjpeg function. Next, we grab the height and width of the FeedBurner image using the imagesx and imagesy functions, and stick the values in a coupe of variables:

$feedBurnerStatsX = imagesx($feedBurnerStats);
$feedBurnerStatsY = imagesy($feedBurnerStats);

and then run the important function, imagecopymerge, to combine the two images:

imagecopymerge($outputImage,$feedBurnerStats,156,50,0,0,$feedBurnerStatsX,$feedBurnerStatsY,100);

Finally, the image is output to the browser in PNG format:

header('Content-type: image/png');
imagepng($outputImage);
imagedestroy($outputImage);

That’s it – painfully simple, eh? Now all that’s required is to include the new image in some (X)HTML Markup – note that the src of the image, points to the PHP file, not to a traditional JPG etc.:

<img src="http://www.64bitjungle.com/wp-content/themes/openbook22-en/subscribe-image.php" alt="Subscribe to RSS Feed" />

Et voila:

The font, by the way, is “SF Fedora”.

The new theme is based on the English version of Open Book, developed by Jean-Baptiste Jung and which in turn is based on Darren Hoyt’s Mimbo. I’ve spent a little time making some modifications to the theme over the past few days, tweaking it to my liking, and I’ll probably spend more time over the coming weeks cleaning up some code, and tweaking some more. It’s always the same when you get a new toy.

The site should be easier to navigate. I still need to do a lot of work on streamlining categories, and optimising existing posts, their categories, tags and so on – although I’m somewhat reluctant, since I don;t want to damage any inbound links to existing posts!

That’s pretty much it. I hope you all like the new design, and find it easy to use. For the sake of sentimentality, there’s a screen shot of the old site design with this post…

As much as I love the i3Theme, I’m getting fidgety, and feel like dressing 64bitjungle up in a new outfit. I’m just making some tweaks and changes to the new theme, trying to get everything the way I want it – could take a couple of hours, or a couple of days. We’ll see!