Archive for the ‘VandalSniper’ Category

VandalSniper does the watchlist, yo!

Sunday, July 9th, 2006

It will only be a short while before all of the tabs in VandalSniper are functional! I’ve already implemented the change cache, so the recent changes list is refreshed from the last few edits to be seen on IRC. This makes refreshes instant (except for the diff summary).

Driven by the success of this method, I’ve decided to switch gears with respect to the watchlist tab. Recently I figured out why I was unable to retrieve cookies from the WebControl — it’s document.cookie, not document.cookies. I’ve added yet another parser that, using these cookies, retrieves the articles on the user’s watchlist. This will be stored somewhere, possibly refreshed periodically, and used along the same lines as the sniper tab: if an edit is seen for a watchlisted article, a notification will be displayed and it will be added to the watchlist tab.

A few improvements to the tabbed browsing interface and this is going to be by browser of choice for just browsing Wikipedia!

VandalSniper and IRC: better together!

Saturday, July 8th, 2006

I spent much of the today integrating SmartIrc4net with VandalSniper. No, VandalSniper doesn’t let you chat on IRC now. It connects to the Wikimedia IRC server and joins the Wikipedia “recent changes” channel, which gets spammed by a bot every time any change is made to Wikipedia.

Which means that we can not only save Wikipedia’s bandwidth, but we can update the UI in realtime!

So far the sniper is the only function that uses this live feed. The previous approach has been to go over the “hitlist” in round-robin fashion, checking one user every 5 seconds. This means that if you’re monitoring 6 people, it will take 30 seconds to check everyone! While sluggish, I used this approach to conserve bandwidth and CPU on both ends of the connection. But now, by passively monitoring an IRC channel, the sniper never needs to contact Wikipedia directly, and can display edits in realtime!

Currently the recent changes tab functions as before. I’m still not sure if feeding the IRC stream into the box live is a great idea, as it will be very distracting and won’t give people enough time to check each edit. But I may cache the last 100 or so edits that come out of the stream, and use that cache when refreshing the stream. This would make the refresh immediate, and it wouldn’t require a trip to Special:Recentchanges.

There are only 113 lines in Irc.cs, which is responsible for setting up the IRC connection, converting channel messages into Change objects. and passing these objects off to an event.

VandalSniper 11 released

Friday, June 30th, 2006

No turning back now. VandalSniper revision 11 has been released on Wikipedia. In addition, I am now tracking changes to the source tree with Subversion, which is what gives each release of VandalSniper its version number. I decided to number the releases with just the Subversion repository revision to simplify support and dispense with the “oh, 0.0.1 must be unstable and crappy” mentality.

Hats off to the folks in #mono, who were exceedingly helpful and supportive.

VandalSniper Beta around the corner

Tuesday, June 20th, 2006

I’ve been amazed at how easy Gtk# has made this project. If I were using MWF I’d be spending all my time trying to get the UI to behave properly when the form is resized. Simply put, Gtk#, or rather GTK+, takes care of resizing interface elements for me, and that’s one less thing — and a very complicated thing — that I have to code.

Granted, Gecko# can be a pain to work with, simply because it does not offer much in the way of interaction with a loaded page. However, in a previous post I explained how I patched jscall to allow the execution of arbitrary JavaScript on a loaded page. In combination with jscall’s existing data-passing framework, this has made my task of automating Gecko# almost painless.

The beta is almost here.

It’s alive!

Tuesday, June 13th, 2006

After many painful hours of Googling, more Googling, crying, pounding on the desk, and losing my temper in #mono, I have successfully added an ExecuteScript method to jscall, and the corresponding managed binding! With one method call in managed world it is now possible to execute an arbitrary script, passed as a string, inside of a Gecko# WebControl.

Combined with the already-existing jscall features, this means that the glue library can be injected into any page loaded in a WebControl, regardless of how that page was loaded!

I plan to reward myself by doing something that is unrelated to XPCOM in every possible way.

Gecko# interaction

Monday, June 12th, 2006

While developing VandalProof, it has become very obvious that being able to interact with the DOM of the displayed page will be vital to achieving the program’s goals. At this point, Gecko# does not offer any mechanism by which I can do this.

I talked with mikalh in #mono for a while, and he referred me to jscall, which I had been investigating earlier. Unfortunately this does not suit my needs, because it requires that a short JavaScript glue library be present on the page to work. But with further digging, it may be possible to execute arbitrary JavaScript on any page in Gecko# by making calls to C++ world, which would in turn use nsIScriptLoader to run the script.

More when/if I get it working.