you=this
,the=('a\
ler\
t'),you=you[the]
you('hello world \
by Raphael Geissert \
based on example by\
Gareth Heyes\
')
,/abc abc\
abc abc abc\
abc\
/,/abc abc\
abc abc abc\
abc\
/
It will be a make-or-break year for Perl. If the Perl developers cannot either bring new life to Perl 5 or turn Perl 6 into something real, this language will, by the end of the year, have moved well down the road to "legacy" status.As can be imagined, that set them off all over again. The mental image I get is a big angry bull, frothing at the mouth, and ready to stomp that damn red cape. Here's the problem, though, guys: the cape isn't what's holding you back. Trust me, I know. Once upon a time, when people spoke of scripting languages, they talked about "Perl, Python and Tcl". No Ruby, no PHP, although both existed. I happen to like Tcl a lot, and it measures much worse than Perl on all the popularity charts... worse than plenty of other languages, these days. Lately, I don't use it so much, but once upon a time I dedicated a lot of mental energy to wondering why things weren't going better. And in that community too, there were people who consistently held their fingers in their ears and yelled "LALALALA there is no problem!". In the long term, it's not an effective strategy: it makes everyone but the other True Believers think you're going off the rails, because the evidence is plain to see that things weren't quite like they used to be, that there are problems. And it doesn't really address the problem in a constructive way, either. Long term, what works is to produce good code, and get it in people's hands. The most effective way of dealing with problems of this nature includes these points:
It will be a make-or-break year for Perl. If the Perl developers cannot either bring new life to Perl 5 or turn Perl 6 into something real, this language will, by the end of the year, have moved well down the road to "legacy" status.As can be imagined, that set them off all over again. The mental image I get is a big angry bull, frothing at the mouth, and ready to stomp that damn red cape. Here's the problem, though, guys: the cape isn't what's holding you back. Trust me, I know. Once upon a time, when people spoke of scripting languages, they talked about "Perl, Python and Tcl". No Ruby, no PHP, although both existed. I happen to like Tcl a lot, and it measures much worse than Perl on all the popularity charts... worse than plenty of other languages, these days. Lately, I don't use it so much, but once upon a time I dedicated a lot of mental energy to wondering why things weren't going better. And in that community too, there were people who consistently held their fingers in their ears and yelled "LALALALA there is no problem!". In the long term, it's not an effective strategy: it makes everyone but the other True Believers think you're going off the rails, because the evidence is plain to see that things weren't quite like they used to be, that there are problems. And it doesn't really address the problem in a constructive way, either. Long term, what works is to produce good code, and get it in people's hands. The most effective way of dealing with problems of this nature includes these points:
I believe that most debian developers ignore discussions of possible general resolutions like the current one, until/unless they look like reaching the required number of seconds to trigger a vote.
It s hard to prove that a group is ignoring something, but disproof is simple: please could all DDs who watch pre-proposal discussions of possible GRs please email mjr-possiblegr at debian.org. I ll count with from -f possiblegr.mbox wc -l in a week or so, after filtering out any emails from non-DDs.
Feel free to ask other debian developers to email if they watch reasonably likely places (planet, non-technical lists, ) for pre-proposal discussions of possible GRs. Please don t spam debian-devel or announce lists about it, unless you re expecting future possible GRs to be sent there. I d welcome a quick comment if you post it anywhere.
If you can see a way to prove that a group is ignoring something, let me know. I realise that failing to disprove this isn t the same as proving the opposite, but I think it would still be useful.
I received a SanDisk
Sansa e260 (v2) for my birthday. It was one of those presents that
acquired for myself on behalf of someone else because it worked out easier
that way. I bought it for cheap from Woot!
I thought I'd use it to play podcasts while I'm at the gym. We've been
listening to NPR for a while now, and
there's lots of excellent programming, and it's all available in download
for as well. Since I don't spend all that much time in the car, I'm not
listening to much of it.
The first mission was to upgrade the firmware. Getting the player into MSC
(instead of MTP) mode
with the original firmware was a little
tricky, but I got there in the end. Then I had to locate the firmware in
a Linux-installable format. I think I ended up resorted to using Windows,
but I later found the raw
firmware image without needing an installer.
I'm using Rhythmbox at
the moment to download the podcasts. I thought I'd try out its MTP support,
just because it actually had it, but either Linux 2.6.26 has a problem with
MTP, or the player is particularly flaky doing it with Linux, because I just
seemed to get a pile of USB errors when connecting the device in this mode,
so I'm sticking with MSC for now.
Oh, and I had to put a .is_audio_player file in the root of the
device to make it show up in Rhythmbox. I later discovered that it worked
most optimally if I put
audio_folders=MUSIC/ folder_depth=2in the file. I'm still trying to come up with an optimal way of managing the audio I want to listen to. It seems somewhat tedious to drag and drop all of the podcasts from Rhythmbox to the device. I kind of want some sort of plug and play auto-sync method. It seems I can't use a connection-triggered rsync, because some of the podcasts seem to get downloaded with non-FAT-filesystem-friendly filenames. Rhythmbox seems to take care of this by doing some sort of automagical renaming at transfer time. That said, not everything is showing up in the music list with sane names. There's a few things that have an unknown artist I think. That may be a deficiency in the ID3 tags of the MP3s themselves though... What I really want some way of getting home, hooking up the player and just getting what's new, without expending too much effort (at the time of hooking up the player, anyway. I'm happy to expend some effort getting to that point) The next weird thing is that the device wants to talk USB 1.1. I'm not sure what is at fault here, but I can, allegedly at least, make the device reconnect at USB 2.0 by removing and reloading the ehci-hcd module after connecting it. Here we have the device initially attached:
apollock@icarus:~$ lsusb -t
Bus# 5
-Dev# 1 Vendor 0x1d6b Product 0x0002
Bus# 4
-Dev# 1 Vendor 0x1d6b Product 0x0001
Bus# 3
-Dev# 1 Vendor 0x1d6b Product 0x0001
-Dev# 9 Vendor 0x0781 Product 0x7423
Bus# 2
-Dev# 1 Vendor 0x1d6b Product 0x0001
-Dev# 6 Vendor 0x413c Product 0x8103
Bus# 1
-Dev# 1 Vendor 0x1d6b Product 0x0001
lsusb says that bus #3 is ID 1d6b:0001 Linux Foundation 1.1 root hub
Then if I do a spot of presto-changeo...
apollock@icarus:~$ sudo modprobe -r ehci-hcd
apollock@icarus:~$ sudo modprobe ehci-hcd
apollock@icarus:~$ lsusb -t
Bus# 5
-Dev# 1 Vendor 0x1d6b Product 0x0002
-Dev# 3 Vendor 0x0781 Product 0x7423
Bus# 4
-Dev# 1 Vendor 0x1d6b Product 0x0001
Bus# 3
-Dev# 1 Vendor 0x1d6b Product 0x0001
Bus# 2
-Dev# 1 Vendor 0x1d6b Product 0x0001
-Dev# 7 Vendor 0x413c Product 0x8103
Bus# 1
-Dev# 1 Vendor 0x1d6b Product 0x0001
Bam! It's moved over to bus #5, which lsusb says is 1d6b:0002
Linux Foundation 2.0 root hub
Weird.
I wonder if I should try running Rockbox on it? Seems not, it's only for
v1 players. Oh well.
I'm working on designing a microformat that can be used to
indicate the location of VCS (git, svn, etc) repositories
related to a web page.
I'd appreciate some web standards-savvy eyes on my
rel-vcs microformat rfc.
If it looks good, next steps will be making things like
gitweb, viewvc, ikiwiki, etc, support it. I've already written a
preliminary webcheckout tool that will download an url, parse
the microformat, and run the appropriate VCS program(s).
(Followed by, with any luck, github, ohloh, etc using the
microformat in both the pages they publish, and perhaps,
in their data importers.)
Why? Well,
XS-VCS-* fields.
deb http://packages.kirya.net/dspam-community/ experimental main deb-src http://packages.kirya.net/dspam-community/ experimental main
gpg --keyserver wwwkeys.eu.pgp.net --recv-keys FBABB737 gpg --export -a FBABB737 apt-key add -
wget -O - http://packages.kirya.net/Kirya.netDebianpackagesVerificationKey.asc apt-key add -
I've been owning a Nintendo Wii for quite a while now, but so far only played an occasional game of tennis or the like. Over the holidays I got The Legend of Zelda: Twilight Princess, which is a really nice game in itself. What is even more interesting though, is that this game allows you to run homebrew software on your Wii.
What you usually want to do, is to use the so-called Twilight Hack to install the Homebrew Channel on your Wii (you'll need an SD card and the Twilight Princess game for this). Once the process has finished you won't need the game anymore though.
So, here's a quick tutorial on how to install the Homebrew Channel. I basically followed the Setting up your Wii for Homebrew HOWTO from wiibrew.org.
Requirements
An SD card max. 2GB in size (not an SDHC card!), an SD card reader in your PC or laptop, and the Twilight Princess game (which you must play at least once).
Backup
First, you'll want to backup your Twilight Princess save games (if any). For that, we format the SD card (it needs a FAT16/FAT32) filesystem.
$ mkfs.vfat /dev/mmcblk0p1 (you may need to change "mmcblk0p1" to whatever fits your setup)Now insert the SD card into the Wii, start the Wii, go to Wii Options --> Data Management --> Save Data --> Wii and copy your Twilight Princess save games onto the SD card. Then, poweroff, remove the SD card, insert it into your laptop/PC and copy the save games to a safe place.
$ mount -t vfat /dev/mmcblk0p1 /mnt $ mv /mnt/private ~/zelda_savegamesTwilight Hack and Homebrew Channel
Next up: download the Twilight Hack and Homebrew Channel, and put the files on the SD card:
$ wget http://hbc.hackmii.com/dist/twilight-hack-v0.1-beta1.zip $ unzip twilight-hack-v0.1-beta1.zip $ cp -r private /mnt $ wget http://hbc.hackmii.com/dist/the_homebrew_channel-1.0.1.tar.gz $ tar xfvz the_homebrew_channel-1.0.1.tar.gz $ cp the_homebrew_channel-1.0.1/boot.dol /mnt $ umount /mntNow remove the SD card, insert it into the Wii and power-up the Wii. Go to Wii Options --> Data Management --> Save Data --> Wii, delete the Wii Twilight Princess save games, then copy the "Twilight Hack" save game from the SD card onto the Wii (you need to select the correct one for your region). Quit the menu, start Twilight Princess, load the "Twilight Hack" savegame and finally talk to the person in front of you (do not perform any other actions, or the Wii may crash!). Follow the remaining instructions on the screen and you're done. You now have an additional channel named Homebrew Channel where all your homebrew programs/games (and your own Free Software programs you may write/port) will appear. Installing homebrew software So far, there are no real applications in the Homebrew Channel, you need to put all the homebrew software you want on the SD card. There's a huuuge list of applications and games to choose from, many of them Free Software with source code, some however are binary-only. Basically, you put each application in a sub-directory of apps/ on the SD card, the most important file in every sub-directory is always boot.dol. If you have a boot.elf file instead, you'll probably need to convert it using the ELF to DOL converter. Restoring Twilight Princess save games You may now want to restore your Twilight Princess save games onto the Wii, you no longer need the "Twilight Hack" save game. Put your ~/zelda_savegames directory on the SD card and name it private/ again. Insert the SD card into the Wii and copy the save games on the Wii (similar procedure as above). Have fun with homebrew software on your Wii, or even better write your own software or port existing Linux applications/games!
J r my Bobbio suggested that I should explain how I looked for packages
affected by a compiler bug
(Debian bug 506713;
gcc bug 38287). I don't claim that
this is a particularly good way to do it, but here it is:
First, I identified a pattern to search for. Unfortunately I don't really
understand the cause or fix for the bug, but I did have the example which
led to this bug report: Debian bug
490999. The bad code was a stack-pointer-relative load immediately
after a stack allocation (SPARC save instruction) where the offset was not
adjusted for the stack allocation:
I generalised this to:save %sp, -112, %sp ld [ %sp + 0x40 ], %i5
where offset1 + offset2 < 0. Of course, this may be valid if the intervening instructions include asave %sp, offset1, sp ... ld [ %sp + offset2 ], register
restore,
branch or store to the effective stack location that the last instruction
loads from. I ended up allowing up to 10 intervening instructions and
examining a disassembly to work out which cases were valid.
I looked up the instruction encoding for these two instructions.
Thankfully SPARC is RISC so they are simple and regular:
save %sp, offset1, sp is encoded as 0x9de3a000 offset1 & 0x1fffld [ %sp + offset2 ], register is encoded as 0xc003a000 reg << 25 offset2 & 0x1fff
bytes type for this,
as str is a Unicode string type.)
So that's how I scanned single files. The next step was to find, unpack
and scan all the SPARC shared libraries in the archive. (This particular
code generation bug is understood to affect only PIC code, and that is
normally only used in shared libraries.) I wrote functions to search
Contents-sparc for shared library files - assumed to match the pattern
([^\s]*/lib[^/\s]+\.so(?:\.[^/\s]*)?) - and to parse
Packages to find the filenames for the packages containing those files.
The latter uses the debian_bundle.deb822 module from
python-debian.
The last key function downloads and unpacks a package using
wget and dpkg-deb. I could have used
the httplib module for downloading but I correctly
anticipated that I'd need to restart the script several times so I
wanted to cache the packages which was easier to do using
wget.
So, that's the explanation. If you really want to see it,
here's
the code.
(this is something I've had "in production" for many months now, I just
haven't had the time or energy to do a proper write up about what I did)
We have a cat water bowl, it looks like this:
Under "normal" circumstances, it usually lasts about seven days. So when our
weekly routine is happening, we'll refill it on a Saturday whilst doing
house chores, and it'll last until the following Saturday when it gets
refilled.
Unfortunately, sometimes our routine gets disrupted, and we forget.
Sometimes, we travel and have a house-sitter, who may not pay as close
attention to such things as ourselves.
Once, one of our cats was licking the condensation off a chilled bottle of
soft drink that was on the kitchen counter one evening, before we realised
the water bowl needed refilling. Naturally, we felt like terrible pet
owners.
So I think it was some time around the 2008 Maker Faire, that I hatched the
idea of having some sort of water sensor on the cat bowl, which would
communicate to one of the various computers in house. At the Maker Faire, I
bought a copy of Making things
talk, and an Arduino starter kit, which consisted of a Diecimila board
and a make-it-yourself proto
shield. I also bought a little electronics starter kit, which consisted
of a breadboard and various components, and a USB-TTL cable.
I decided to use Bluetooth to communicate with the board, as I already had
my MythTV setup using a Bluetooth keyboard and mouse, and it was within
range of the water bowl. I decided against using Zigbee, because I didn't
know anything about it, and I didn't want to add (or learn about) yet
another wireless infrastructure just for this project.
I should point out that I know very little about electronics. I'd never
owned (or really used) a soldering iron until I embarked on this project. I
took a basic soldering class at the Tech
Shop, but I'd already assembled the proto shield by the time I took the
class, so I'd pretty much figured it out.
I had a very naive vision that I could just basically shove two wires in
some water and it'd close a circuit and that would be my water sensor. Of
course this didn't work, so I started hunting around on the Internet for a
circuit that would do this. I happened upon a circuit (I don't seem to have
retained the URL, so I can't link to it), which just consisted of a couple
of transistors and some resistors. So I headed off to Fry's to try and buy
the transistors I needed.
I quickly discovered that I didn't have sufficient information to identify
the transistors that I wanted, but I did happen to stumble upon a cheap
assemble-it-yourself water alarm. It consisted of a PCB, and a
transistor and some resistors and a buzzer. I bought a couple of these
instead.
Between studying the PCB and the circuit
diagram that came with the alarm, I was able to reproduce it on my
breadboard instead of on the PCB. Sure enough, placing the two probes in
water closed the circuit. I replaced the buzzer with an LED so I could see
what was going on.
I attached the circuit to the Arduino proto shield, and had it feed into one
of the digital I/O ports. I wrote some quick and dirty Wiring code so that
when water not present (i.e. the circuit was open and no current was
detected on that I/O port) the LED was switched on. Really at this point, I
didn't need a microcontroller, I could have presumably achieved the same
thing with a NOT gate.
At this point, I wanted to make the sensor remotely queryable. I bought a BlueSMiRF
Silver Bluetooth modem, which I attached to the TX and RX lines of the
board (I first configured it by attaching the USB-TTL cable to it and using
Minicom on my laptop). I extended the Wiring code to provide a rudimentary
prompt, and accept a command to check if water was present.
I think around this time it also dawned on me that I could use the digital
I/O pins as a switch. When they're "high" they provide power. So rather than
constantly running a current through the water, I only needed to briefly
power up the water detection circuit, see if the circuit closed or not, and
then report if water was present if it did.
I much preferred this, as at the time, I was endeavouring to power the whole
sensor off a 9 volt battery. I figured I'd get much better battery life if I
wasn't running a current through the water the entire time. I should point
out that I did some "tongue tests" in a glass of water while the circuit was
powered up, and couldn't detect a difference between when the circuit was on
or off. The last thing I wanted to be doing was zapping the cats!
At this point, the Wiring and Arduino work was pretty much complete. I setup
ser2net on the MythTV server, so that I could just connect to port
4000, and be connected to the water sensor.
apollock@icarus:~$ telnet teevee 4000 Trying 172.16.0.9... Connected to teevee.andrew.net.au. Escape character is '^]'. ser2net port 4000 device /dev/rfcomm0 [9600 N81] (Debian GNU/Linux) waterbowl> s Water is present waterbowl> telnet> q Connection closed. apollock@icarus:~$The Wiring code running on the Arduino board is checked in here. Next, I wanted to monitor this with Nagios. One thing I found with the Bluetooth connection was that it wasn't all that reliable. Not every connection to port 4000 resulted in a connection with the water sensor. I elected to write some standalone code that submitted results to Nagios by way of a passive check, rather than having Nagios try to actively monitor it. Again, trying to conserve energy, I decided to only check the sensor once every 8 hours. So I wrote a Python daemon, which tried to be as robust as possible. If at first it doesn't make a connection on its 8 hourly schedule, it keeps trying until it does. Nagios itself has some freshness detection for this monitor, so if no passive result is submitted within 8 hours and one minute, Nagios alerts that something is possibly wrong with the sensor itself. (The original intent was to deal with the situation where the battery went flat) This is the Nagios service definition I've got. Some of it may be unnecessary or redundant:
define service
host_name teevee
service_description Cat water bowl
check_command check_stale!2!"Check water bowl monitor is on and reachable"
normal_check_interval 480
notification_interval 240
active_checks_enabled 0
check_freshness 1
freshness_threshold 28860
max_check_attempts 1
check_period 24x7
use generic-service
stalking_options o,w,c
contact_groups everyone
The code for the Python daemon is checked in here.
So everything was going swimmingly, apart from I couldn't get even 24 hours
of monitoring on my conservative 3 times a day schedule, and the Bluetooth
modem configured for all of its power saving options, and the water sensor
itself only being powered on when it was performing a check. There wasn't
much more I could do to try and reduce power consumption, at least with my
limited electronics knowledge. Perhaps using Zigbee instead of Bluetooth
would have helped, but I still think I'd have been going through 9 volt
batteries more quickly than I'd have liked.
I also had a brief foray into solar powering the board. I thought maybe the
lighting in the house would be sufficient to power the board. Of course this
didn't work out. I'd also have needed to make the code running on the board
more self-sufficient, and have it just provide a water status indication
whenever it had enough power to do so, instead of being a fairly dumb device
like it currently is. This all felt a whole level more complicated, and out
of my league, and I wasn't interested in attempting this sort of
remote-sensing exercise at this time.
The Arduino board can also be powered by USB, so as I already had some long
USB type A to type B cables (that had funky lights in them to boot), I
decided to just get a wall wart that had a USB type A receptacle, and
powered the Arduino board that way. So much for being completely "wireless".
(I could have also gotten a general purpose DC power supply that was capable
of spitting out 9 volts, but I doubted I'd get one with a sufficiently long
cable, which is why I went for the USB-powered option, as I already had a
cable long enough)
Speaking of wires, the most challenging part was the probes for the water
sensor. As they were going to be permanently in the cats' drinking water, I
didn't want to contaminate the water with them. I figured plain untinned
copper wire would be okay, since water pipes are copper. Finding untinned,
unstranded copper wire was a real challenge. I started out using some FM
antenna cable, but that was stranded, and the shielding was a nightmare to
strip. It was also reasonably difficult to make go where I wanted it.
What I really wanted was something more solid, that would flex and stay
where I put it. I cannibalised a spare IEC power cable, but it was also
stranded copper wire. I finally managed to obtain some solid-core CAT-5
cable from a hardware store, and this has worked exactly as I wanted.
I haven't done any further work on the setup since getting the CAT-5 cable
for the probe. Further improvements that I'd like to do at some point:
I had a lot of fun with this project. I had a real sense of achievement,
being able to go from concept to completion, and learn a few things about
electronics along the way. I'm normally not a fan of messing around with
hardware.
Some photos of the project are here.
).
My local branch is not online yet, but I m working on it. It is basedI Deprecation of mixedCase naming conventions in apt module II Re-organisation of the apt.progress module III Language updates IV Unification of testing code V Cleanup of the code VI Using unique variable names throughout the modules VII Some other changesI. Deprecation of mixedCase naming conventions in apt module In order to comply with PEP 8, we should start to change our names
cache - An apt.cache.Cache() object pkg - An object returned by cache[str()] (in special cases) pkg - An apt.package.Package() object cand - An object returned by depcache.GetCandidateVer()This would remove some confusion for developers, especially
Since I managed to get my blogspam plugin listed on wordpress.org I've seen a surge of interest.
In the past few hours capture stats are:
| Good comments | 1 |
| SPAM comments | 100 |
# cd /var/lib/mysql/tabs_compare/Pretty big :) Now, check the table:
# ls -l
total 659500
-rw-rw---- 1 mysql mysql 65 2008-09-21 00:35 db.opt
-rw-rw---- 1 mysql mysql 12840 2008-12-25 00:44 log_1230162297.frm
-rw-rw---- 1 mysql mysql 675299244 2009-01-01 20:34 log_1230162297.MYD
-rw-rw---- 1 mysql mysql 1024 2009-01-01 20:37 log_1230162297.MYI
# myisamchk log_1230162297.MYIHopefully there is no error, so we can compress that table:
Checking MyISAM file: log_1230162297.MYI
Data records: 4293747 Deleted blocks: 0
- check file-size
- check record delete-chain
- check key delete-chain
- check index reference
- check record links
# myisampack log_1230162297.MYIAnd the result it's really nice:
Compressing log_1230162297.MYD: (4293747 records)
- Calculating statistics
- Compressing file
43.05%
# ls -lThe compress command didn't even take a full core on my machine and almost took 20secs to complete.
total 375572
-rw-rw---- 1 mysql mysql 65 2008-09-21 00:35 db.opt
-rw-rw---- 1 mysql mysql 12840 2008-12-25 00:44 log_1230162297.frm
-rw-rw---- 1 mysql mysql 384558282 2009-01-01 20:34 log_1230162297.MYD
-rw-rw---- 1 mysql mysql 1024 2009-01-01 20:49 log_1230162297.MYI
# myisamchk -r log_1230162297.MYInow tell MySQL to reload those table with:
...
# myisamchk log_1230162297.MYI
...
mysql> flush tables <schema>;Keep always in mind that compressed tables are read-only, so no DML commands, while DDL are allowed (so you can DROP it, for example).
Well that was a bit of process.
The best set of instructions I found were here.
I think a lot of the other instructions I found assumed you were at firmware
version 1.00.62. The CYT unlocker program seems to only work with this
firmware version.
The CYT unlocker program is a Windows console-mode program. It seems to run
under Wine, but I switched to Windows before I realised that possibly my
problems running it under Wine were related to the firmware version on the
RTP300 and not a problem talking to the network.
All of the remaining steps on the above page could have been performed on
Linux. In fact, the CYT unlocker program merely makes a HTTP POST to a
specific URL (and I think it could just as easily be an HTTP GET) and then
starts up a webserver on port 2400 to hand an XML blob of provisioning
information when the RTP300 requests it as a result of the HTTP POST. A
Linux version would be easy to implement.
In all of the futzing around, I noticed this gem in the HTML source of the
web interface:
*********************************************************
* Copyright 2005, CyberTAN Inc. All Rights Reserved *
*********************************************************
This is UNPUBLISHED PROPRIETARY SOURCE CODE of CyberTAN Inc.
the contents of this file may not be disclosed to third parties,
copied or duplicated in any form without the prior written
permission of CyberTAN Inc.
This software should be used as a reference only, and it not
intended for production use!
Now that I've unlocked it, I guess I should try and make it talk to my
Asterisk box...
Next.
