Using the App Store to download Xcode-5.0.2 isn’t enough, one has to select the proper command-line tools. Now the trouble with upgrading is that invoking
“xcode-select –install”
right after the upgrade won’t work. I personally had to shut down the machine and restart the OS in order to get it to pop-up the selection window … (probably a reminder of the previous Xcode ?)
The most tricky point with that strange behaviour of xcode is that most build will be okay, probably because of older binaries or
settings of previous xcode being used, but some package will definitely be reluctant (ex: openmotif) ; so
check carefully that step before continuing further.

There is a complete documentation for this, particularly about saving the list of port installed.
Now, when running into a lot of troubles, one will probably go fast and might forget some steps. Or rather, like it occurred to me, partially crash the previous install by trying a port selfupdate right after the OS upgrade !
Anyhow I backed-up the former port tree and some off the apps installed:

mv /opt/local /opt/local-OLD
cd /Applications/Macports && for NOM in * ; do mv "${NOM}" "${NOM}-"`date '+%Y%m%d-%H%M'` ; done

From that point, whenever the old list of ports was needed, I used the following ugly trick :

sqlite3 -line /opt/local-OLD/var/macports/registry/registry.db "select * from ports" | grep 'name =' | sed 's/^.*name = //' | sort -u

At this point, with nothing in the way anymore, I simply downloaded macports-2.2.1-10.9 and followed the regular install.
But at this point, in order to work around some bugs, some trick was needed …

Some packages need the libtool .la files in order to build (for dependencies calculations ?), but the current macports doesn’t
install them anymore. Yet, I don’t have any other workaround than keeping the whole build and parse them back for those .la files.
So we must instruct macports to keep the build trees : tune the /opt/local/etc/macports/macports.conf with

portautoclean           no

Probably at some point, some cleaning will become mandatory in order to free space.

Most port builds won’t need the libtool’s *.la files, and some build will crash with DYLIB path injections. However some build will
choke explicitely on missing lib*la files.
I simply used this uggly script in order to copy some parsed .la files from the build-trees :

#!/bin/bash

ls -ctr `find /opt/local/var/macports/build/ -name 'lib*.la' -type f` | while read LIBLA
do
    SHORTNAME=`echo ${LIBLA} | rev | cut -d/ -f1 | rev | sed 's/\.la$//'`
    if [ ! -f "/opt/local/lib/${SHORTNAME}.la" ]
    then
        sed 's#/opt/local/var/macports/build[_/abcdefghijklmnopqrstuvwxyz\.1234567890+-]*/\(lib[_/abcdefghijklmnopqrstuvwxyz\.1234567890+-]*\.la\)#/opt/local/lib/\1#g' < "${LIBLA}"  > "/opt/local/lib/${SHORTNAME}.la"
    fi
done

The best being probably to move those out of the way right after the build of the “la-needing” packages, but keep them for future use :

mkdir /opt/local/libla && mv /opt/local/lib/lib*.la /opt/local/libla

dbus port may fail from previous install, in which case a simple port install -f dbus will do the trick.

The new ddd isn’t necessarly fully compatible with the previous release, I had to remove the ~/.ddd directory in
order to get a new clean one ; otherwise ddd was stuck waiting for gdb to answer.

mv ~/.ddd ~/.ddd-`date '+%Y%m%d-%H%M'`

The 5.0.2 version of xcode doesn’t include the gdb debugger anymore, and the ddd port doesn’t yet depend on gdb. a simple port install gdb will provide a new one.
Now for some reason, the gdb port-provided is called ggdb, so ddd won’t find it right out. Two solutions here :
either invoke ddd session with :

ddd --debugger /opt/local/bin/ggdb [args]

or tune the ressource file for the proper gdb name, ~/.ddd/init :

! addition to locate and use the macports supplied gdb :
Ddd*debuggerCommand: /opt/local/bin/ggdb

! DO NOT ADD ANYTHING BELOW THIS LINE -- DDD WILL OVERWRITE IT
Ddd*dddinitVersion: 3.3.12
.../...

Finally, the vast majority of ports do build flawlessly, confirming the quality of those sources and the work of macports authors !

our galaxy as seen from makhtech-ramon

Makhtech Ramon is a huge erosion valley in the middle of negev desert. Stepping into a desert is really something worth trying, you’ll have the sensation of being invited by nature to shortly visit a place where humans are not really supposed to be.

Already, during daylight, embracing the “crater” as a whole from it’s edge is stunning. The light is strong and tend to blur everything in the distance, but precisely distances ar big : 10k wide 40km long …

Though, the numerous geological variations brought by erosion set an incredible complex map. 300m cliffs on the sides are the only remain of what use to be a dome above. Inside, the intricate patch of colors tells us about black for basalts or even cooked limestones, red for oxyded layers of  lime, sometime up to green for some clays.

makhtesh ramon - click and get lost into it, zoom as much as you can !

makhtesh-ramon - south cliff

The cauldron is inviting you to dive in.

A further step is to have a small nightly walk, without any disturbing light, and possibly without moonlight. The first surprise is that the star’s glow is strong enough to have a slow walk in those rocks. A few second after leaving the camp lights, the surprise is the arch of the milky way. Words from my five years old son : “it’s like fireworks, but suspended !”.

The image above pictures a horizon to horizon mosaic of 15 seconds-long shots, which is of course more than what naked eye can see. It’s somehow close to the seeing of myriad of stars you’ll get when at a remote dark place. Next to the left cliff, you can also find our neighbourg the andromedae galaxy.

Click on the mosaic for full size and more.

Obviously any process wants its  own sound device. That’s why sound servers were introduced after the inititial oss design. From the past, I used to tweak multiseat configs a lot with every last trend of sound servers, oss, esd, alsa, even tried jackd which isn’t really suited for general use. Finally, when I switched from debian to ubuntu for desktop use, I took a glance at pulseaudio.

Pulseaudio has one main point against the others : it is ubuntu’s current choice and it comes with a rather simple and convenient front-end for setting processes sound-volume individually (pavucontrol – Pulse Audio Volume Control).

With the multiseat constraints, I could not get a decent stable system keeping the initial per-user design ; this document mainly details most tricks needed to switch from a per-user to a system-wide pulseaudio daemon.

/etc/default/pulseaudio

The system-wide daemon is started once for all at the starting of the machine by it’s /etc/init.d/pulseaudio startup script.

PULSEAUDIO_SYSTEM_START=1

/etc/group

One main trouble when sharing sound devices is all those old binaries that try to steal /dev/dsp one to each other, but the same trouble may occur on /dev/snd/*/* device files ; that’s why I finally choosed to

• remove all users from audio group except pulse
• put back all users into pulse-access group

this way, stealing to each other is much more difficult (though pulseaudio daemon is a setuid application so some more has to be done, see below).

/etc/pulse/system.pa

load-module module-alsa-sink device="front:Intel" sink_name=global
load-module module-remap-sink sink_name=big channels=2 channel_map=right,left master_channel_map=right,left remix=no
load-module module-remap-sink sink_name=small channels=2 channel_map=right,left master_channel_map=rear-left,rear-right remix=no
; those three lines permit splitting a unique common multi-channel sound card to a pair of stereo sinks
; one using the front jack, the other the rear output jack.

.../...

# pulseaudio system-wide deamon keep the sound card for himself ...
# load-module module-suspend-on-idle

/etc/pulse/daemon.conf

# on my box, 2.6.33 introduced some troubles around there ...
no-cpu-limit = yes
# this one is for enabling four channel on the global sink (for watching movies ?)
default-sample-channels = 4

/etc/pulse/client.conf

; don't let user launch pulseaudio deamons at need, there's already one
autospawn=no

/etc/profile.d/pulseaudio-client.sh

as the environment variable $PULSE_SINK takes precedence over global or file tunings, another entry into /etc/profile.d sounds efficient :

#!/bin/sh

# in oder to match a screen-set to a pulseaudio sink :
# pour le cas ou l'on veut faire correspondre a un terminal un canal pulseaudio :
if [ "$DISPLAY" ]
then
    if [ "$DISPLAY" = ":0" ]
    then
        PULSE_SINK="big"
    fi
    if [ "$DISPLAY" = ":1" ]
    then
        PULSE_SINK="small"
    fi
fi

this script has to be usable by anyone :

# chmod 755 /etc/profile.d/pulseaudio-client.sh

update all ~users/.asoundrc

I confess I’m not (yet) sure for that one, I should start over with a clean ubuntu to check about it, anyway it shouldn’t hurt much : for each user, play :

> asoundconf set-pulseaudio

in order to get a default alsa mapping to pulse.

~/.pulse/client.conf

Any user may have its own additional settings, but should take care of eventually erasing the $PULSE_SINK var if needed (for example, my children have sound following their seats whilst I always have the big loudspeakers).

default-sink=small
; probablement mieux de ne pas avoir de pulseaudio lancés par les users
autospawn=no

there we are

Eventually /etc/group changes won’t be effective before X-session endings, the system-wide daemon has to be launched after killing anything in the way to soundcards, but at this point things should work, no more “release the sound for me please” battleground !

• C++ provides a lot of methods which are inherently safe and neat regarding string treatments,
• STL(sgi) provides a lot of nice containers, particularly the associative map,
• convenient simple text input/output using iostream …

Now, coding a daemon implies a lot of very unix-native C details such as : properly detach from terminals, output some errors via syslog …

When one realises all those functionnalites have simple posix-C functions to take care of, a very convenient bridge from C to C++ is to bind a regular iostream to a FILE* descriptor.

Example : reading from a pipe using istream
The below posix-C function :

FILE *popen(const char *command, const char *type);

provides a very simple way to fork and read to (or write from) another process. The gnu iostream library documentation mentions some methods usable to turn FILE* into stream, but I would not say the said documentation made it straighforward. So here’s an example of such a pipe :

#include <errno.h>
#include <string.h>     // strerror

#include <iostream>
#include <ext/stdio_filebuf.h>  // __gnu_cxx::stdio_filebuf

using namespace std;

void filter_uggly_uppercase (istream &in, ostream &out) {
    char c;
    while (in && in.get(c)) {
        if ((c>='a') && (c<='z'))
            out << (char)('A' - 'a' + c);
        else
            out << c;
    }
}

int main (void) {
    const char *command = "find . -type f";

    FILE *f_pipe_in = popen (command, "r");
    if (f_pipe_in == NULL) {
        int e = errno;
        cerr << "error at piping from " << command << " : " << strerror (e) << endl;
        return 1;
    }

    // let's build a buffer from the FILE* descriptor ...
    __gnu_cxx::stdio_filebuf<char> pipe_buf (f_pipe_in, ios_base::in);

    // there we are, a regular istream is build upon the buffer :
    istream stream_pipe_in (&pipe_buf);

    // let's read from that pipe now, the usual way ...
    filter_uggly_uppercase (stream_pipe_in, cout);

    pclose (f_pipe_in);

    return 0;
}