Weblocks 0.8.3 released

Weblocks is an advanced web framework written in Common Lisp.

It is designed to make Agile web application development as
effective and simple as possible.

WHY YET ANOTHER WEB FRAMEWORK?

This is not your ordinary run-of-the-mill web framework in PHP, Python or Ruby.

Weblocks uses powerful Lisp features like multiple dispatch, the
metaobject protocol, lexical closures, keyword arguments, and macros
to build abstractions that make web development easy, intuitive, and
free of boilerplate. In addition, control flow is easily expressed
using continuations.

Things that are hard or mundane in other frameworks become easy and
fun in Weblocks. A fine example of this are Weblocks’ AJAX capabilities
which relieves you from writing Javascript in a lot of situations.

AUDIENCE

People who want to get their real-life web programming done
as effectively as possible.

Weblocks is not only targeted at old hands but also at
newcomers to Lisp and Lisp web programming.

It offers a helpful community and code that prevents you
from shooting yourself too easily in the foot.

IS IT USABLE? CAN I SEE SOME DEMOS?

Weblocks is well-tested and has proven its worth in daily usage.
It is used by a community of developers all over the world.

Public applications running Weblocks include

CHANGES IN 0.8.3

  • Greatly enhanced performance in the request handler
  • Support for request timeouts
  • Automatic bundling/versioning of static files
  • Rudimentary profiling
  • Fundamentally overhauled nav system
  • CLSQL demo fixed
  • Updated Simple Blog example
  • New HTML error handler
  • More flexible debugger configuration with additional restarts
  • The usual assortment of fixes and contrib/ additions

MORE INFORMATION

Platforms

Well-tested on SBCL and Clozure CL.
Partially tested on CMUCL, Lispworks, AllegroCL, and OpenMCL.

Official site (with detailed installation guide)

http://weblocks.viridian-project.de/

Demo

http://weblocks.viridian-project.de/weblocks-demo

CONTRIBUTORS

This release has been made possible by Nandan Bagchee, Benjamin Collins,
Stephen Compall, Chris Hallwright, Jan Rychter and yours truly.

Starcraft on VirtualBox (and Hamachi)

Rationale

Starcraft on Wine is horribly slow due to the missing DIB engine.

Handling DIBs is a crucial component when it comes to fast 2D drawing. Other games like Age of Empires and even applications like Adobe Photoshop are affected by this weakness in Wine.

Work on this has started last year as a Summer of Code program, but progress has slowed down recently.

All in all I guess we won’t get a usable implementation within the next few years except if another dedicated effort is spent on it.

Enter VirtualBox

Luckily another solution has come up recently: Sun’s VirtualBox virtualization product is free (as in beer and freedom), easy to use and works well enough with Starcraft.

Here’s my basic setup: VirtualBox 3.0.0 (in beta state right now but so far it hasn’t crashed on me) with guest additions, Windows XP and Starcraft Brood War 1.16.1.

I have enabled DirectDraw acceleration and bridging as network mode in VirtualBox. Both are simple point-and-click settings; you need to make sure the vboxnetflt module is loaded, though.

All of Starcraft is usable and very importantly fast.

Resolution issues

Update: You can just use VBoxSDL to start your VM in proper fullscreen mode without jumping through the hoops below. Makes it much more convenient and reliable.

VirtualBox does not have a real full-screen mode. With the guest additions you’re able to get a Desktop that resizes automatically to fit, but fixed resolutions (Starcraft uses 640×480) will not be scaled up to fill the VirtualBox window or the whole screen.

I have tried XRandR but it just made the viewport smaller which is worse than useless.

The kludge here is to copy over your X config, remove all resolutions except for 640×480 and start a new X server. I cannot go into the full detail here but it boils down to this:

xinit /home/sky/scripts/xinitrc.2 -display :1 \
  -- :1 -ac -config xorg.conf.lowres

Put in some lightweight window manager or VirtualBox itself at the end of xinitrc.2.

After that just use VirtualBox as you have before and switch to full screen.

You should be ready to get the full experience of playing Starcraft now!

Bonus: Hamachi integration

Hamachi is a proprietary cross-platform VPN solution that is also beginner-friendly and gratis. It works well with my VirtualBox setup, too.

However the latest version (1.0.3.0) does seem to have some problems with UDP networking.

Downgrading to 1.0.1.4 helped, and I was even able to play Starcraft via a VPN. Don’t forget to turn off the helpful Windows firewall least it might interfere with your network.

Did this post help you?

If yes, then I’d like to know about it. Please also tell me about other games that work or don’t work with this setup.

If you’re really happy about it you may also send me a gift.

Mercurial extensions for git features

I still enjoy work with Mercurial more, although git has grown a lot better in the last few years.

In the last few days I especially noticed that hg is faster for me than git (even after repack of the git repository).

That said, git has some very cool features that are missing in Mercurial.
Two of them are local branches (helpful for feature development or bug isolation) and the stash command that lets you stash away local changes for later (sort of a simplified patch queue).

Fortunately there are two extensions that provide both local branching and stash functionality.

Localbranches extension

Wiki page
http://www.selenic.com/mercurial/wiki/index.cgi/LocalBranches
Repository
http://hg.kublai.com/mercurial/extensions/localbranch

Shelve extension

Wiki page
http://www.selenic.com/mercurial/wiki/index.cgi/ShelveExtension
Repository
http://freehg.org/u/tksoh/hgshelve/

Installation

To use an extension just clone the repository and put the following line into the [extensions] section of your hgrc (create file and section if necessary):

EXTNAME=/path/to/EXTNAME.py

Usage examples are on the wiki pages.

Happy hacking!

Reblog this post [with Zemanta]

Muffling package redefinition warnings (SBCL)

The CLHS says the following about DEFPACKAGE:

If the new definition is at variance with the current state of that package, the consequences are undefined; an implementation might choose to modify the existing package to reflect the new definition.

SBCL opts to modify the package but throws a warning, most often in the form of “PACKAGE also exports the following symbols: …”.

Luckily the warning is a specific one, i.e. SB-INT:PACKAGE-AT-VARIANCE.

So to get rid of the warning the following macro helps:

(defmacro without-package-variance-warnings (&body body)
  `(eval-when (:compile-toplevel :load-toplevel :execute)
     (handler-bind (#+sbcl(sb-int:package-at-variance #'muffle-warning))
       ,@body)))

Apply sparsely.

We need the EVAL-WHEN to ensure that the non-toplevel definition of the package is available at compile time.

There’s a minor catch here. One might be tempted to put the EVAL-WHEN clause inside the HANDLER-BIND. But this leads to the package not being available at compile time (therefore rendering the EVAL-WHEN ineffective) because “the compile-time side effects described in Section 3.2 (Compilation) only take place when eval-when appears as a top level form.” (CLHS on EVAL-WHEN).

Does anyone know how to muffle these redefinition warnings in other implementations?

Weird release policies in PEAR land

I’m not very fond of PHP, but it’s hard to dodge it.

Fortunately the PEAR project has a set of excellent (well, as close to excellency as PHP lets you get…) libraries for all sorts of purposes.

The only thing with them is that they have problems managing their releases. The main site of the popular HTML Quickform library sports a fat warning sign, claiming that this package had been superseded by the aptly named HTML QuickForm 2 package.

That’s funny, because most if not all other packages depending on QuickForm are still built for the old version. Even more funny is what a vanilla install of the PEAR package tool will throws at anyone attempting to install QuickForm2:

% sudo pear install HTML_QuickForm2
Failed to download pear/HTML_QuickForm2 within preferred state "stable", latest release is version 0.2.0, stability "alpha", use "channel://pear.php.net/HTML_QuickForm2-0.2.0" to install
Cannot initialize 'channel://pear.php.net/HTML_QuickForm2', invalid or missing package file
Package "channel://pear.php.net/HTML_QuickForm2" is not valid
install failed

Now take into account that this situation has been in place for at least one year. Not really a role model for a sane software development release process.

Evidence B: Structures_Datagrid and a bunch of other packages are also marked “beta” but have been used by the majority (I daresay) of developers without any problems over the course of the last dekamonths.

What gives, PEAR?

Partial MP3 decoder in Haskell

Here’s a partially conforming MP3 decoder in Haskell.

It looks pretty clean even to me, not being a Haskell programmer.

Who’s up for it in Common Lisp? :)

JES, a KISS mail server

JES is a tiny Java mail server.

Very useful for testing local mail emitting routines.

Usage: download, extract, quickly edit the configuration files and execute bin/mail.sh.

Thanks, Eric!

Threads in SBCL

Working with threads in SBCL isn't obvious in some respects. I'd like to use this post to collect some hints for people starting out with multi-threaded programming in SBCL. Prerequisite: SBCL compiled with threads (still not the default). Check with (not (null (member :sb-thread *features*))).

Usage

All thread stuff lies in the SB-THREAD package, so you need to import it when you don't want to do prefixing:
(use-package :sb-thread)

Creating a thread

(make-thread (lambda () ...) :name "optional name")
Spawns a new thread executing the lambda and return it. The thread will silently terminate when the lambda returns. You can wait for its completion using JOIN-THREAD.

Listing threads

(list-all-threads)
'nuff said.

Debugging threads

Use RELEASE-FOREGROUND to switch between multiple threads waiting for input:
CL-USER(15): (make-thread (lambda () (break)))
 
debugger invoked on a SIMPLE-CONDITION in thread #< thread RUNNING {AA9E831}>:
  break
 
#< thread RUNNING {AA9E831}>
CL-USER(16): (release-foreground)
 
Resuming thread #< thread RUNNING {A93CD49}>
 
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
 
restarts (invokable by number or by possibly-abbreviated name):
  0: [CONTINUE        ] Return from BREAK.
  1: [TERMINATE-THREAD] Terminate this thread (#< thread RUNNING {A93CD49}>)
 
(BREAK "break")3
0] (release-foreground)
Resuming thread #< thread "initial thread" RUNNING {A6DD551}>
CL-USER(17):

Cleaning up

Perhaps this is obvious to someone familiar with the stack semantics of threading:
CL-USER(25): (make-thread (lambda () (unwind-protect (break) (format t "cleanup~%"))))
 
#<thread RUNNING {AB89DB9}>
CL-USER(26):
debugger invoked on a SIMPLE-CONDITION in thread #< thread RUNNING {AB89DB9}>:
  break
(release-foreground)
Resuming thread #< thread RUNNING {AB89DB9}>
 
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
 
restarts (invokable by number or by possibly-abbreviated name):
  0: [CONTINUE        ] Return from BREAK.
  1: [TERMINATE-THREAD] Terminate this thread (#< thread RUNNING {AB89DB9}>)
 
(BREAK "break")
0]
1
Resuming thread #< thread "initial thread" RUNNING {A6DD551}>
1
CL-USER(27): cleanup
</thread>

Miscellaneous notes

Hash tables

Somewhere in time SBCL dropped locking for hash tables to give the user the freedom to implement the level of locking they need. So you need to protect your hash tables for concurrent access or else.

Thread model

There are two fundamental models for a thread framework: rely on the native OS facilities for threading or implement some sort of concurrency scheduling yourself. Allegro uses the latter method while SBCL and ECL use native threading.

HID remotes and LIRC

Nowadays USB HID remotes that act like a keyboard and mouse in one device seem to be popular.

At least I unknowingly got me one and then had problems getting it to run with LIRC.

Fortunately Chris Grove figured out how to make this work, after three weeks of fiddling.

Here’s the recipe.

These remotes register themselves as two HID devices, a keyboard and a mouse. Some keys it sends as keyboard, some as mouse. So first you need to find out which devices it will use:

cat /proc/bus/input/devices

Try to identify the devices and note down the event node name on the line where it says “Handlers”:

[...]
N: Name="HID 05a4:9881"
[...]
H: Handlers=kbd event7
[...]
N: Name="HID 05a4:9881"
[...]
H: Handlers=kbd mouse2 event8
[...]

So mine is at /dev/input/event7 and /dev/input/event8.

Now we need to run an lircd instance for both of them using the dev/input devices and link them. Here’s a script that does this:

#!/bin/sh
 
sudo lircd -Hdev/input -d/dev/input/event7 -o/dev/lircd1 \
  --pidfile=/var/run/lircd1.pid --listen
 
sudo lircd -Hdev/input -d/dev/input/event8 -o/dev/lircd \
  --pidfile=/var/run/lircd.pid --connect=localhost:8765

Done! Everything should work now.

Vim: Substitute in all buffers

To replace all instances of FOO with BAR in one file, you’d do:

:%s/FOO/BAR/g|:up

The pipe | lets you separate multiple commands and :up is like :w but only writes changed buffers.

Now for all open files:

:bufdo :%s/FOO/BAR/g|:up

Roughly translates to: for all open buffers, substitute FOO with BAR and write the changes.

« Previous PageNext Page »