Forced fsck on Ubuntu 8.10 boot

During the boot I got one of those "filesystem has been mounted X times, time for a checkup" messages. I didn't particularly want that, I had other things to do, so pressed Esc to skip. It kinda hanged, and I may have pressed Esc again. Messages spewed across the screen, and Iwas forced to a shell prompt with an instruction to run fsck. Didn't want to do that, so rebooted. Dumped to shell prompt again with an instruction to run fsck. On running fsck, I get many screens of not-very-nice looking messages, and then this:

Buffer I/O error on device sda1, logical block 16777358

Error reading block 16777358 (Attempt to read block from filesystem resulted in short read) while getting next inode from scan. Ignore error? yes

Force rewrite?

Scary. Similar messages have been seen by others, and they've succeeded to get their system back by answering 'yes' to the above questions. Personally, this looks like the point where you will likely lose everything, so if there's anything you value, seek professional help. Answering 'yes' worked for me, but I have no idea what damage has been done. Time for a new hard drive.

Building Firefox Round 2

Things are better the second time around? Rewind 8 months, I was struggling with a debug build of Firefox, nothing was working right. Well, the hint may have been in what I was compiling. I eventually got a build working, but looking back at that, I was building the wrong thing, I was building from cvs when it seems I should have been using Mercurial. Ugh. Makes some amount of sense, but looking at MDC I can see why I thought I was doing the right thing:

"Those doing active development can check out the latest source using CVS"

Which seems to contradict other information on the page. I'm always hesitant with editing this stuff; there are smarter people than me working on this, maybe it's right. I'm pretty darn sure it's wrong.

So, I've bought a new hard drive, installed the latest OS I favour, and starting fresh. I'm building from Mercurial looking at jbostons' wiki content on the build process for Ubuntu. and checking against MDC's build options info. It's been lovely. Here's some feedback I certainly didn't get last time:

checking for stdint.h... yes
checking for inttypes.h... yes
checking for sys/int_types.h... no
checking for GL/glx.h... no
configure: error: Can't find header GL/glx.h for WebGL (install mesa-common-dev (Ubuntu), mesa-libGL-devel (Fedora), or Mesa (SuSE))
*** Fix above errors and then restart with "make -f client.mk build"
make[1]: *** [configure] Error 1
make[1]: Leaving directory `/home/matt/Projects/mozilla/src'
make: *** [/home/matt/Projects/mozilla/src/ff-debug/Makefile] Error 2

What? It couldn't find a header and told me what to install? We are certainly living in the future.

sudo apt-get install mesa-common-dev

Running the debug build has also been a joy. I don't remember getting this much feedback at the console last time, I'm not entirely sure it's all good news:

++DOCSHELL 0xb11bbac0 == 5
WARNING: NS_ENSURE_TRUE(browserChrome) failed: file /home/matt/Projects/mozilla/src/docshell/base/nsDocShell.cpp, line 9888
WARNING: Something wrong when creating the docshell for a frameloader!: file /home/matt/Projects/mozilla/src/content/base/src/nsFrameLoader.cpp, line 1017
WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005: file /home/matt/Projects/mozilla/src/content/base/src/nsFrameLoader.cpp, line 1041
WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005: file /home/matt/Projects/mozilla/src/content/base/src/nsFrameLoader.cpp, line 197
pldhash: for the table at address 0xb11bbee8, the given entrySize of 48 probably favors chaining over double hashing.
++DOCSHELL 0xb11bbe80 == 6

But it's better the second time around.

Burying The Dead

Sigh. The time has come. I'll try to develop a more detailed post mortem, might create some content for a small bit of a thesis.
Partly in an effort to find a memory leak, way back in March I went about splitting the Bittorrent XPCOM work into separate reusable components. With hope, things like BirdTorrent could make use of these components, as the code is reliant on Mozilla's platform rather than any direct system calls.
Things attempted:

• Splitting the work into parts eg. Server, PeerFactories, Torrents, Bencoding library, BitTorrent Wire library, BitTorrent Utility library
• One step build
• Testing of individual components

These didn't go well. Things didn't go well at all. The fact that the last release of something usable was February, and it's now November, isn't a particularly thrilling fact. Pretty much each task I've gone along with in that time has stalled at some point, so now my project has more loose ends than functioning ones. There's been times when I've thought it might get better, but I don't really have the support needed for this development (or not willing to ask for it, because it needs too much). It's damn irritating, but at this point I think fixing what's broken would take more time than just starting again.
My aim is to let the current work die. Start afresh, and as it goes I hope to pick through the bones for what may be used, without inheriting the bits that caused this collapse.

Wasted Time

I have no sympathy for plagiarists in education, they have literally wasted weeks of my life this year.

If you haven't learnt any damn thing well enough to do the work yourself, for what work will the degree aid you?

XPCOM Bittorrent Tracker IDL

Here's the working copy of the IDL I'm working on for the Bittorrent tracker component.

#include "nsISupports.idl"
#include "nsIVariant.idl"

[scriptable, function, uuid(a2a97e13-ddab-4a8c-a72e-45f3c26e5dce)]
interface nsIBittorrentInformation : nsISupports
{
    nsIVariant get(in ACString key);    
};

[scriptable, function, uuid(8bd92751-6566-4e8c-9d65-9a84195876d9)]
interface nsIBittorrentTrackerListener : nsISupports
{
    void update(in nsIBittorrentTracker tracker, in nsIVariant information);    
    void onError(in nsIBittorrentTracker tracker, in nsIVariant information);    
};



[scriptable, uuid(eb4f9895-e19a-4655-95d6-de801075e303)]
interface nsIBittorrentTracker : nsISupports
{
    void init(in ACString announceURI, in nsIBittorrentInformation infoSource);
    void start();
    void stop();
//    boolean forceUpdate(in boolean ignoreInterval);
    void addTrackerListener(in nsIBittorrentTrackerListener listener);
    void removeTrackerListener(in nsIBittorrentTrackerListener listener);
};

BittorrentInformation is just a simple map, the source for finding basic information about a torrent: info_hash, peer_id, port, uploaded bytes, etc. Perhaps this should be an interface with those attributes? At the moment, I find the thought of adding more and more interfaces for simple information a waste, but would be glad to hear differing opinions. I expect if the key isn't found, then an exception would be thrown.

The listener is for receiving the tracker updates, or errors if the tracker has issues. For example: a PeerManager may listen for tracker updates to record new peers.

I've thought about adding fancy extras to the Tracker, (eg. force updating, setting auto-retries) but this seems like predicting usage of the component before there's actually usage. Hoping to keep it simple.

I expect that the components implementing these interfaces will be completed this week. I'm also expecting to migrate new code from the current firewalled SVN repository to Google Code (Bittorrent4XPCOM).

Nice to be back at work.

Update - Refactoring Bittorrent for Firefox

Just a small update.

So, what's the state of the Bittorrent for Firefox extension? The last released version works, is fine for use on smaller torrents but needs thorough debugging to find some leaks that become quite bad on larger torrents.

So, what am I doing? Well, I've been caught up in the academic year; I've been tutoring, and will be lecturing in a few weeks. It's taken time away from some research (particularly some experiments) I'm doing using P2P for content delivery. Ooh! Fancy! Disregarding that, I've been refactoring the existing code so that components can be used independently of one another as complete XPCOM components. A previous post provided a Bencoding component for encoding/decoding data structures, and more recently I've been refactoring the Bittorrent Tracker client code. It's painfully slow, but should be nice. If you can see yourself using bittorrent XPCOM components, I'd love to hear the interface you'd like.

So, what to look forward to? The code for shutdown of torrent has been corrected, and will be released on request or once refactoring complete. If anyone wants to build a different Bittorrent client, they can look forward to using the refactored and separated components. In the future, I'd like to see the downloads appear in the Download Manager, instead of in the current version's Tools > Torrents menu (this way I can piggy-back on the status bar download progress without taking up more space, and it also makes managing torrents easier for the user), though if anyone else would like to write that, that'd be wonderful. ;-)

Question: Preferred Behaviour on Torrent Problems

What kind of response would you like if:

1. The torrent file was corrupt
2. The tracker doesn't exist (therefore can't download)
3. The tracker may exist, but isn't responding (maybe can't download)
4. There are no peers (therefore can't download at the moment)
5. There are no peers accepting connections (therefore can't download at the moment)
6. Peers won't share after, for example, a minute of waiting (therefore can't download at the moment)
7. Given the peers we have seen in the last, for example, minute, no-one has the complete file we're interested in (therefore can't complete download at the moment)
8. There is a problem saving to the specified destination
9. Firefox is closing (there is the possibility of resuming when re-opening Firefox)
   
10. The download is complete