DoctorMo's Blog

I was rethinking my ideas I had a few years ago about repeating dates and events. Basically there isn’t a pattern of repeated dates which should not be able to be represented with a simple definition and shouldn’t require custom code to do it. this took the form of simple strings like:

1m10d – 10th of Every month
1y11m5d – 5th November every year
2w2d – Every second Tuesday

And so on. But just suppose you wanted to calculate new and full moons, which is something I had to do for yesterday’s calendar. then you’d have to add 29.35 days to the previous known new or full moon date/time. That necessitates a seeding value which other repetitive dates don’t require. Although most events have a start date anyway which can be worked from for these kinds of problems, it would just be a case of adding the time delta back on.

I’m considering that these delta repeats might be a wholly separable form of repeating date/times which should be dealt with in a different way.

Thoughts?

As promised yesterday, here is the calendar for 2010 without personal dates:

Hope you all had a good new year.

I wrote this nifty script in python to take the output from the cal command and parse it, using an svg template it outputs an entire calendar in your own style, with your own pictures and everything.

It was a bit rushed because I was making a personal calendar for my wife with birthdays, anniversaries and our family pictures on it. And it came out really well too, she’s very happy with it! Here is a page from the calendar:

A big shout out to Inkscape, which again was flexible enough to allow me to create my calendar template without complaining about missing images or custom svg xml. If you want to have a go yourself at making a calendar then just download the following package:

calendar-creator.tar.bz2

Populate the flips directory with your own png files 01.png – 12.png and a title.png file for the front page, add any extra dates you want to the dates.lst, then run `./create-cal.py 2010` on the command line this will make a whole set of svg files for each page. You can then run `./make-book.sh` which will use inkscape (make sure it’s installed) to generate png files of each page.

Once you have your images, you can print them out in order or create a pdf of them using imagemagik’s convert command: `convert pngs/*.png full-calendar.pdf` but be aware this file might get big and generating these things takes time.

I will post a complete calendar tomorrow.

Recently I’ve gotten to grips with using Clipping Masks in inkscape (Object > Clip > Set / Release) this feature allows an artist to create a complex picture which bleeds out over it’s intended boundary but then to have it’s boundary cut short later by a defining shape.

I have to say I’m quit fond of the clipping and masking techniques now. I’m sure I’ll be using it much more in future works. For instance I used it to make this google ad-words type image for our Anime Boston event (see image right).

What do you think of all the advanced features in inkscape?

Good news, today we’ve released chapter 04 of the ever wonderful Ubunchu manga first published in Ascii magazine in Japan. With translations from Vlad and editing by Arturo, this chapter is cute, cuddly and informative. Check it out!

Go to Chapter 04

This chapter is all about the lovely Risa creating a short comic and the discussions the systems administration club is having about licensing. Wonderfully done by Seotch san as always and I hope you enjoy it too.

Here is a preview screenshot of the current commit screen, it doesn’t yet allow you to choose which things to commit and which not, or show you any diffs, but it does commit files and auto add any new ones.

Thoughts?

I’ve been trying to come up with some kind of brand for my ground control project, and it’s a bit of a hard one since I think my head is far too much in the code to be able to come up with something that is both easy to recognise and visible at small pixel widths.

This is my idea:

Thoughts?

These are the words I use and the way I use them:

• How to – A specific work-flow given as list of commands with breif descriptions of what they do.
• Guide – A tour of a specific work-flow with verbose explanations and tangents.
• Technical Documentation – A document that describes the internal workings and mechanisms.
• User Documentation – An explanation of every feature available to the user and how to use it.
• Manual – A blend of user docs and guides to add context.
• Definition – A brief description of the use and mechanics without example, see wikipedia.

I hear that there is still friction between the Ubuntu Manual team and the Ubuntu Docs team.

I can’t see why, the wiki documentation is a great resource and while it has problems that stem from it being a wiki system, it’s been useful to me and to a lot of people I know. The most important parts of it are kept up to date even though it’s been criticised for becoming out of date too easily and for people to be mislead easily into following guides for older versions by mistake.

On the other hand the Manual team is new, brand new and has all the passion of a bright and eager team that might be able to make some nice documentation for Ubuntu which should be fairly easy to share back to the wiki and the Docs team in general. The manual team is also concentrating on a definitive, narrow band guide to be published on release for new users to get to grips with Ubuntu. It’s non rolling release really separates it from the Doc Team’s work and is perhaps a drawback in our ever changing work. But I think as long as each manual release is very clearly labelled, they should avoid that problem.

But even if the two teams end up sharing 90% of their content, the production of the result is where the work is going to be. I mean I think that some content from docs and manual is most certainly going to end up in some of the learning team’s classes and visa versa, but there is work there in each team which isn’t relevant to it’s peers. I don’t expect docs or manual to write quizzes or demonstration lesson plans for teachers, nor do I really expect the docs team to write all the tools and organise the compartmentalisation that will be required to produce a self contained manual.

It’s also likely that the intonation and pacing of each document source is going to be different anyway, just because the expectations are going to be different. We’re planning for, in the learning team, on being able to pull data in from other sources, but we don’t expect to be able to pull it in with a simple automated copy. It’s expected that an editor will have to go through it anyway.

What are your thoughts? Is there too much duplication? Is the manual project a sub-section of the Doc’s Team work?

This is what python threading does to people:
My work on groundcontrol is trialling thanks to nautilus being based on gtk and the Thread class which is supposed to provide easy threading. And bzrlib, which may or may not be thread safe, but never actually functions in a thread even when self contained in one thread.

It’s turning into a real dogs breakfast and advice from other devels says to avoid threading in python… that may not be acceptable for this project. I’ve managed to solve now most problems via not having threads but instead loading at opportunistic times. but it’s ridiculous to me how badly Thread, gtk and bzrlib mix and how much time I’ve wasted trying different solutions. So desperate was I that I even tried using subprocess to fork out a separated script.

Now I know a lot of this is due to not knowing the precise operating functionality of threads in python… but the subject seems to operate on some kind of uncertainty principle where the more a person knows the less likely they are to explain how it works, conversely the less someone knows the more likely they are to try and explain it wrong.

So anyone know any _really_ good guides on python threading that explain it and demonstrate it? So far the guides I’ve found have been wrong.

Update: The community does not disappoint… a great simple guide in the form of a pygtk faq was most helpful, provided by M.K. Erlandsen below in the comments. Also useful is the multiprocessing explanation provided by Jess S.