Now, every Lisp dialect I know contains at least three fundamental procedures, namely cons, car and cdr. And so does Scheme, a main Lisp dialect. In the spirit of The Seasoned Schemer, we can describe what cons, car and cdr do, namely

(car (cons 1 2))
=> 1
(cdr (cons 1 2))
=> 2

So far there is nothing mind boggling, admitted. Assume now that there is no car, cdr and no cons. All we have is lambda and define where lambda allows us to express a anonymous procedure and where define allows us to give something a name. Just charged with this, can we still implement cons, car and cdr?

The boggling thing is, yes we can. Here we go:

(define cons (lambda (a b) (lambda (m) (m a b))))
(define car  (lambda (z)    (z (lambda (x y) x))))
(define cdr  (lambda (z)    (z (lambda (x y) y))))

Let’s see whether this works as expected:

;; declare a variable z to contain a tuple (1,2)
(define z (cons 1 2))
;; try car and cdr
(car z)
=> 1
(cdr z)
=> 2

It works. It’s mind boggling, isn’t it?

So how does it work anyway? The result of (cons ..) is just a procedure which happens to remember the arguments passed. That procedure is a value like any other. However, that procedure value can also be called with one argument which is expected to be a procedure again. Let’s assume that we have a procedure foo somewhere, then we can do something like ((cons 1 2) foo) and we end up in (foo 1 2), as by the definition of cons above.

So if we want to express car, then foo must be (lambda (x y) x) while in the case of cdr, foo becomes (lambda (x y) y). All what is left is to define car as procedure with one argument and calling that argument with foo, i.e.

(car z) =>
(car (cons 1 2)) =>
((cons 1 2) (lambda (x y) x)) =>
(lambda (1 2) 1) =>
1

This is a well known bug. To make Wireshark run again, try to delete your local X11 font cache, i.e.

$ rm -rf $HOME/.fontconfig

That should do it.

However, when I tried to install such an event handler beast via Plesk | Server | Event Handler | Add New Event Handler I ended up in an error message like Error: Some fields are empty or contain an improper value for which add did not have any explanation. Much, very much later, I discovered that I had copied the path of my script to be executed via copy-n-paste into that Plesk command field. That copy contained whitespace at the end of the command, i.e. something like

/path/to/handler.sh\n

which is enough to make Please grumpy. What’s more, it’s all about whitespace (blanks, tabs, newline etc) at the end of a command while whitespace within the command is accept without any rumble:

echo > /dev/null

That works fine.

Summary:

When entering an event handler command, make sure that there is no whitespace at the end of the command.

Flaka is an extension for Ant. A main project goal of Flaka is the
simplification of writing a build script.

Flaka provides:
1. an expression language (Java Unified Expression Language)
2. well known programming elements (for, when, switch, choose, ..)
3. exception handling
4. additional types, tasks and macros

A small teaser script to demonstrate some of those features:

<project xmlns:c="antlib:it.haefelinger.flaka" name="Flaka" >
  <c:logo>
    Hello #{ project.name ? project.name : ''}!
  </c:logo>
  <c:for var=" f " in=" ''.tofile.list ">
    <c:when test=" f.isfile ">
      <c:echo>
        ;; report basename and modification time
        file #{f.name} last modified: #{ f.mtime }
      </c:echo>
    </c:when>
  </c:for>
</project>

Flaka’s Google Project Page is
http://code.google.com/p/flaka

Manual
http://flaka.googlecode.com/files/flaka.pdf
(* Part I of this manual contains a broad overview of
features Flaka has been charged with *)

Jar (ready to be used – no additional dependencies required)
http://flaka.googlecode.com/files/ant-flaka-1.01.jar

Development Package (rebuild from scratch)
http://flaka.googlecode.com/files/flaka-1.01.zip

Issues should be reported to:
http://code.google.com/p/flaka/issues/list

More information on Flaka at
http://code.google.com/p/flaka ; and
http://workbench.haefelinger.it/flaka

Regards,
Wolfgang Häfelinger

I install those two web applications myself rather than using MacPorts to do so. The installation is basically nothing more than unzipping the distribution package and to modify the configuration files to make sure they connect to my MySQL database on my localhost. However, while installing Wordpress went smooth, I run into database connection failures when installing Mediawiki. It took me some time to figure out what is going on here.

If you have weird connection problems using PHP and MySQL then try one or both of the following solutions:

• Solution: Use 127.0.0.1 instead of localhost as host of your MySQL database server. This has a rather surprising effect, see below.
• Solution: Change your PHP’s configuration file, which is /opt/local/etc/php5/php.ini, to contain the following two lines:
  1. Tell PHP about the Unix domain socket to use

        mysql.default_socket = /opt/local/var/run/mysql5/mysqld.sock
     

  2. In addtion make sure that PHP’s save mode is off (notice that this feature has been deprecated and removed in PHP 6), otherwise your previous modification will be gracefully ignored:

         safe_mode = Off
     

  Notice that in addition you need to restart your Apache web server so that your changes are taken into account. You can do that with apachectl restart.

Background Information

Neither Mediawiki nor Wordpress (nor most other PHP based web application accessing MySQL) implement the gory details how to connect to a database. Usually they just delegate this to mysql_connect();, a API function provided by PHP.

PHP in turn uses the functionality of a (shared) library provided by MySQL, i.e. the MySQL driver. MySQL allows you to connect to the database via two routes:

1. via Internet sockets (TCP/IP); and via
2. UNIX domain sockets

So, how does one choose between this two routes? The answer is rather surprising. MySQL decided to give localhost a new meaning. If you specify localhost, then the UNIX domain socket route is chosen. If you say 127.0.0.1 instead, then you connect via an Internet socket. While this is probably the most natural thing for those MySQL folks, it’s a rather confusing fact for all other humans. It is rather carved deep in our brain for years now that 127.0.0.1 and localhost is the same thing.

After I have changed both Mediawiki and Wordpress to use localhost I had for the first time a situation where both web applications behaved in the very same way. They both did not work. Then, when I changed to 127.0.0.1, both worked fine. Btw, notice that localhost is the default hostname used by Mediawiki while 127.0.0.1 is the default host suggested by Wordpress.

Using 127.0.0.1 is usually fine, however I do want to use the UNIX socket and I was wondering what went wrong.

The problem is that MacPorts MySQL port patches the original MySQL sources to use socket /opt/local/var/run/mysql5/mysqld.sock instead /tmp/mysql.sock. This change is not particular well documented. One would assume that this kind of change goes into an appropriate my.conf configuration file. That’s actually not the case. Even worse, MacPorts MySQL port does not even ship with such a configuration file.

Changing the default socket location is one thing, not telling us and the PHP5 maintainer this is another sin. So, while MySQL happily uses that weird socket location, PHP5 still expects /tmp/mysql.sock. In other words, PHP and MySQL are not working out of the box when using MacPorts. At least not when relying on Unix domain sockets. It does work when using Internet domain sockets cause that default port, being 3306, has not changed. Btw, the MacPorts maintainer of PHP and MySQL is one and the same person. Sounds familiar? Yes, I also have been thinking about Dr. Jekyll and Mr. Hyde. No serious. I assume that there is a serious reason why this does not work out of the box as we all wish. I just don’t get it.

So just assume that you have create a new subdomain and you want to make your CSS files available via /css instead of going via some hardwired domain URL. So all you want to have is an alias like

Alias /css "/path/to/my/css/folder"

Ok, but where to enter? When you look at the folder structure and files created by Plesk it is by no means clear what to do. But hey, what are manuals good for anyway? What you discover is that Plesk created a folder like

  /path/to/domain/subdomains/subdomain/conf

for your subdomain. The folder is empty. It would be really great if Plesk would in addition create a README file in that folder. That file would then state something like this:

To configure your subdomain, add herein a file name vhost.conf. Put any Apache configurations in this file you like but be aware that this file is being included in a virtual host definition.

 $ /usr/local/psa/admin/sbin/websrvmng --reconfigure-all

Good luck and have a nice day.

Unfortunately, that README file is missing. Unfortunately.

This is XeTeX, Version 3.1415926-2.2-0.9995.2 (TeX Live 2009)
entering extended mode
[..]
** WARNING ** Failed to convert input string to UTF16...

and I had no explanation where this might come from. After a divide-and-conquer debugging session, it turned out that my input was just fine. It was rather a setting that caused this warning:

\hypersetup{
     ..
     unicode=true          %  causes UTF-16 warning
}

After having removed that line, all UTF-16 warnings are gone.

iSync screenshot with device Nokia 2720 added.

The easiest way to install this plugin is by using the nokia-2720a-2.dmg installer package. When being used, the plugin will be installed in folder /Library/PhonePlugins/. To support other installation locations, other package formats have been uploaded as well. To support a private installation, create folder ~/Library/PhonePlugins then download an untar package nokia-2720a-2.phoneplugin.tgz within this folder. Eventually restart iSync and try adding your device again.

Eventually I would like to say that it did not work out for me. All too often I found myself trying to set the default values I have just discarded in my reset.css style-sheet. Ignoring inconsistencies for the moment, the I would like to state that usually all default properties are rather wisely chosen and contain exactly what you want when writing an article, a posting whatever.

Inconsistencies start to matter when designing a website. Then browser inconsistencies can have disastrous effects (like two divs are not side-by-side floated cause they don’t fit in the given width by perhaps just one pixel). However it’s just a small part of the website which needs precision rendering and not the whole website.

So, instead of setting the padding of all divs to be

div { padding: 1px 0; }  /* avoid margin collapsing */

I propose to reset only where it matters:

#header, [..], #footer, #header div, [..], #footer div, #content-main {
  padding: 1px 0; /* avoid margin collapsing */
}

Please notice that divs are reset in all grid elements except within #content-main (supposed to hold your page its informational content). Therein, default values are just fine.