Eskild Hustvedt

wwine 0.3

Just released wwine version 0.3. wwine is wine wrapper that wraps wine, Crossover etc. into a single unified interface, with full bottle support. This version contains several improvements compared to 0.2. It adds additional information to the output of the --kill and --drykill commands. These now lists the bottle and wine flavour the process belongs to when used under Linux. It’s also now possible to combine --kill or --drykill with --wine and/or --bottle, allowing targeted kills of only a single bottle instead of all running processes.

This version also introduces support for wine packages installed via PlayOnLinux. PlayOnLinux supplies many prebuilt wine-packages, easing wine installation and allowing several to be installed side-by-side. wwine reads from the list of installed PlayOnLinux wine packages and adds those to the list of available –wine versions. It also adds support for using PlayOnLinux bottles, so wwine may be used on games and software installed through PlayOnLinux. Users may now use wwine --list to list available wine versions.

Lastly several minor tweaks were made. Including improved support for GameTree Linux, the addition of --cxg-installdir (which compliments the existing --cxinstalldir). A crash that could occur when --wrap was combined with --wine wine without also supplying a --bottle was fixed, and the deprecated parameter --env-bottle was removed.

It is available for download from the wwine website.

Announcing gpgpwd

I’ve just released gpgpwd. It is a simple password manager for people that live on the command-line. It stores a list of passwords in a GnuPG encrypted file, which it then provides an interface for retrieving, adding, changing and removing entries from.

The basics are simple: gpgpwd set X sets the entry for X in the file. The password is not accepted on the command-line, but will be requested interactively to avoid it showing up in ps. gpgpwd will provide you with a randomly generated password that you can use, or you can provide your own. gpgpwd get X retrieves the entry for X (and copies it to the X11 clipboard unless --no-xclip is supplied) - this command takes a regex, so you don’t have to type out the entire name each time. Finally gpgpwd remove X removes the entry for X.

In addition to these basic commands it also has a few extra features to make life a bit more convenient, the main one being git support. You can tell gpgpwd that your password file is inside git, which will make gpgpwd git pull before reading the file, and git commit+git push after writing to it, allowing you to easily synchronize your password between several computers. It also has a command that will let you batch add passwords from a file, if you’re importing passwords you already have stored.

You can grab it from its website, where you can also read the full manpage. If you give it a go and have some feedback, I’d love to hear from you - either in the comments here, via e-mail, IRC or through the github issue tracker for gpgpwd.

wwine 0.2 released

I’ve just released wwine 0.2. It adds support for the new Crossover 11.0 release, which changes some of the paths and needs a bit of additional magic to use. It also has some improvements to the wrapper scripts it generates, primarily through a new and more robust metadata header.

The most interesting new feature however, is the addition of the \–env and \–tricks parameters. \–env causes wwine to set the WINE and WINEPREFIX variables to the syntax used by vanilla wine, this allows various wine scripts that use those to be able to run using wwine’s bottles, as well as with crossover. The most interesting use of this is the ability to use winetricks with Crossover. This effectively lets you use Crossover as any other wine release, while still using Crossover’s bottles. So if you have winetricks and Crossover installed, you need only run wwine -w cx -b BOTTLE --tricks ACTION to use winetricks with Crossover.

Blog migrated to octopress

I have finally gotten around to migrating my blog from wordpress to octopress.

Octopress is “A blogging framework for hackers”. It’s based on jekyll, a ruby framework for generating static websites. What sold me on it is the ability to use the best blog-writing client available, a normal shell along with vim. Blog posts are written in markdown (by default), the source is in git, and it comes with rake targets for creating new posts, building it and deploying it.

As this should make it a lot easier to write posts, I’m hoping that it just might make me post more often.

jqsimple-class 0.1.1

Last week I released version 0.1.1 of jQsimple-class. The main addition in this version is support for using jQsimple-class in CommonJS environments, such as node.js. All one has to do is place the CommonJS build of jqsimple-class somewhere in the include path and then do: var jClass = require(‘jqsimple-class’).jClass; From there on out the API is the same as the browser one. The CommonJS build also has the same testsuite as the normal build, and passes all of the tests.

Outside of that, the standalone build has been stripped down to the bare necessities, shrinking the minified standalone build of jQsimple-class from 10KiB to 3KiB (the version that uses jQuery is just 1.5KiB).

jQsimple-class released

Today I’ve released the first version of jQsimple-class, a small JavaScript class-declaration library. The reason I wrote it is that the usual way of building classes in JavaScript is frankly quite ugly, and inheritance is equally ugly. With jQsimple-class I’ve tried to make it as simple and intuitive as possible to write classes in JavaScript. The library itself is very small, and the syntax is simple. It’s meant to let you quickly declare a class, and easily extend others, and then get completely out of your way. It only exports a single variable/function, named jClass (Class is a reserved word in JavaScript, so I went for the next best thing). Using jClass, and methods on it, it is possible to build classes, virtual classes and extend classes.

jClass() takes a single parameter, a JavaScript hash, where keys are method or attribute names, and the values are any valid JavaScript type. jClass.extend() lets you build a class that extends one or more existing classes. jClass.virtual() lets you construct a “virtual” class. That is to say, a class that can not be instantiated, but that can be extended by others.

Internally jQsimple-class uses some jQuery methods, but it does not depend upon jQuery to be used, a standalone version that bundles the parts it needs (not all of jQuery, and without exposing them to the public namespace) is available for applications that do not use jQuery. I have written an extensive testsuite for jQsimple-class to make sure that things work as they should, and it works across all modern browsers.

For more examples and the full API, see the jQsimple-class documentation. jQsimple-class version 0.1 is available for download now. Minified it is only 1.5K (or 9K for the standalone version). Any feedback is welcome, feel free to do so in the comments, or, if you find a bug, on the bugtracker.

A very simple one-liner REPL for perl

Here’s a very simple one-liner REPL for perl, it’s not very advanced (like ie. re.pl) but does well in most cases: perl -MData::Dumper -MTerm::ReadLine -e ‘$r = Term::ReadLine->new(1);while(defined($_ = $r->readline(“code: “))){$ret=Dumper(eval($_));$err=$@;if($err ne “”){print $err;}else{print $ret;}}’

It uses Term::ReadLine, which gives a simple session history if you have a Term::ReadLine::* implementation that supports it. It will also use Data::Dumper so that you can quickly see any data structures, you can always use scalar(STATEMENT) if the return value differs in list and scalar context.

Here’s an alias that can be shoved into .bashrc : alias ‘perl-repl’=’perl -MData::Dumper -MTerm::ReadLine -e ‘'‘$r = Term::ReadLine->new(1);while(defined($_ = $r->readline(“code: “))){$ret=Dumper(eval($_));$err=$@;if($err ne “”){print $err;}else{print $ret;}}’'‘’

SWEC 0.4

About two weeks back I released SWEC version 0.4. The largest new thing in this release is an updated file format for writing test definitions. Thew new format is a lot more flexible, and will also allow me to extend its syntax with more capabilities more easily later on. It can still read the old file format, and I’ll keep the compat code in there until SWEC 0.6 - so people have time to update their files (only minor changes are needed to update them to the new file format, should only take a couple of minutes).

Other than that I extended the command-line parser, so you can now say “swec example.com -s /test.html“ where you would previously have had to do “swec --baseurl example.com -s /test.html“. Other than that it’s mostly a bunch of cleanups, some refactoring and a few minor bugfixes, in addition to a new test suite so the thing can be properly sanity-checked before release.

If you need to sanity check dynamic websites, give SWEC a go.

Fixing PHP documentation woes

I prefer writing in Perl or Ruby, but sometimes the choice of language has been made by someone else, a position I have found myself in lately. When using perl and ruby, there’s always perldoc and ri, so documentation is a quick command away in any of my terminals, which thanks to screen is never fewer than ten. PHP however, has no such tool, the docs are in HTML and many distros don’t even package the HTML docs. So, to avoid the pain of switching out of the safety of my terminal and into a web browser all the time, and speed up my work, I wrote an app, phpdocr. It’s quite simple, it scrapes php.net (and caches the result for quick viewing later) and displays the parsed HTML in your pager - resulting in something sort of like perldoc or ri. So if you have the same itch, grab it from http://random.zerodogg.org/phpdocr.

The app itself, of course, is not written in PHP - it’s written in ruby.

Sanity checking mason

I have found myself doing quite a bit of mason at work lately, both maintaining old legacy stuff and as the view in a catalyst app.

While doing this I found myself missing the old ‘perl -c’ to quickly sanity check code, however naturally that won’t work on Mason - as mason is essentially HTML with inline perl, not the other way around. As such I wrote a quick script that emulates ‘perl -c’ by loading the file using mason inside eval then printing any errors. The script itself is pretty simple, though it doesn’t have any support for printing useful line numbers - but at least it gives an idea of what/where the problem is. The script also declares $c and $m, as at least for Catalyst - those will be available.

You can clone the gist, or just copy+paste the code: