As acting release engineer of
the Gypsy project (a GPS mux, if
you didn't know) I'm proud to announce the release of Gypsy 0.8. So, what's
new?
Some people still ask me from time to time when I'll upload Battle for Wesnoth 1.8. My usual answer is that it's there already since before the official announce went out in the wesnoth-1.8 package.
The longer answer which also answers Why the name change?goes like this: People asked for a way to be able to install different branches side-by-side so that they can keep the old stable branch around for finishing started campaigns there while still being able to play with their friends multiplayer games using the new stable branch. Also people using the development version wanted to not having to get rid of the stable version just to use the development branch. So there it is! Enjoy! There though is still something missing though, and that's why the question where the 1.8 version of Wesnoth is still pops up: There is no transitional/meta package yet. This requires a bit more work including adding alternative handling (so one can still run wesnoth and not have to use the versioned wesnoth-1.8 binary name) and for that some dpkg-divert magic about the historical unversioned wesnoth packages. Given that my release is requesting quite some support overhead I can't tell yet when these things will be done, but a similarly related support contract will run out by the end of the month so potential I'll be able to find some time next month to finish this for good. If you want to have it done earlier or feel like helping out, feel free to send in patches after talking with me about the fineprints and potential approaches. Thanks in advance!
It's been a while since I've been able to make any progress on the ISC DHCP 4.1
packaging. I had to cannibalise my test infrastructure to deal with hardware
failure that would have rendered my MythTV installation out of commission, we
bought a condo, did some renovations, and had a baby. I'm still playing catch
up.
The other day, I was able to recreate a test environment on my laptop using
KVM, instead of Xen on a dedicated machine, and it's 37% more awesome than my
old setup, so I'm back in the saddle again.
I've been able to do some basic testing of the 4.1 packages that are in
experimental, and they appear to work, and they upgrade cleanly from the 3.1
packages.
There's the small issue of third-party packages that are plonking files in
/etc/dhcp3 (it's just /etc/dhcp now). I finished filing bugs
for the transition this morning, so I think the next step is to upload to
unstable, which I think I'll do on the weekend.
This last weeks, I've worked on implementing the Desktop Notification Specification into Emacs. It allows sending desktop notification in a very simple way.
(notifications-notify
:title "You've got mail!"
:body "There's 34 mails unread"
:app-icon "~/.emacs.d/icons/mail.png"
:urgency 'low)
It supports the protocol signals (NotificationClosed and ActionInvoked) and
the two main methods (Notify and CloseNotification).
The methods specification are implemented entirely (hints, replaces,
actions, icon, etc).
The signals are supported via callbacks function provided on the
notification creation.
It have been merged into Emacs trunk today.
2010-06-09 Julien Danjou <julien@danjou.info> * net/notifications.el: New file.This also allowed me to discover, raise and fix a bug in the D-Bus binding of Emacs, which will be probably fixed in trunk soon.
Early this morning I sent
Rcpp version 0.8.1
off to CRAN and
Debian. In the meantime,
Romain has already provided
a very nice blog post about
it.
There are a few fairly visible new things in this release. As we want to
focus the next few minor releases on completing the documentation, we started
by adding a total of four (!!) new vignettes:
0.8.1 2010-06-08
o This release adds Rcpp modules. An Rcpp module is a collection of
internal (C++) functions and classes that are exposed to R. This
functionality has been inspired by Boost.Python.
Modules are created internally using the RCPP_MODULE macro and
retrieved in the R side with the Module function. This is a preview
release of the module functionality, which will keep improving until
the Rcpp 0.9.0 release.
The new vignette "Rcpp-modules" documents the current feature set of
Rcpp modules.
o The new vignette "Rcpp-package" details the steps involved in making a
package that uses Rcpp.
o The new vignette "Rcpp-FAQ" collects a number of frequently asked
questions and answers about Rcpp.
o The new vignette "Rcpp-extending" documents how to extend Rcpp
with user defined types or types from third party libraries. Based on
our experience with RcppArmadillo
o Rcpp.package.skeleton has been improved to generate a package using
an Rcpp module, controlled by the "module" argument
o Evaluating a call inside an environment did not work properly
o cppfunction has been withdrawn since the introduction of the more
flexible cxxfunction in the inline package (0.3.5). Rcpp no longer
depends on inline since many uses of Rcpp do not require inline at
all. We still use inline for unit tests but this is now handled
locally in the unit tests loader runTests.R.
Users of the now-withdrawn function cppfunction can redefine it as:
cppfunction <- function(...) cxxfunction( ..., plugin = "Rcpp" )
o Support for std::complex was incomplete and has been enhanced.
o The methods XPtr<t>::getTag and XPtr<t>::getProtected are deprecated,
and will be removed in Rcpp 0.8.2. The methods tag() and prot() should
be used instead. tag() and prot() support both LHS and RHS use.
o END_RCPP now returns the R Nil values; new macro VOID_END_RCPP
replicates prior behabiour
As always, even fuller details are in
Rcpp Changelog page and the
Rcpp page which also
leads to the downloads, the
browseable
doxygen docs and zip files of doxygen output for the standard formats.
A local directory has
source and documentation too.
Questions, comments etc should go to the
rcpp-devel mailing list
off the R-Forge page
A somewhat na ve young man, a kidnapping, a policeman's daughter, a night club singer, said policeman's partner being involved, a love triangle, a pervert and (probably because it's Lynch) a cut off ear. What more do you need ... ? Or, in other words, I absolutely regret not having seen Blue Velvet before.
In contrast, Pink Flamingos takes its fight over the title of the filthiest woman alive (which sets the whole plot in motion) a bit too literal for my taste. I like movies that leave more things up to the imagination of the spectator. Or perhaps it's just that my sense of aesthetics doesn't agree with John Water's.
(And to the person who knew nothing bettter to say than You idiot to my negative critique about Tarantino's Inglourious Basterds: I don't delete comments on my blog that don't agree with me. But I do not tolerate personal attacks. Post it to your own blog. You're as entitled to your opinion as I am.)
svn co svn://svn.valgrind.org/valgrind/trunk valgrind -r 11100cd valgrindwget -O - -q https://bug549749.bugzilla.mozilla.org/attachment.cgi?id=449748 patch -p0icegrind/ice_main.c, go on the last line of the track_mmap function and replace mmaps with dest_mmaps.mkdir icegrind/tests ; touch icegrind/tests/Makefile.amlibtoolize ; aclocal ; automake --add-missing ; autoreconf./configure; make
wget http://hg.mozilla.org/users/tglek_mozilla.com/startup/raw-file/6453ad2a7906/elflog.cppg++ -o elflog elflog.cpp -lelflibelf-dev package.make install ; install -m 755 elflog /usr/local/bin/usr/local.elflog --contents libxul.so > libxul.so.sectionsLD_LIBRARY_PATH=. valgrind --tool=icegrind ./firefox-bin -P my-profile -no-remote about:blankNew major user-visible features:The list of supported OSes and architectures is slowly getting longer, e.g. these have been tested: Linux, FreeBSD, NetBSD, DragonFly BSD, Nexenta, Solaris and Mac OS X. There's partial support for DOS (no USB/serial flashers) and Windows (no PCI flashers). Initial (partial) PowerPC and MIPS support has been merged, ARM support and other upcoming. Also, the list of external (non-mainboard) programmers increases, e.g. there is support for NICs (3COM, Realtek, SMC, others upcoming), SATA/IDE cards from Silicon Image and Highpoint, some NVIDIA cards, and various USB- or parallelport- or serialport- programmers such as the Busirate, Dediprog SF100, FT2232-based SPI programmers and more. More details at flashrom.org and in the list of supported chips, chipsets, baords, and programmers. I uploaded an svn version slightly more recent than 0.9.2 to Debian unstable, which should reach Debian testing (and Ubuntu I guess) soonish.
* Dozens of newly supported mainboards, chipsets and flash chips.
* Support for Dr. Kaiser PC-Waechter PCI devices (FPGA variant).
* Support for flashing SPI chips with the Bus Pirate.
* Support for the Dediprog SF100 external programmer.
* Selective blockwise erase for all flash chips.
* Automatic chip unlocking.
* Support for each programmer can be selected at compile time.
* Generic detection for unknown flash chips.
* Common mainboard features are now detected automatically.
* Mainboard matching via DMI strings.
* Laptop detection which triggers safety measures.
* Test flags for all part of flashrom operation.
* Windows support for USB-based and serial-based programmers.
* NetBSD support.
* DOS support.
* Slightly changed command line invocation. Please see the man page for details. Experimental new features:
* Support for some NVIDIA graphics cards.
* Chip test pattern generation.
* Bit-banging SPI infrastructure.
* Nvidia MCP6*/MCP7* chipset detection.
* Support for Highpoint ATA/RAID controllers. Infrastructural improvements and fixes:
* Lots of cleanups.
* Various bugfixes and workarounds for broken third-party software.
* Better error messages.
* Reliability fixes.
* Adjustable severity level for messages.
* Programmer-specific chip size limitation warnings.
* Multiple builtin frontends for flashrom are now possible.
* Increased strictness in board matching.
* Extensive selfchecks on startup to protect against miscompilation.
* Better timing precision for touchy flash chips.
* Do not rely on Linux kernel bugs for mapping memory.
* Improved documentation.
* Split frontend and backend functionality.
* Print runtime and build environment information.
DevOps
I first heard about DevOps from Lindsay Holmwood at linux.conf.au 2010. Since then, I ve been following the movement with interest. It seems to be about cross-functional involvement in software teams, specifically between software development and system administration (or operations). In many organizations, especially SaaS shops, these two groups are placed in opposition to each other: developers are driven to deliver new features to users, while system administrators are held accountable for the operation of the service. In the best case, they maintain a healthy balance by pushing in opposite directions, but more typically, they resent each other for getting in the way, as a result of this dichotomy:
| Development | Operations | |
|---|---|---|
| is responsible for | creating products | offering services |
| is measured on | delivery of new features | high reliability |
| optimizes by | increasing velocity | controlling change |
| and so is perceived as | reckless and irresponsible | obstructing progress |





















Lately, I have recurring WTF moments when working with Python. I'm still
more or less a novice in Python, as I started to use it in my day job last
year, so sometimes it could be blamed to ignorance.
Today I was writing some code that takes any file descriptor as argument,
and thought it could be nice to accept also objects that represent one. But it
seems there is no common ancestor to file objects and socket objects, for
example. In Perl, I'd just check for IO::Handle.
Then, I wrote code to check if a passed argument was a socket, or a file
descriptor to one, with some obvious check: isinstance(s,
socket.socket). WRONG, when you create sockets with
socketpair, they are of an undocumented type which is not a
descendant of socket, nor of SocketType! (There is a patch for this since 2007)
In general, I have found a lack of any reasonable object hierarchy, and many
inconsistencies in the low-level interfaces, which is a pity, because Python is
in general quite tidy. Comparing with Perl is unavoidable, and I would have
expected that Python had learnt more from it.
Another thing that amazes me is the lack of anything like CPAN, which is one of the reasons
Perl was so successful. The cheese
factory doesn't come close, as you need to publish your files
somewhere else, there is no automated testing, no automatically generated
documentation, or anything that requires access to the source code.
In Perl-land, many people loathe the venerable MakeMaker, and some of the
alternatives are ugly as hell. The Python equivalent (or so) to Makemaker,
distutils, looks to me like a bad joke: advanced customisation is black magic
(if possible at all), and doesn't provide absolutely basic things like running
your unit tests! After fighting with it for some days, I decided to go back
writing my own Makefile and calling distutils just to build and install.
Tags: Planet Debian, Planet Lugfi, Programaci n
Apropos Matthew's
post...
I picked up a cheap netbook for Jo a couple of months ago, an Acer
Aspire One 751. She liked the look and feel of the machine, and it was
much smaller and more carryable than the massive old Dell "slab" she'd
been using previously. Got a very good deal on it
too, as it was the last one in stock at the local Comet store.
All went well until we got it home and I started playing with
it. That was when I found the painful truth: it was based on the
Poulsbo, using Intel's crippled GMA500 graphics chipset. Up until
then, I'd been very happy with buying Intel kit: for the last few
years it's been a sure sign that the hardware would work well with
Debian and Linux. Now they've come out with a crappy product that has
destroyed that goodwill. I spent many hours working through various
options to try and get this new netbook up and running properly using
Debian, but to no avail - the various binary blobs wanted newer
versions of code than was in Lenny and (by then) older stuff than was
available in Squeeze. In the end I gave up and installed an outdated
version of Ubuntu on the machine just so Jo could have it working for
her when we went on holiday together.
Since then, she's had to get used to the machine locking up once or
twice a day while she's using it (something I can only assume is
caused by the shitty drivers). She's happy enough in that
it's much better than her old Vista-infested Dell machine, but it's
really not a great experience for her compared to the Thinkpads she
sees others using reliably and flawlessly at home.
At some point I guess we'll simply ditch the machine altogether and
get something less nasty. Thanks for the good stuff you used to make,
Intel, but you've lost your way. I'll be damned careful next time to
avoid this trap.
This is already possible with Memcache, but
if you are already drinking the Koolaid...
import time class Lock(object): def __init__(self, key, expires=60, timeout=10): """ Distributed locking using Redis SETNX and GETSET. Usage:: with Lock('my_lock'): print "Critical section" :param expires We consider any existing lock older than expires seconds to be invalid in order to detect crashed clients. This value must be higher than it takes the critical section to execute. :param timeout If another client has already obtained the lock, sleep for a maximum of timeout seconds before giving up. A value of 0 means we never wait. """ self.key = key self.timeout = timeout self.expires = expires def __enter__(self): timeout = self.timeout while timeout >= 0: expires = time.time() + self.expires + 1 if redis.setnx(self.key, expires): # We gained the lock; enter critical section return current_value = redis.get(self.key) # We found an expired lock and nobody raced us to replacing it if current_value and float(current_value) < time.time() and \ redis.getset(self.key, expires) == current_value: return timeout -= 1 time.sleep(1) raise LockTimeout("Timeout whilst waiting for lock") def __exit__(self, exc_type, exc_value, traceback): redis.delete(self.key) class LockTimeout(BaseException): pass
def cache_without_dogpiling(key, cb, cache_expiry=None, *args, **kwargs): val = cache.get(key) if val is not None: return val # Cache miss; gain the lock to prevent multiple clients calling cb() with Lock(key, *args, **kwargs): # Check cache again - another client may have set the cache val = cache.get(key) if val is None: val = cb() cache.set(key, val, cache_expiry) return val def slow(): print "Inside slow()" return 1 + 1 # Python is slow >>> cache_without_dogpiling('my_key', slow, 60 * 10) Inside slow() 2 >>> cache_without_dogpiling('my_key', slow, 60 * 10) 2
import contextlib @contextlib.contextmanager def Lock(*args, **kwargs): yield
The screenshot is featuring myself in Collabora's UK office
(top-left), Robert McQueen from a hotelroom in Taipei (top-right),
Will Thompson and Magical trevor also from the Collabora UK office
(bottom-left) and Mike Ruprecht from somewhere in Missouri. So we
were quite spread out over our little planet. Both audio and video
quality was quite good, even though the network in robs hotel was a
bit flaky from time to time.
In case you want to try it out have a look at the MujiDemoClient
page.
With the recent "PR1.2" firmware upgrade of Nokia N900, a new feature was enabled in the browser - WebGL. WebGL is cool and scary. The cool part is that it is a chance to bring lots of games to to Linux users. The screenshot is from Match3D, a 3D tic-tac-toe game.
A couple of months ago, I've started using ERC to hang out on IRC. I've read all the pages on EmacsWiki about it, just to see how far I could customize it. I must admit that I was not disappointed, even if I expected to be. It's quite a nice software, and once well configured it's more convenient that my old irssi setup. While browsing EmacsWiki, I read an interesting idea about channel scoring/temperature on the erc-track page. The idea is to see if it's worth jumping to an IRC channel to see what people are talking about. Challenge accepted! I sat up and started to dig though ERC source code to find the information I needed about variables and functions. I finally did write something nice, which I called erc-track-score. And yet another piece of software I wrote for my lovely Emacs! How does it work? Ha-ha, I was sure you would ask. You're so predictable, dude! Read the following, and you'll know everything you ever wanted to know about it since the moment you read the title of that blog entry. Which probably turned you on. Nasty you. First of all, the score of a channel starts at zero. Zero means "seriously, don't bother, nothing is happening here". Upon each new message arrival, the score is incremented by 1. If a new message contains a keyword, your nickname or is sent by a pal, the score is increased by configurable values, by default between 2 and 20 points, depending on the match type. On the other hand, when a message is send by some fool, the score is decreased by 1 by default. Obviously, if the score is going negative, you really should not jump to the channel. Finally, the score is permanently and slowly brought back to 0. By default, the score is decreased by 1 point every 10 seconds. Overall, reading the score should gives you a good idea of the channel temperature. I'm still not sure what is the best formula to compute the score, but so far the default values seem quite good. We'll see.
Next.