• file a
• dir b
  • dir c
    • file d
  • file e

And someone ,on presumably a mac or a *nix machine, added the directory “b\c”. In *nix, where the SVN server was run, this was a perfectly valid directory name. On Windows, what most of us run on, the backslash is a directory seperator.

So when TortoiseSVN tries update or check-out, it fails to create a directory like that. Even worse, when you try to delete the offending directory from the “Browse Repository”, it actually interpreted the \ as a directory seperator, so while you wanted to delete directory “b\c”, it ended up deleting directory c in b. My boss had fixed this by completely removing the trunk, and putting in a new one from his working copy, but this way you lose all history of the files, and any changes that he had made to the working set were not visible anywhere.

I fixed it by doing the following:

• First, you branch from the Trunk revision just before those faulty directories were added.
• Then you carefully merge all changes from trunk from that point to HEAD to that branch, while excluding all revisions that add those offending directories.
• Then you branch the current trunk to a branch like “MessedUpTrunkBackup” using TortoiseSVN Repository browser (You can’t do it by checkout + branch, as checkout fails)
• Then you delete the current trunk, again using the repository browser.
• Then you copy the clean branch you made earlier to trunk, using either the repository browser or by using normal branching methods.

Tada: You now have a new trunk, without the offending changes, but with full history on all files, and you can safely issue a checkout, or an update on an earlier working copy

I am aware it’s probably possible to cleanly revert those changes from a *nix box, but we didn’t have any available at the moment, so I had to do it this way.

The problem lies in the fact that the program I was working with had a stack somewhere around 0×60000 or 384kb. V8 then substracts 512 from that, but instead of getting a nice stack-boundary, it ends up with an incredibly big number due to integer underflow. The next time it checks the stack, it compares the stack address (still somewhere around 0×60000) with it’s calculated stack limited (which, due to the underflow, is about 0xFFFE0000), and assumes it has a stack overflow.

To fix this, I had to manually set the stack limit. Basically, the following code takes a random stack address, divides it by 2, and uses that as the lower-limit to the stack:

	v8::ResourceConstraints rc;
	rc.set_stack_limit((uint32_t *)(((uint32_t)&rc)/2));
	v8::SetResourceConstraints(&rc);

 LivePlatform.LivePlatformFactory factory=new LivePlatform.LivePlatformFactory();
            LivePlatform.ILiveIdentityCollection ids = factory.IdentityService.CachedIdentities;
            System.Console.WriteLine("Cached identities");
            for (int i = 0; i < ids.Count; i++)
            {
                LivePlatform.ILiveIdentity id = ids[i];
                if (id.HasPassword)
                    System.Console.WriteLine("\t"+id.Username);
            }
            System.Console.Write("Username: ");
            string szUsername = System.Console.ReadLine();
            LivePlatform.ILiveIdentity found = null;
            for (int i = 0; i < ids.Count; i++)
            {
                LivePlatform.ILiveIdentity id = ids[i];
                if (id.HasPassword && id.Username.ToLower().Equals(szUsername.ToLower()))
                {
                    found = id;
                    break;
                }
            }
            string szPassword = "";
            if (found == null)
            {
                System.Console.Write("Password: ");
                szPassword = System.Console.ReadLine();
            }
            platform=(found==null)?factory.CreateEx(szUsername,szPassword):factory.Create(found);
            platform.Config["BlockingSignin"] = true; //Don't set this to make Signin non-blocking. You'll have to wire up events to listen for OnReady before you do anything, though.
            platform.Signin(null);
            System.Console.WriteLine("Full name: "+platform.Me.FullName);
            LivePlatform.ILiveObjectCollection query = platform.Query("type(contact)");
            System.Console.WriteLine(String.Format("Contacts: {0}", query.Count));
            for (int c = 0; c < query.Count; c++)
            {
                LivePlatform.ILiveObject obj = query[c];
                LivePlatform.ILiveContact contact = obj as LivePlatform.ILiveContact;
                System.Console.WriteLine(String.Format("{0} ({1})", contact.FullName,(contact.Emails.Count>0)?contact.Emails[0].Address:"none"));
            }
            System.Console.WriteLine("Press enter to quit");
            System.Console.ReadLine();

It’ll print your full name, as well as your full contact list. Also note that if you added your facebook account, those contacts will show up too.
Some other queries I saw when debugging messenger:

type(invite)
type(contact) and contacts:canHideFrom(true)
type(contact)
type(contact) and contacts:isHidingFrom(true) and contancts:canHideFrom(true)
type(contact)
type(circle)
type(category)
type(category) and contacts:isfavorite(true)
type(contact) and contacts:isonline(true)
type(category) and contacts:isfavorite(true)

I believe that hooking this API in messenger might allow for some pretty cool tricks, for example something like BuddyFuse.

As a final note, I’d like to say that I’m posting this because I’m hoping more sharing might make the messenger community more like it once was. If you find out more about this API, or other new APIs, please be so kind to share them too so a new sharing eco-system might emerge. Thanks.

EDIT: Added cached identities.

Apparently, the power widget is in Settings.apk. This file also contains a lot of other stuff, and not suprisingly the settings dialogs are among those. Seeing as CyanogenMod adds quite a bit to the settings dialogs, simply putting back a stock Settings.apk is not an option.
So instead, we should change something inside of Settings.apk. This is what I did to get the Settings.apk (and back it up) using the Android SDK:

adb remount
adb shell
cd /system/app
cp Settings.apk Settings.bak
exit
adb pull /system/app/Settings.apk Settings.zip

Then I opened Settings.zip with winrar, and browsed around. I found the files needed in res/drawable-hdpi under filenames appwidget_settings_ind_on_?.9.png and appwidget_settings_ind_mid_?.9.png (where ? is c, r and l).
My first attempt was simply to change the colors using GIMP, but that messed up the scaling of the pictures.
To fix that, I used a program called tweakpng, and removed all PNG chunks not in the original file, and copied the one chunk that the new file didn’t have from the old file.
This targets the scaling issues, but somehow I still had some weird blue lines through the images.
Instead of turning it to white as I wanted, I figured the normal Android green would be sufficient too. So I set out to get it from a stock ROM.
I found the stock Nexus ROM, and found the system.img. Apparently it’s a YAFFS2 filesystem, and after some googling, I found a tool unyaffs (needed to compile that on a linux box) to extract it. As said before I couldn’t just take the Settings.apk from there, so instead I renamed it to Settings_orig.zip, and with winrar moved the files I found earlier from the original into the modified zip file.
Then I used

adb push Settings.zip /system/app/Settings.apk

to push it back onto my device.
After re-adding the widget, the colors were green again

• It never cleaned up the torrent files, so at this point I had well over 200 .torrent files that I really no longer needed, but still existed on the drive.
• I only had some directory for “general” torrents that I could manually deposit torrents in. This way games, linux distro’s, movies, everything I manually downloaded ended up in the same directory.
• rtorrent never actually erased any of the torrents. It stopped seeding at a point, but it would still exist in the overview. Because of this the rtorrent overview was a mess, and the only way to really make any sense out of it was to look at the “Incomplete” tab only.
• If I wanted to add a new RSS feed with a seperate directory, I had to adjust bot the flexget config and the rtorrent config, and restart rtorrent.

Now, as tvrss shut down, and I needed to reconfigure a few things, so I figured I’d better completely re-do the setup. What I came up with were a few PHP scripts that would fire on several rtorrent events and do all the hard work. Here’s my current setup:

• /media/tb/.rtorrent/data/: this directory holds all the data that rtorrent downloads or has downloaded. Incomplete files are actually in here, complete files will be symlinks to their final destination(s)
• /media/tb/.rtorrent/incoming/: This is the directory that holds all completed files
• /media/tb/.rtorrent/session/: rtorrent session info
• /media/tb/.rtorrent/torrentdump/: This is where I can dump torrents for manual downloading. Files will end up in /media/tb/.rtorrent/incoming/Dump. It also works with recursive dirs: all torrents in /media/tb/.rtorrent/torrentdump/A/B/C will be downloaded to /media/tb/.rtorrent/incoming/Dump/A/B/C.
• /media/tb/.rtorrent/torrents/: This holds the torrents actually being downloaded, as well as a .info file for each torrent holding information on what should happen with it after it’s completed.
• /media/tb/.rtorrent/scandump.sh: A PHP script that will scan the torrentdump directory, move the torrents to the torrents directory, and create .info files for each
• /media/tb/.rtorrent/oncompleted.sh: A PHP script that will be fired by rtorrent once a download finishes. This will move the downloaded data to it’s destination directory, leave a symlink in the data directory, fix up permissions, and remove the torrent and info file.
• /media/tb/.rtorrent/rtorrent.rc: rtorrent config file.
• /media/tb/Incoming: symlink to /media/tb/.rtorrent/incoming
• /media/tb/TorrentDump: symlink to /media/tb/.rtorrent/torrentdump

Let’s start with scandump.sh:

#!/usr/bin/php
<?
$suffix=".torrent";

function scan($directory,$outputpath,&$todo) {
	$d=opendir($directory);
	if ($d!==FALSE) {
		while (FALSE !== ($file=readdir($d))) {
			if ($file[0]==".") {
				//Ignore
			} else {
				$path=$directory."/".$file;
				if (is_dir($path)) {
					scan($path,$outputpath."/".$file,$todo);
				} else if (substr($path,strlen($path)-strlen($suffix))==$suffix) {
					$todo[$path]=Array(
						"path"=>$outputpath
					);
				}
			}
		}
		closedir($d);
	}
}
$todo=Array();
scan("/media/tb/.rtorrent/torrentdump","Dump",$todo);
$torrentdir="/media/tb/.rtorrent/torrents/";
foreach ($todo as $torrent=>$info) {
	$target=$torrentdir.basename($torrent);
	$infopath=$target.".info";
	file_put_contents($infopath,serialize($info));
	exec("mv -f ".escapeshellarg($torrent)." ".escapeshellarg($target));
}
?>

the “scan” function recursively scans a directory for torrent files. Every torrent file it finds will be put in the $todo array, together with the destination directory (and maybe other info). The main script will call this on /media/tb/.rtorrent/torrentdump, together with a “Dump” directory as output dir. After that, it will create a .info file for each torrent first (which contains the serialized data from the scan function), and then move the torrent to the torrents dir for rtorrent to download.

Next up: oncompleted.sh:

#!/usr/bin/php
<?
$torrent=$argv[1];
$infofile=$torrent.".info";
if (!file_exists($infofile))
	die("Nothing to do");
$datapath=$argv[2];
$info=unserialize(file_get_contents($infofile));
$downloaddir="/media/tb/.rtorrent/incoming/";
$newdir=$downloaddir;
$newpath=$newdir."/".$data;
$pathsplit=explode("/",$info["path"]);
$newpath=$newdir;
foreach ($pathsplit as $pathbit) {
	//Make new directory (with chmod and all)
	$newdir.="/".$pathbit;
	exec("mkdir -m 777 ".escapeshellarg($newdir));
}
//Move data
exec("mv -f ".escapeshellarg($datapath)." ".escapeshellarg($newpath));
//Chmod data
exec("chmod -R 666 ".escapeshellarg($newpath));
//Link old data to new data
exec("ln -s ".escapeshellarg($newpath)." ".escapeshellarg($datapath));
//Remove torrent file (will have rtorrent remove symlink)
exec("rm -rf ".escapeshellarg($torrent));
//Remove info file
exec("rm -rf ".escapeshellarg($infofile));
?>

This gets both the torrent file ($argv[1]), and the download path ($argv[2]). It tries to open the .info file, and then creates the needed directories (as read/write for everyone), moves the file, chmods it read/write, set up a symlink on the old location (for rtorrent to keep seeding), and removes the torrent and info files.

rtorrent config follows:

# This is an example resource file for rTorrent. Copy to
# ~/.rtorrent.rc and enable/modify the options as needed. Remember to
# uncomment the options you wish to enable.

# Maximum and minimum number of peers to connect to per torrent.
#min_peers = 40
#max_peers = 100

# Same as above but for seeding completed torrents (-1 = same as downloading)
#min_peers_seed = 10
#max_peers_seed = 50

# Maximum number of simultanious uploads per torrent.
#max_uploads = 15

# Global upload and download rate in KiB. "0" for unlimited.
#download_rate = 0
#upload_rate = 0

# Default directory to save the downloaded torrents.
directory = /media/tb/.rtorrent/data/

# Default session directory. Make sure you don't run multiple instance
# of rtorrent using the same session directory. Perhaps using a
# relative path?
session = /media/tb/.rtorrent/session/

# Watch a directory for new torrents, and stop those that have been
# deleted.
#schedule = watch_directory,5,5,load_start=./watch/*.torrent
#schedule = untied_directory,5,5,stop_untied=

# Close torrents when diskspace is low.
#schedule = low_diskspace,5,60,close_low_diskspace=100M

# Stop torrents when reaching upload ratio in percent,
# when also reaching total upload in bytes, or when
# reaching final upload ratio in percent.
# example: stop at ratio 2.0 with at least 200 MB uploaded, or else ratio 20.0
#schedule = ratio,60,60,"stop_on_ratio=200,200M,2000"

# The ip address reported to the tracker.
#ip = 127.0.0.1
#ip = rakshasa.no

# The ip address the listening socket and outgoing connections is
# bound to.
#bind = 127.0.0.1
#bind = rakshasa.no

# Port range to use for listening.
port_range = 12300-12400

# Start opening ports at a random position within the port range.
port_random = yes

# Check hash for finished torrents. Might be usefull until the bug is
# fixed that causes lack of diskspace not to be properly reported.
check_hash = no

# Set whetever the client should try to connect to UDP trackers.
use_udp_trackers = yes

# Alternative calls to bind and ip that should handle dynamic ip's.
#schedule = ip_tick,0,1800,ip=rakshasa
#schedule = bind_tick,0,1800,bind=rakshasa

# Encryption options, set to none (default) or any combination of the following:
# allow_incoming, try_outgoing, require, require_RC4, enable_retry, prefer_plaintext
#
# The example value allows incoming encrypted connections, starts unencrypted
# outgoing connections but retries with encryption if they fail, preferring
# plaintext to RC4 encryption after the encrypted handshake
#
encryption = allow_incoming,try_outgoing,enable_retry

# Enable DHT support for trackerless torrents or when all trackers are down.
# May be set to "disable" (completely disable DHT), "off" (do not start DHT),
# "auto" (start and stop DHT as needed), or "on" (start DHT immediately).
# The default is "off". For DHT to work, a session directory must be defined.
#
dht = on

# UDP port to use for DHT.
#
dht_port = 12300

# Enable peer exchange (for torrents not marked private)
#
peer_exchange = yes

#
# Do not modify the following parameters unless you know what you're doing.
#

# Hash read-ahead controls how many MB to request the kernel to read
# ahead. If the value is too low the disk may not be fully utilized,
# while if too high the kernel might not be able to keep the read
# pages in memory thus end up trashing.
#hash_read_ahead = 10

# Interval between attempts to check the hash, in milliseconds.
#hash_interval = 100

# Number of attempts to check the hash while using the mincore status,
# before forcing. Overworked systems might need lower values to get a
# decent hash checking rate.
#hash_max_tries = 10

# Set the umask for this process, which is applied to all files created by the program.
# umask = 0666

# Watches
# Scan torrent dump, and watch for torrents
schedule = watch_directory,10,10,"execute=/media/tb/.rtorrent/scandump.sh;load_start=/media/tb/.rtorrent/torrents/*.torrent"
# Watch for torrent files being deleted
schedule = watch_untied,10,10,"remove_untied="
# If a torrent is erased, erase the contents
on_erase = rm_files,"execute=rm,-rf,--,$d.get_base_path="
# Run oncompleted on a completed torrent
on_finished = linkup,"execute=/media/tb/.rtorrent/oncompleted.sh,$d.get_tied_to_file=,$d.get_base_path="

# Throthling
schedule = throttle_high,01:00:00,24:00:00,"download_rate=0;upload_rate=50"
schedule = throttle_low,09:00:00,24:00:00,"download_rate=500;upload_rate=20"
download_rate=500
upload_rate=20
schedule = ratio,10,10,"stop_on_ratio=1,1K,2"

# XMLRPC for wTorrent
scgi_port = localhost:5000

Some of the notable changes from a default rtorrent setup:

• Before watching the watch directory, it calls scandump.sh
• After the torrent file is deleted, it’s removed (= completed files stop seeding)
• If a torrent is erased, the data is erased. Note that if a torrent is completed, the data is merely a symlink, so no completed torrents will be deleted
• On finished, oncompleted.sh will be run

So, this is a much better setup than I had already. Some of the things I still need to fix:

• Set up FlexGet to download series, and create appropriate .info files for each torrent
• Find a way to have untied torrents seed for a while, and remove after a certain seeding threshold

I’ll be spending today on writing up documentation on that forum and doing quick bugfixes.

So I spent 3 hours of my time debugging and testing these new functions. Turns out they’re not nearly as exciting as I had hoped:

	[
	  odl,
	  uuid(929BB08C-B50C-4ECD-B68C-175F0B69A544),
	  helpstring("MSN Messenger Conversation Window Interface Ex"),
	  dual,
	  oleautomation
	]
	interface IMSNMessengerConversationWnd2 : IMSNMessengerConversationWnd {
		[id(0x0000080c), propget, helpstring("Get the window text.")]
		HRESULT WindowTitle([out, retval] BSTR* bstrWindowTitle);
		[id(0x0000080c), propput, helpstring("Set the window text.")]
		HRESULT WindowTitle([in] BSTR bstrWindowTitle);
	};

I’ve tested this in Vista, it gets and sets the window titlebar. As Vista doesn’t use the borderless-windows that WLM9 uses on XP, I’m not sure if it works on that, but I suspect that this interface has been specially generated for precisely that.

Well, either way, have fun with it. Sure hope my time has been useful for someone :p

Just felt that was worth sharing

I’ve put up the initial scaffolding for the Messenger API, and am currently filling in the functionality for the Messenger, Contact, and Conversation classes. The DirectUI (messenger’s user-interface library) module is in a somewhat usable state, and I’ve even written an old-style UIFile parser to it (written completely in Javascript). One package I haven’t started on is the Interop (= communication with external libraries) one, but the plan for that one is well established in my head, and shouldn’t be too hard to implement.

For now I’m aiming for something that is on-par with Messenger Plus!’s scripting, but once I reach that I hope to keep expanding and surpass it greatly. One of the advantages I have is the extensibility. Each package can export certain functionality, and as such anyone is free to extend the API as they wish. Someone could make a package solely dedicated to communicating with facebook or twitter, and other developers can then use those packages from their scripts, for example creating a script that keeps your facebook or twitter friends updated on how many contacts you have.

Here’s a list of a few things that are done and worth mentioning:

• Minimal main system: the main system *only* contains the bare necessities needed to load the modules and scripts. As such you can replace virtually anything with your own implementation; Don’t like the standard Console? take it out and write your own.
• Google’s V8 JavaScript engine: The same engine that’s behind the blittering speed of Google Chrome. A downside is that things like “new ActiveXObject” aren’t supported, but upsides are plenty: It’s fast, it’s flexible, it’s standards compliant, and it actually allowed me to do the DirectUI stuff (Microsoft’s JScript was a bitch when it came to threading, V8 just sticks to one)
• Code searching package: No more hard-coding of patch offsets, simply define what kind of pattern you’re looking for, and this package will find the offset(s) for you. It’ll optimize multiple patterns so only one pass over the memory is needed, so it should be really fast, and it’ll run in the background and only keep your script waiting minimally: it will return the offset the millisecond it’s found, and continue searching in the background.
• Quick and simple console package that outputs script errors, and exports functions to add messages, warnings, or errors so you have an easy way to output data to the user.
• DirectUI access: Want to remove a button from messenger? add a new one? Move the wordwheel to the bottom of the contact list? It’s all possible.
• UIFile parser completely implemented in JavaScript, allows you to define your own output callbacks (or use existing ones), so someone could easily stick in a UIB compiler.
• Packages can consist of modules (DLLs) or scripts, or even a combination of both.
• The actual Messenger API is a mess, there’s about three different ways to do things, and half of the functionality is often broken. But as a package developer you don’t have to worry about that: I’ve taken the time to write a Messenger package that takes care of all that for you, and exports an easy to use interface for your scripts to use
• Need some functionality that’s not yet in LiveScratcher but is in Plus? For now there’s a PlusCom package that allows you to make a (string values only) bridge between a Plus! script and a LiveScratcher package.
  I’m not sure if this will be useful when it’s all done, but it was a nice experiment, and might come in handy with other things.
• Need to pop up a toast? That’s already in the Messenger module with callbacks and everything. And not fake lookalike toasts, nope, actual real Messenger toasts with custom text.

Now, it all sounds really great when I put it like this, but there’s also a bunch of things that are missing (but that I do plan to implement some day):

• Debugger: as of now, all you have is some errors in the console if something goes wrong. I’m planning on exposing the V8 debugger protocol and write a nice debugger plugin for Eclipse or Notepad++ or something like that.
• More advanced Interop: For now I’m focussing on an interop approach like Plus!. A simpe way to call external libraries with integers or strings, and some memory block class for pointer stuff. When I have the time I’m hoping to come up with a nicer approach that allows you to specify a structure and it will make a memory-block automatically and catch all get/set calls to it.
• Protocol level stuff: For now I’m focussing on exposing all the API based stuff, but at some point I hope to write a proxy/protocol-analysing package that would allow for similar functionality to Messenger Discoveries’s plugins.
• RichEdit hooking: It’s going to be a big project, but I do hope to implement some kind of RichEdit hook and expose that, so scripts can implement new mark-up stuff. For example implement Plus!’s coloring, or implement a LateX package that automatically converts latex to images.

Well, now you know most of what it is and my plans about it. If for some reason you got excited (sure hope you did ) and want to take a look and give some feedback, please don’t hesitate to contact me. Just leave a comment and I’ll get in touch with you. I’ll gladly send it over and give you all the help you need to get using it. At this point however I’m not quite comfortable with just uploading it here (as it’s still very very crude and rough around the edges), so you will have to personally ask me if you want to take a peek