Python migration to Hg

When it was mentioned that Python would be migrating to distributed version control, I couldn't help but sigh. There was no benefit for me personally that I could see, and if Python went, it was likely Stackless would have to also. Half of the work involved in maintaining Stackless Python is merging in the code from the Python branches.

But having moved back to New Zealand, where the internet connectivity is not as good as it is overseas and is also charged per gigabyte, the idea of using a distributed version control system has immediate benefits. Now, I can't wait for the switch to go ahead.

Reading posts to the python-dev mailing list querying whether the migration could be accelerated, reminded me of a conversation I had with Martin v. Löwis at PyCon. Martin said not to worry, if the migration went ahead, Stackless would be migrated too. So, seeing the activity on this subject, made me wonder if I should subscribe to the mailing list and try and throw in a reminder for Stackless to be migrated as well.

I was pleasantly surprised to see the following in the progress report by Dirkjan Ochtman:

Richard Tew has indicated that he'd like the Stackless repository to also be converted.

Thanks Dirkjan, thanks Martin!

Finding removed content on Sourceforge

Sourceforge is filled with noise. Projects that were created and never started, projects that were started but never really taken anywhere and in general just such a mass of projects that searching there for new and interesting ones is too much effort. Occasionally, someone will mention an interesting project hosted there and that's pretty much the only way I go to sourceforge these days.

While casually browsing through the Flipcode archive for articles related to software rendering, I stumbled across a reference to a project called 'sw-shader'. At some stage, the open source project was cleaned out when the technology was sold to TransGaming where it was improved and released as SwiftShader. None of the downloadable source code archives or binaries once made available by the project were available any more, and the homepage set to redirect to the SwiftShader page at TransGaming.

This isn't the first project that has "gone dark" on sourceforge. Another is 'flux3d', a project for the FluxPlayer source code. And another was for the Elephant versioning file system, although I cannot remember the name of its project.

In the past, you used to be able to go to a sourceforge server where tarballs were automatically generated for all projects and find a snapshot of a project's CVS repository. This seems to have gone the way of the dodo. You also used to be able to go to a sourceforge server where the files made available for download by a project (removed or not) could be browsed. This appears to also have gone the way of the dodo. Sourceforge claim that data is not deleted, only hidden, yet it seems almost impossible to locate that hidden data, where it was trivial before.

Please note that data that users or SourceForge.net administrators "delete" from the SourceForge.net site is merely hidden, but retained for perpetuity. It is not necessary to restore this data if flagged as deleted; contact us for assistance.

One of the sourceforge mirrors is browsable as a folder hierarchy of downloadable project files. As can be seen in the given link, no files are present for the 'sw-shader' project. 'download.sourceforge.net' cannot be connected to either, so that is a false lead.

Eventually I found a link to another mirror where sourceforge project files are accessible, one that contains all files, hidden or not. Files are available for the softwire project and the sw-shader project. Also for the flux3d project. I have no idea whether there were ever checkins to the CVS repositories.

It's not the most ideal solution. It used to be so much easier to track these things down. It's possible that I could contact sourceforge and ask, but I wanted to see whether I could track down what I wanted without the break in attention span that the delay involved in that contact would cause.

Shipping books to New Zealand via M-Bags

The bulk of my possessions that I actually wanted to ship back to New Zealand were books. I had around 200kg of books, to a large extent from the C.C.P. North America damages bookshelves which employees can help themselves to. The original plan was to ship all of them in boxes by sea, but as tends to happen, I recalled the movie Fight Club and Tyler Durden saying along the lines of "the possessions that you own, come to own you." So I threw most of the books in the apartment complex dumpster and went with the cheapest easiest way of shipping for the rest. Someone suggested I should have ebayed the ones I didn't keep, but it seemed kind of unethical.

The cheapest way of shipping I found was to use M-Bags. Like most things in the U.S.A. where bureaucracy is involved, the U.S.P.S. doesn't give a simple description of how to ship this way. But the gist of it is that you go to the post office and they give you a number of bags that look like this:


Along with these sacks, they give you an address tag to fill out. You can see the one attached to this sack in the upper right of the photo above. And they also give you a customs sticker. You fill out the customs sticker declaring the value of the books, and describe them. I put "personal possessions (books)" as I was moving back to New Zealand and can ship possessions without Customs charging me for them.

I was a little worried about the condition the books would arrive in, so I wrapped them in shrinkwrap to protect against water damage, then wrapped them again in bubblewrap. I also held back on sending too many books this way because I was concerned about whether it was worth it, comparing the U.S. price of the books versus the cost of shipping this way. This proved to be a mistake as everything in New Zealand is very expensive.


It turns out I was right to be worried about the condition of the books in these sacks. Even at the post office in the states, I was concerned whether the velcro strap used to fasten the bag shut was anything more than a token effort. The first bag to arrive at the N.Z. address I sent them to, didn't. Several bubblewrapped bundles of books arrived.

Given the amount of money I spent to ship these books, I was a little bit worried by this. Several days later more bubblewrapped bundles arrived along with the second sack. Another worry was that some bundles might have gone missing, but an inventory showed that all the bundles from both sacks were present. It was just as well I put an address label on each bundle, with my name and address. Not sure why I did it, but if I hadn't I might have lost a whole sack of books.

There was a little damage to the hard-cover books, with bent corners, but other than that the only other damage was due to the missing sack. Somewhere along the lines, someone had combined book bundles for easier courier shipping with hard plastic tape, crushing a book or two.

Here's a page complaining about price increases in M-Bag shipping. It looks like it used to be a really cheap way of shipping books (which is pretty much all you're allowed to put in M-Bags).

I was just looking up prices here in N.Z. for two of the books (A and B) I shipped. The combined price of these two books easily covers the shipping cost of one of the sacks.