What the Hell, XDG?
Take a look at the XDG Base Directory Specification. It looks good, doesn't it? It really makes sense to have some "official" directories to store this kind of stuff in. Now look at the default locations listed:
$XDG_CONFIG_HOME - Looks like they nailed that pretty well. I might rather see some user-editable config files placed directly in '~/.app/', but '~/.config/app' is alright as a second choice.
$XDG_CACHE_HOME - Dead on. It is incredibly nice to have a single home for all those nasty little cache files that are a little too persistent to place in '/tmp'.
$XDG_DATA_HOME - Okay, it's a little bit ugly to store extra data in '~/.local/share', why couldn't they just put it in '~/.local'? But on the other hand, most applications don't even need extra data of that sort anyway, and it will rarely, if ever, be edited by a human, so it's at least a little bit acceptable.
$XDG_DATA_DIRS - Yeah, they're back on form for this one. Those two default directories cover basically every app in existence, so not a single fault can be found there.
$XDG_CONFIG_DIRS - WHAT THE FUCK! Why the hell do they decide every application needs to store their system-wide configuration in a special '/etc/xdg' directory? On my system, I count a grand total of three applications in there, of which I use one and have configured zero. For comparison, I count 157 files and directories in '/etc', other than '/etc/xdg'. Obviously, people will kind of expect to see their system-wide config files placed directly in '/etc'
What reason can there be for that kind of annoyance? When I have to go in and manually edit a system-wide config file, I will look for it in '/etc'. It would never even have occurred to me to look in '/etc/xdg'. At the very least, couldn't the default search path have been '/etc/xdg', followed by '/etc'?
This kind of trivial little issue weakens the entire specification, because such a seemingly inconsequential little rough edge can completely sour people's opinions of the whole document. And it would be a shame if that happened, because I would rather see the majority of these things become common convention.
Useful Haskell List Function
I keep finding myself with a long list of elements, which I need to split into a list of lists of those elements. For example, I need to go from [0,1,2,3,4,5,6,7,8] to [[0,1,2],[3,4,5],[6,7,8]]
So far, the best function I have found to do this is
But that seems a little bit overcomplicated for such a simple function. Am I missing a better, more obvious solution?
Escaping Strings in a Shell Pipeline
A useful little sed script I wrote, which turned out to be much more useful than I expected. It simply takes a list of files, one per line, and outputs that same list, but with all the spaces and special characters escaped. It's mainly intended for use right between find and xargs, as in "find . -name 'asd' -print | shell-escape | xargs -I % echo %'
The list of characters is taken from IEEE Std 1003.1
#
# Shell-Escape
# A very basic script to escape characters in the shell.
# Mainly intended for use in shell pipelines, right between
# 'find' and 'xargs'
#
s@\\@\\\\@g
s@ @\\ @g
s@'@\'@g
s@"@\\"@g
s@(@\\(@g
s@)@\\)@g
s@|@\\|@g
s@&@\\&@g
s@;@\\;@g
s@<@\\<@g
s@>@\\>@g
s@`@\\`@g
Haskell: A Pretty Nice Language
I was going through one of those "every language sucks" periods a few days back, so I decided to do something productive and learn me a Haskell. So far, I'm liking it: the pure functional style isn't as hard as I expected, monads are okay after a bit (though I'm still a little suspicious of them), the strict typing isn't too much of a burden, the polymorphic types are bliss to use, and the pattern matching is simply wonderful. It also comes with an extensive set of libraries and a central repository, which is nice to find in a non-mainstream language. Overall, I think Haskell is a good language to know.
Super-Makefile has levelled up! SuperMakefile became BashBuild!
I had just about reached the limits of what was possible with just a makefile, but I still felt like adding more. So I rewrote the thing today as a shell script. Now, you simply call it as './configure', and it generates the Makefile for you. The script is still configured in much the same manner as the old Makefile, except now you don't have to specify a compiler.
More importantly, the rewrite has allowed a whole bunch of new tricks, including:
- Command-line specification of the install prefix
- Now the commands are familiar to anyone who has ever done a "./configure && make && sudo make install" before
- Out of source builds are now implemented
- Autodetection of the C compiler
And most importantly:
- Plenty of room to grow
Unfortunately, the code took a major step backwards in attractiveness. Over the next few days I may tinker around with it in an attempt to make it not look quite so bad, and possibly move more logic out into the configure script.
Other major news of the day: I finally dumped bzr for git, just so I could use GitHub. The new project is named BashBuild.
Revenge of the Super-Makefile
So today I found some more things that the old Makefile was lacking. An "install" target, a ".PHONY" target to prevent breakage down the line, and the ability to recursively build subprojects. A few hours later, I have this:
VERSION=0.0.1
SOURCES=bar.c baz.c
SUBPROJECTS=xyzzy fnord
LIBRARY=-lm
INCPATHS=xyzzy fnord
LIBPATHS=fnord
PREFIX=/usr/local
LDFLAGS=
CFLAGS=-c -Wall -g
CC=gcc
# ------------ MAGIC BEGINS HERE -------------
# We want subprojects to use these variables
export CC
export PREFIX
# Automatic generation of some important lists
OBJECTS=$(SOURCES:.c=.o)
INCFLAGS=$(foreach TMP,$(INCPATHS),-I$(TMP))
LIBFLAGS=$(foreach TMP,$(LIBPATHS),-L$(TMP))
# Set up the output file names for the different output types
ifeq "$(LIBRARY)" "shared"
BINARY=lib$(PROJECT).so
else ifeq "$(LIBRARY)" "static"
BINARY=lib$(PROJECT).a
else
BINARY=$(PROJECT)
endif
all: $(SOURCES) $(SUBPROJECTS) $(BINARY)
$(BINARY): $(OBJECTS)
ifdef SOURCES
# Assemble the object files into the right type of binary
ifeq "$(LIBRARY)" "static"
ar rcs $(BINARY) $(OBJECTS)
else ifeq "$(LIBRARY)" "shared"
$(CC) -shared $(LIBFLAGS) $(OBJECTS) $(LDFLAGS) -o $@
else
$(CC) $(LIBFLAGS) $(OBJECTS) $(LDFLAGS) -o $@
endif
endif
$(SUBPROJECTS):
make -e -C $@
.c.o:
$(CC) $(INCFLAGS) $(CFLAGS) -fPIC $< -o $@
install:
@ for i in $(SUBPROJECTS); do make -e -C $${i} install; done
ifdef SOURCES
ifeq "$(LIBRARY)" "static"
install $(BINARY) $(PREFIX)/lib
else ifeq "$(LIBRARY)" "shared"
install $(BINARY) $(PREFIX)/lib
else
install $(BINARY) $(PREFIX)/bin
endif
endif
distclean:
rm -f $(BINARY) $(OBJECTS)
@ for i in $(SUBPROJECTS); do make -C $${i} distclean; done
clean:
rm -f $(OBJECTS)
@ for i in $(SUBPROJECTS); do make -C $${i} clean; done
.PHONY: all clean distclean install $(SUBPROJECTS)
It's longer, but not by too much, and now I can safely say it has everything I have ever needed in a fancy build system. It would be nice if I could get pretty colourized output, but this Makefile reliably builds, cleans, and installs the projects I have tested it on.
The Super-Makefile
After toying with build systems off and on for months, I concluded today that make is about as advanced as I ever need to get for my projects. In the past, I recall using this gem of a Makefile. But my needs in a build process have grown a little. First of all, I now prefer C to C++, so that had to be changed. Then I had to go about adding static and shared library abilities to it. Then I added "clean" and "distclean" build targets, and include and library search paths got introduced somewhere along the way.
After good half hour of modification, I had the following Makefile, posted here mainly so I can find it easily from any computer. By modifying the first six variables defined in the Makefile, it can be adapted to almost any C project of reasonable complexity. It has no support for cross-platform library identification, out-of-source builds, or debug and release build toggles. But on the other hand, I can never get those things to work right any way.
Toggling between static library, shared library, and executable build modes is performed by setting the LIBRARY variable to "static", "shared", or anything that isn't those two values.
SOURCES=bar.c baz.c
LIBRARY=nope
INCPATHS=../some_other_project/
LIBPATHS=../yet_another_project/
LDFLAGS=-ldosomething
CFLAGS=-c -Wall
CC=gcc
# ------------ MAGIC BEGINS HERE -------------
# Automatic generation of some important lists
OBJECTS=$(SOURCES:.c=.o)
INCFLAGS=$(foreach TMP,$(INCPATHS),-I$(TMP))
LIBFLAGS=$(foreach TMP,$(LIBPATHS),-L$(TMP))
# Set up the output file names for the different output types
ifeq "$(LIBRARY)" "shared"
BINARY=lib$(PROJECT).so
LDFLAGS += -shared
else ifeq "$(LIBRARY)" "static"
BINARY=lib$(PROJECT).a
else
BINARY=$(PROJECT)
endif
all: $(SOURCES) $(BINARY)
$(BINARY): $(OBJECTS)
# Link the object files, or archive into a static library
ifeq "$(LIBRARY)" "static"
ar rcs $(BINARY) $(OBJECTS)
else
$(CC) $(LIBFLAGS) $(OBJECTS) $(LDFLAGS) -o $@
endif
.c.o:
$(CC) $(INCFLAGS) $(CFLAGS) -fPIC $< -o $@
distclean: clean
rm -f $(BINARY)
clean:
rm -f $(OBJECTS)
Fixing Broken Macros with Eval and Quasiquote
Recently, I found myself needing to deal with a "convenience" macro, which quoted several of its arguments for me before passing them along to the real function. Unfortunately, only the macro was exported from the library, and I was unable to access the base function.
(syntax-rules ()
((_ arg1 arg2) (much-harder-function 'arg1 'arg2))))
How useful. To save me a handful of quotes, I lose the ability to programmatically generate my arguments.
As I was loath to reimplement the entire library just to regain that ability, I looked for another solution. Thankfully, I found one.
(eval `(convenient-function ,arg1 ,arg2)
(environment '(convenient-lib))))
As far as I can tell, this circumvents the macro's quoting features entirely to allow me to pass in a dynamically generated symbol. While it won't work with functions which modify the environment, it worked well in my case, and allowed me to move on to more interesting code.
SRFI-0 for Detecting Scheme Implementation
I found out earlier today that SRFI-0 can be used to determine the host Scheme in some cases. Here is the result of my testing, in case someone finds it useful:
No SRFI-0 by default:
- mzscheme
- ikarus
- scheme48
Name exported for cond-expand:
| Scheme Name | SRFI-0 Feature Name |
| CHICKEN | chicken |
| Guile | guile |
| Bigloo | bigloo |
| Gambit | gambit |
| MIT Scheme | mit |
| Gauche | gauche |
Runtime Scheme Detection
I really want my code to be "write once, run anywhere", at least as far as Schemes go. R6RS library features make strides toward that goal. Only, there's not many R6RS Schemes. Since there are a whole lot of R5RS ones, I'd like to include R5RS in the portability fun.
In many cases, enough functionality appears in all major implementations to make some major steps toward portability. So a while back, I decided to get a few things out of the way (you know, processes, FFI, things like that).
To make simple, portable libraries, we need to find out some details about the Scheme implementation the code is running under. Unfortunately, there is no standard way to do this. We could just call a function and see if it worked, but then we throw an error, and there's no standard way to trap those in R5RS. And even if a function of the given name existed, we still don't know what arguments it takes, because that differs too.
So we're left with some sort of indirect detection method, guessing the implementation based on a bunch of unrelated tests.
So I gathered a list of as many nonstandardized/undefined behaviours as possible (mainly from this table, and grepping the R5RS spec for the word "undefined"). Then I filtered those differences down to a bunch of tests that won't error out. Then I took the tests that gave meaningful results, and because I had enough of those to be picky, I took only tests which fit on a single line.
The resulting set of 20 tests generates a sort of "signature" -- a list of twenty boolean values that identifies the host Scheme.
Currently the code works on:
- MzScheme
- CHICKEN
- Guile
- Bigloo
- Gambit
- Ikarus
- Scheme48
- MIT Scheme
- Gauche
This is actually a list of all the implementations I have installed right now, and other implementations can be supported just by adding another line to the signatures list.
On Scheme implementations which provide a compiled and an interpreted mode, only interpreted has been tested (I don't really know how to use a compiled Scheme, so I didn't). Some Schemes have different behaviour interpreted and compiled, so caution should be used there.
Enough talk, here's the code:
;;; DETECT
;;; A set of functions to allow an interpreted Scheme
;;; program to determine the implementation it is
;;; running under.
;;;
;;
;; DETECT:SIGNATURE
;; Assemble a signature for the current
;; Scheme implementation.
;;
(define (detect:signature)
(list
;; AXCH: exact-sqrt
(exact? (sqrt 4))
;; AXCH: exact-times-zero
(exact? (* 0 3.1))
;; AXCH: exact-div-zero
(exact? (/ 0 4.7))
;; AXCH: exact-rationals
(exact? (/ 1 3))
;; AXCH: case-sensitive
(eq? 'a 'A)
;; AXCH: promises-are-thunks
(procedure? (delay 3))
;; Do strings made from numbers less than 1 omit the 0?
(string=? ".5" (number->string 0.5))
;; AXCH: literal-rationals
(number? (string->number "1/2"))
;; AXCH: literal-complexes
(number? (string->number "1+i"))
;; Is the empty string eqv to itself?
(eqv? "" "")
;; How about the empty vector?
(eqv? '#() '#())
;; A non-empty string?
(eqv? "a" "a")
;; Does SET! have a constant return value?
(let ((x 0)) (eqv? (set! x 1) (set! x 'asd)))
;; Is it equal to other undefined things?
(eqv? (for-each (lambda (x) #t) '(0 1 2)) (let ((x 123)) (set! x 321)))
;; Are negative and positive inexact zero the same?
(eq? +0.0 -0.0)
(eqv? +0.0 -0.0)
(equal? +0.0 -0.0)
;; Is the default vector filled with zeroes?
(equal? (make-vector 5) '#(0 0 0 0 0))
;; Is the default vector filled with falses?
(equal? (make-vector 5) '#(#f #f #f #f #f))
;; Vector-fill returns a vector?
(vector? (vector-fill! (make-vector 1) 0))
))
;;
;; DETECT:KNOWN-SIGNATURES
;; A precalculated list of signatures for all supported
;; Scheme implementations.
;;
(define detect:known-signatures
'((mzscheme (#t #t #t #t #f #f #f #t #t #f #f #f #t #t #f #f #f #t #f #t))
(chicken (#f #f #f #f #f #f #f #t #f #f #f #f #t #t #f #t #t #f #f #f))
(guile (#f #t #f #t #f #f #f #t #t #t #f #f #t #t #f #f #t #f #f #f))
(bigloo (#f #f #f #f #f #t #f #f #f #f #f #f #t #t #f #t #t #f #f #f))
(gambit (#t #t #t #t #f #f #t #t #t #f #f #f #t #t #f #f #f #t #f #f))
(ikarus (#f #f #f #t #f #t #f #t #f #f #f #f #t #f #f #t #t #t #f #f))
(scheme48 (#f #f #f #t #t #t #f #t #t #t #t #t #t #t #t #t #t #f #f #f))
(mit-scheme (#t #t #t #t #t #f #t #t #t #f #t #f #f #f #f #t #t #f #t #f))
(gauche (#f #f #f #t #f #f #f #t #t #f #f #f #f #f #f #t #t #f #f #f))))
;; DETECT:MATCH-SIGNATURE
;; Determine the name of the current Scheme implementation
;; by checking the signature returned by DETECT:SIGNATURE
;; against a table of known signatures.
(define (detect:match-signature)
(let ((signature (detect:signature)))
; Loop over the DETECT:KNOWN-SIGNATURES list
(let test ((siglist detect:known-signatures))
(if (equal? '() siglist)
; Return 'UNKNOWN if we're stumped
'unknown
(let ((testsig (car siglist)))
(if (equal? (cadr testsig) signature)
(car testsig)
(test (cdr siglist))))))))
;;
;; DETECT:NAME
;; Memoized form of DETECT:MATCH-SIGNATURE
;;
(define detect:name
(let ((memo #f))
(lambda ()
(and (not memo)
(set! memo (detect:match-signature)))
memo)))
Obviously, only the memoized DETECT:NAME is meant for general use, since a program generally won't the see the host changing as it runs, and repeatedly calculating the name would be inefficient. I don't actually have much experience with Scheme, so the DETECT:MATCH-SIGNATURE function could probably be written more efficiently, but it works.
Anyway, I hope that someone finds this to be useful. I have used it to write the beginnings of a portable process library. More on that after I get around to polishing it up a bit more.