Caution: numbers that feel prime may be divisible by 3. For example, 51 and 57.
Conversely, numbers that feel divisible by 3 may be prime. For example, 61, 89 and 97.
Nominations for least prime-feeling numbers that actually are prime: 89 and 101.
Nominations for best prime number: 2 and 101.
Both have digits that sum to 2.
Yes, I was trying to count sheep last night.
Last night I uploaded the first public version of my latest project, Record TV. Record TV is a system for recording TV (on a Linux desktop computer) that is designed to allow lots of different user interfaces all to use the same back end. It is currently only useful for people who are quite familiar with the Linux command line. It essentially has no user interface at all, but the back end stuff works for recording TV.
Perhaps more excitingly, I have also managed to get my recorded programmes to play back on my Nintendo Wii, so I can watch them on my TV.
Find out more on the project page linked above. I’ve released this code very early, in the spirit of “release early, release often,” so expect to hack on it a bit to get it working.
If you think MythTV just goes about things the wrong way, and you’d like to help do it right, it might be of interest.
It’s mostly Python, with some PHP and shell scripts.
A job I’d like to do is to be able to use FreeGuide as a UI for selecting programmes to record.
After over a year, and several U-turns, the next version of FreeGuide is out.
I was dead-set on getting recording functionality into it, and when some students turned up asking to help, I directed them towards doing that. They produced a reasonable framework for how to do it (without any of the dirty details of actually recording stuff), but we ended up throwing it away in favour of the way Alex wanted to do it, which was as an extension of the current reminder code.
This way of doing things never reached a stable state, so the trunk was festering for a long time with broken code in it that lost your settings, and tried to record programmes but started too late, and with loads of other usability bugs that I’d hesitate to call minor since any one of them could put off someone trying the program for the first time and persuade them never to come back.
In the end, since this just wasn’t getting fixed, I decided we needed to give up on recording and get back to what we’re good at, which is being a TV guide. There is, of course, quite a lot of overlap in these two functions, but I just didn’t have time to think through properly what a recording program should do, and how to move FreeGuide over to a sensible model.
So, I reverted the recording code, and it’s there in the SVN history if anyone wants to resurrect it.
Meanwhile, the thing that motivated me to do this and actually get a release out was the fact that the US listings provider Zap2It has wound up their service, and it’s been replaced with a new one, called Schedules Direct, for which you have to pay money.
Hopefully, any US and Canadian users of FreeGuide should be able to download the latest version of FreeGuide (and update to the latest XMLTV if they’re on Linux) and start viewing their listings as soon as they’ve paid for them from Schedules DIrect. Do let us know on the mailing list if this isn’t the case.
So, hopefully the crisis has been averted, and now we can get back to doing things right. I’ve implemented the Benevolent Fascist Dictator rule, and so far, trunk is better than 0.10.5, and we could make a release from it any time. I plan to make one every couple of months, to keep things ticking along.
FreeGuide 0.10.5 contains millions of small features and bug fixes, that I didn’t manage to keep up with while trunk was broken. The next release will be after a much shorter delay, and will have a much better change log.
Why not try the latest SVN version of FreeGuide, which contains lots of bug fixes over 0.10.4? There are detailed instructions on how to Build FreeGuide from SVN, and do ask on the developers’ list if you have problems.
I’ve fixed the horrible bug that deleted all your preferences, and I think the code’s in pretty good shape, with all the recording code gone, but lots of nice additions put in over the last year.
Try it out, and let us know on the developers’ list how you get on - good or bad.
Sorry, sorry, sorry, sorry. I decided to change to wordpress’ pretty-URLs mode, and it changed the feed URL, which I was not expecting, and which I think is fundamentally borken.
FreeGuide has been stalled for about a year because the basic code for recording programmes has been sitting in SVN, but it contained far too many bugs to be useable, even by the developers. This kind of situation completely takes the wind out of development, since any little bug fixes or features people want to send it are either against very old code, or never get written because when they download the latest code it doesn’t work.
I am more and more of the opinion that the code in your trunk (or HEAD, in CVS terminology) should ALWAYS by _better_ than the latest release. I.e. it should only contain bug fixes and properly tested new features. Anything else (i.e. code that is still being knocked into shape) should live in a branch. Branches are pain, but not as much pain as your project dying because new developers who try and do the right thing (download the latest code) are confronted by non-working code and move on to something more fun.
So, I’ve reverted the recording code. If we want to resurrect it, we can branch from just before where I reverted, and then merge from the trunk into that branch any other fixes that apply.
The next release of FreeGuide will be from the trunk, and will contain bug fixes and small new features submitted by a couple of people who have stepped up to do the work. I hope, when my life settles slightly, that I might even be one of them.
New baby resolution: never allow non-completely-working code in trunk. Without new developers, your project will die.
Small hypocritical extra note: I completely broke the code in trunk by reverting the recording code, so now it loses all your settings when you exit. Use with extreme caution. This, of course, completely breaks the above resolution. I will fix it when I can, and in the meantime, Rick is looking into it, so hopefully it will be fixed soon.
I won’t waste too much of your time, but here she is:
She’s excellent, and mum is doing really well. Big brother appears to be a little bothered, but presumably that will pass.
A long time ago I added functionality to FreeGuide so people could opt to report their use of FreeGuide to under a username, or anonymously. This all happens as part of the latest version check, and you can turn it off, obviously.
Quite a long time ago, Alex broke this functionality, and I haven’t yet made a release that fixes it. Stupid, really, because the usage statistics we’ve got are all-but useless:
Hopefully I’ll get a release out soon that fixes it, and these graphs will become more sensible.
Google-friendly title, no?
Executive summary:
In your ~/.procmailrc
MAILDIR=$HOME/Maildir - is BAD, whereas
MAILDIR=$HOME/Maildir/ - is good.
The slash at the end appears to tell procmail that this is a Maildir directory, rather than something else, elusive.
For a week my messages were appearing in $HOME/Maildir, but they were just in there with names like msg.zFS, instead of going into $HOME/Maildir/new and having a name like 1282544959.Q22432E173.192.0.54.2:1,T.
This meant they effectively disappeared, and I had a quiet, relaxing week.
Followed by a panicked and expletive-filled hour or so.
When I put the slash back, new messages started appearing in my Inbox again.
I was also able just to move the msg.zFS files into “new”, and they appeared fine, which was nice.