Last night, stargirl mentioned that my previous posting was very similar to some of the structures devised by people following the Oulipo styles.

These guys seem to have done some very interesting things with structured and specifically restricted writing styles in the 1960s and on from then. If my last posting interested you in the least then I recommend that you go and read around the topic of the Oulipo. It seems rather fun and interesting.

A while ago I discussed with a friend the possibility of using the words from a song to form the framework of a structured piece of creative writing. We settled on the following set of instructions:

• Take a song you particularly like. Take enough of the lyrics to encapsulate a sequence of five or six snippets of story with lyrics between them.
• Each snippet of story must be 100 words long; not a word more and not a word less.
• The song must entirely bracket the story (I.E. lyrics at the start and at the end).
• The story doesn't have to be about the song or indeed related to it; but the two must work as a single intertwined entity.
• Each snippet must be told from a different point of view. You may use an impersonal narrative as one of them.

My first attempt at the genre is entitled “How wonderful life is.” and I encourage you to read it and I hope it inspires you to have a go yourself.

… Because I do boy, And it’s cool boy

Several people have expressed shock and dismay at a concept which has been floating around since the 2003 Debconf in Oslo where it was announced as a concept at the FTP master talk (a well attended talk as I recall). Kenshi expressed support for the SCC concept which is nice to see.

What I find incredible (and perhaps a little confusing) is the large number of people who simply don’t understand that what is being proposed won’t kill off the SCC architectures. If an architecture isn’t one of the “Big Four” then Debian won’t be making STABLE releases (or so the proposal goes) but we will continue to support the architecture in unstable (and, one would assume, continue to support a testing migration path for the architecture too, although that I’m less sure of).

Slashdot carried a story on the proposal and the number of slashmonkeys who misunderstand is sufficiently great that the total amount of animosity now directed toward the Debian release team is actually upsetting a very good friend of mine. If the knee-jerk reaction results in causing pain to those close to our important teams; can we actually expect 100% that those members won’t be tempted to throw in the towel in order to protect the ones that they love? For goodness sake people — get a grip.

As the AMD64 team have demonstrated, architecture ports of Debian are actually capable of surviving outside of the main Debian archive entirely. Of course the port puts quite a strain on the Alioth systems but at least it’s a proof of concept. Also as Ubuntu has demonstrated, it is completely feasible to take an “unstable” snapshot of Debian and turn it into a very stable and pleasant release within six months across three architectures. So surely it would be possible to do it with those minority architectures which want it.

Interestingly the majority of the minority architectures (E.g. mips, mipsel, arm etc) are not actually small in terms of userbase but simply in terms of downloads. However they are also the embedded architectures and on such it is often desirable to take an unstable snapshot and stabilise the parts of it needed for any given application. And this is often what is actually done.

If there honestly is so much energy available to complain about the decision made over the past two years (okay — consolidated and made official very recently) which makes in my (and many others’) opinion complete sense; then can that energy instead be channelled into assisting the release team with achieving the Sarge release and then working with the project teams to actualise this proposal in such a way that those architectures being moved to the SCC flourish under their newfound freedom instead of languishing unattended because those who should care about them are too busy crying about the fact that Debian has moved on to providing a commitment to a smaller more manageable (and thus more releasable) subset of the architectures.

Stop thinking of your own agendas guys and start thinking about the project. If we don’t start making releases soon then Debian is likely to hemorrhage so many developers that we’ll be seriously in danger of implosion. At least this way we stand a chance of only losing a few hot-headed and stubborn developers instead of a large number of capable and dedicated people who accept that making releases and continuing to push out our excellent operating system is more important than their pet architecture.

I have been providing the sympa mailing list manager on Pepperfish for a few years now; explicitly for a single customer who demands some of its features such that enemies-of-carlotta is insufficient.

Pepperfish are going to be moving to a new installation soon (new disks etc) and I have been porting configuration to the new temporary machine so that I can reduce the amount of time I have to spend in a cold noisy datacentre of doom. Unfortunately it seems that the version of sympa I have on Pepperfish now has an on-disk format fundamentally different to the sympa I have available for the new system. Now I have the joys of trying to use dpkg-repack and such to upgrade the data or else get the old sympa running on the new installation.

Sympa consistently causes me the most pain of any customer-facing service we have; and it’s used by exactly one of our customers (and not a very busy one at that). I just wish I could find a web interface to EoC to combine with a web archiving tool so that I could move the customer off Sympa.

Thanks to everyone who has commented about ternary operators. In particular; thanks to Steve Alexander for pointing out PEP 308 to me along with this opinion that the python guys made the right choice.

Thanks also to the several people (namely Jonathon Jongsma, Matthew Good and Ross Burton ) for either emailing me or finding me on IRC to tell me about the fact that cond and truth or falsehood is also a python idiom for the ternary operator with the same caveats as the lua structure of the same form. Gunnar Wolf made a posting about ternary operators too. Thanks for your comments there Gunnar; interesting that perl6 will change the ternary operator from ? : to ?? ::. I wonder how that will affect class/module members etc.

Unfortunately noone yet has come up with a nice plausible luaish idiom for me to use in Aranha so I’m going to have to continue to ponder them. The best I have so far is: (if cond then truth else falsehood) where the parentheses are obligatory.

Just now, while working, I had occasion to use the much maligned ternary operator. Unfortunately I was working in python which doesn’t have the ternary operator per-se and so I had to call a friend (my ADSL was offline) and ask about the python idiom for such an operator. The option he gave me got me thinking about how lua lacks a ternary operator also and how you would implement it in Lua.

This set me to thinking again about how I’d rather like a Luaish ternary operator for my Aranha project. Unfortunately so far all I have come up with would not work due to Lua‘s slightly odd statement separation. I will either have to introduce a new lexeme or else find some way to re-use lua’s lexemes in an effective way without compromising the statement parser.

Possible structures I came up with include truth_result if condition else falsehood_result but that suffers from using if in an awkward position for statement separation. I was also considering (condition then truth_value else falsehood_value) explicitly parenthesised. Unfortunately that adds unusual messes into the expression parser.

I’m interested in what people think about the ternary operators in any case and if people have experience of using languages where ternary operators aren’t present per-se, I’d be interested in knowing what you’d recommend.