1. Python
2. Cygwin
3. MinGW

I really hate doing development on Windows, which is why I usually avoid this crap, but I wanted to upload one of my projects to Github without having to remember how on Earth to install Git on Windows properly again. Maybe it would've been easier than this, but I digress.

The -mno-cygwin option doesn't actually exist anymore in the newer versions of gcc. But Windows Python 2.7's (I didn't try the others) distutils still tries to call it anyway if you actually need something compiled. After actually way more Googling than I probably should have needed, I finally stumbled upon this Stack Overflow answer.

Basically, you just need to edit [YourPythonInstallPath]\Lib\distutils\cygwinccompiler.py and remove all traces of -mno-cygwin, and try again and it'll probably work fine. Assuming you don't run into other errors (like say, actually trying to use 64-bit Python...).

Basically there's a bug on how IE's JScript expands global variable names.

If one does
for(foo in {'a':'b', 'c':'d'}) { alert(foo); }
One gets the expected alerts for 'a' and 'c'.

However, if one chooses to use the variable name 'item', as such:
for(item in {'a':'b', 'c':'d'}) { alert(item); }

One gets an error, saying the 'object does not support this action'. Digging a bit deeper, this happens not only with the word 'item', but any property of the window object, or its prototype (any property to which it responds, like toString). It seems IE JScript is expanding 'item' to 'window.item', and what results is 'for(window.item in ...', which is wrong.

This does not happen if scoping with the 'var' keyword, since then the engine knows it's a local variable, not a property of the global object.

So essentially, if you don't create a variable in a local scope with the 'var' keyword, and it's a variable that exists in the window object or its prototype, it will look for it in the window object instead of your local scope. So keep that in mind when creating loops and whatnot that may not necessarily require you to use the var keyword.

Of course, I got a little lax on my quality control. I wanted to implement some context menus on some of my elements, so I went to my go-to Chrome extension, Chromed Bird, for inspiration. I like the way his context menus are implemented and wasn't too impressed with a few others that I had checked out. So I headed over to A Beautiful Site to read up on their jQuery Context Menu plugin.

It's pretty decent. It installs quickly, has little configuration, and comes with a really nice default stylesheet that doesn't really need any changes (unless you don't want to use the included images). The first warning I should have noticed was that all of the CSS and JS HTML elements were referenced in uppercase (LI instead of li, A instead of a, etc). Ugh. What is this, 1994? Anyway, whatever.

So I set it up and it was quick and painless. I got to testing it out and it seemed to work like I had intended (I was using it in the same was Chromed Bird does, as a context menu for a tabbed interface). But something odd started to happen. I register click events on a number of anchor tags to spawn new tabs in the interface, and as soon as I would open up the context menu, none of the links would work anymore. Kind of a terrible side effect, when you think about it!

So I delved into the code, and this is what I discovered:

• It disables the standard context menu, which is fine and actually necessary.
• When the jQuery context menu opens, it registers a click event on $(document) directly. This is so that you can 'remove' the context menu by clicking elsewhere on the page.
• Once a menu item is clicked, or the document is clicked, it unregisters those click handlers on the document.

Really straight-forward, when you get down to it. The problem was that he was using a global unbind call.

This apparently has the nasty side-effect of removing ALL click elements that have been attached to any element on the page. jQuery does give you the option to pass either an event as the first option to use to unbind, or the function that was attached to the event to unbind from as the second parameter. However, because of the way the code was set up, this really just wasn't possible. I ended up having to do a very heavy rewrite to get it to work properly (and also to make it work a little more how I thought it should work).

The moral of the story is thus:

If you're developing plugins that other people are going to use, you need to be as unobtrusive as possible with your code.

It's entirely possible this is a bug or change in functionality that's happened over the past couple of years since the original release of the plugin, but it's still a design that could have easily been avoided with a slightly better design.

My updated code is below, though it does include a pretty large change in ideology over the original design. In mine, you create one context menu and attach elements to it that will use it, then remove them if they're not needed anymore. It's somewhat specialized for the way it works in my project, but should be generic enough. It does currently depend on John Resig's Class.extend inheritance model. I also removed anything that wasn't necessary for it to run in Chrome (there were a few IE/Firefox specific things), as well as the keypress functionality that had existed that I also didn't find super useful or necessary to have.

[Edit] Oops, just realized it also uses a variation of Prototype's bind() method for binding the local space of function calls to objects: Function.prototype.bind = function(context) { if (arguments.length < 2 && typeof arguments[0] === "undefined") return this; var __method = this, args = Array.prototype.slice.call(arguments).slice(1); return function() { var a = args.concat(Array.prototype.slice.call(arguments)); return __method.apply(context, a); } } ]]> http://infalliblelogic.com/2011/01/23/jquery-plugins-putting-developers-in-a-bind/feed/ 0 http://infalliblelogic.com/2011/01/23/jquery-plugins-putting-developers-in-a-bind/ http://feedproxy.google.com/~r/InfallibleLogic/~3/aalj1dAP4z0/ http://infalliblelogic.com/2010/12/03/oauth-a-space-escaping-gotcha/#comments Fri, 03 Dec 2010 09:52:05 +0000 Chris http://infalliblelogic.com/?p=72 I just finished helping a third-party developer who is trying to integrate with Formspring's API, and it brought up a pretty common problem I've seen:

Most standard URI escaping mechanisms will convert spaces to a '+' character. This works all well and fine in the browser, but OAuth is pretty finicky about its parameters.

OAuth requires the space to be sent as %20.

So in the case that your standard URI escaper converts to a '+', you'll need to add one additional step to convert the '+' to a '%20'. Otherwise, you'll likely find yourself getting Invalid Signature errors.

If you recently upgraded to PHP5.3, and you just so happen to be using XML_RPC2, you may notice that... everything works fine. But conversely, you may notice that nothing works at all and your program dies with no error messages of any sort being logged anywhere, which is less awesome. If you were smart enough to actually track down the problem, and then conversely stupid enough to actually open up the XML_RPC2 code, you'd probably find your way to XML_RPC2_Backend.

XML_RPC2_Backend is what is called when you use XML_RPC2_Client::create() to get your client object. It is a supposedly pluggable architecture so you could create your own backends to RPC2 or something, although it then has a hard-coded list of types it will actually allow, so it's not really pluggable at all, but uh.. yeah. Also, super LOLs to this snippet of useless clock cycles (what's the point of ucfirst???):

$backend = ucfirst(strtolower($backend));
        if (
            $backend != 'Php' &&
            $backend != 'Xmlrpcext'
           )

Anyway, point is, it first checks for the existence of the xml_rpc extension in PHP, and does so by force-loading the extension if it can't find the functions from the library. Seriously?? Whatever. I guess it ultimately wouldn't be a huge problem, except for one small caveat from the manual for the dl() function:

This function has been removed from some SAPI's in PHP 5.3.

Apparently due to 'stability issues', PHP no longer includes the dl() function in most of their distributions. (Why they didn't remove it completely is a mystery, honestly.) They suggest people just update their php.ini's instead or something.

THE POINT BEING: If your xml_rpc extension install either: 1) Doesn't exist because you don't want to include it, or 2) Isn't loaded by default, and you're running one of these SAPI's, XML_RPC2 will crash and burn gloriously by forging ahead and calling dl() just in case. I suggest just going directly into the XML_RPC2_Backend::getBackend() method and completely commenting out where it tries to load XMLRPCext. Seriously worthless.

I recently came across a problem where I was accessing data across multiple database instances, and it was all well and good. Until you tried to use one of the first database connections again. Running anything against it would just result in a "no such table" error.

Buh? How can there not be a table there when I just queried from it not even a second before? Doing a dump of the MDB2 object itself even showed it was using the correct database information and it claimed to be using the correct database name.

Ultimately the problem turned out to be the fact that it still relies on the old mysql_* methods. This error occurred on our dev server, which is set up to model production, but isn't quite the same. On production, all our instances are actually on separate hosts. On dev, they're in separate databases, but the host and connecting information is all the same. If you look in the PHP docs for the mysql_connect() method's new_link parameter:

If a second call is made to mysql_connect() with the same arguments, no new link will be established, but instead, the link identifier of the already opened link will be returned.

Yay. So successive calls to mysql_connect() with the same host, username, and password will return the same connection. It's a good thing to have to prevent opening too many connections, but it also largely depends on your database framework being able to correctly give you separate connections if you really want them. (In fact, I might go so far as to say it SHOULD be the code that caches connections, not the underlying driver, but whatever. mysql_connect()'s new_link param does give back a new connection if set to true.) Unfortunately, MDB2 caches the database name and checks its own cached name to ensure the database hasn't been switched, so it never detects that the same connection was pulled and switched elsewhere.

The easy fix is just to call mysql_select_db() every time you're pulling a cached DB connection to ensure your DB is correct. I'm honestly not sure of the overhead of doing that, but assuming you're not making tens of thousands of those calls, I'm sure it's reasonably minuscule. I'd honestly just suggest switching to PDO and caching your own connections, anyway.

Now obviously when you uninstall the software, it will keep this directory intact since it could potentially contain some of your music files. What it doesn't tell you is that it will automatically import any data it finds in your playlists! After running through the steps of my previous posts, it was still finding some of the albums from directories I was no longer including in monitoring and it was driving me crazy. I had kept my playlists because I had a decent number and didn't want to recreate them. Joke's on me because it just took all the tracks from those playlists and reimported every single one, including ones from when I was still using the 4.2 software!

So if you had any autoplaylists created, ensure you delete those (and really probably anything else inside that directory, to be safe) or else it will still import anything it finds in there.

First and foremost is that you can no longer keep your Libraries and your Zune monitored folders separate. If you try to remove monitored folders in the Zune software, it will remove them from your Libraries entirely, which isn't even necessarily something you want to happen! So you are forced into putting all you media into Libraries, and even more than that, you're forced into keeping media out of your Libraries if you don't want them scanned!

In my scenario, I keep a separate folder for freshly-ripped or downloaded albums so that I can tag them and set them up in such a way that they can be integrated into the rest of my collection. I like to keep these separate because there's no way to guarantee how the source of the album has tagged it, or how they've set up their album art (I am fervently against putting art in tags since it's an unnecessary waste of space) or things of that nature.

At the same time, this folder does contain music, so I do like to keep it in my Music Library so I can easily access it with the rest of my music. But now I can no longer do that with the Zune 4.2 software update because it will scan it into my collection and try to sync it with the hardware, which I absolutely do not want it to do (the Zune software already has far too many troubles with tracking moved or renamed files).

I was fortunate enough to still have my installer for 4.0, and I would urge anyone who does not like this change to uninstall 4.2 and revert back. One thing to keep in mind, however, is that the software will attempt to auto-update when you run it, so you'll need to disable your internet connection during the install. After that, it will just prompt you when you open it and you can ignore it, if you'd like.

I just don't understand how it's so difficult for these guys (Microsoft and Apple) to get their software right. Why do we need it to be tied to some ridiculous piece of software? Why can't we allow syncing from anywhere? I understand that it gives them far more control over how you use your media, but it's ridiculous for the end-users to have to conform to that.

Back when zAlternator was actually functioning, I used MediaMonkey to sync and I found one thing out: The hardware has far, far less limitations than the software. The software requires you to rename all your album art to ZuneAlbumArt.jpg, where the hardware could read folder.jpg or cover.jpg just fine. The software will create a ridiculous database and throw all your files randomly onto the player where with MediaMonkey, I just synced my files over in the exact directory structure I have at home, and the player found and played it all fine.

The Zune is really a great piece of hardware, it's just such a shame to see such a terrible excuse for software holding it back.

I picked up the Java Pocket Guide for three bucks and it was well worth the money. Near as I can tell, these are complete versions of the books at hand, and they're all running with the very slick Aldiko UI, which has many configuration options for font sizes and other reading preferences, as well as the ability to bookmark and view a table-of-contents and other things.

For those of you that have a debug or rooted phone (or the ability to pull APKs off your phone via ADB), you'll find that the files are also just split up via HTML, with an XML-based table-of-contents. I've created a quick XSLT file you can use to transform the TOC into a basic HTML file so you can browse the book on your computer if you want. You'll need to make one change to the toc.ncx file, right below the <?xml?> tag:

Then put this file in the same directory and name it 'toc.xslt' (note that I haven't used XSLT or much Javascript in like 8 years, so this may suck). I've updated it to include some basic javascript for easier navigation between the pages!

I've admittedly only tried this with one book, but I can't imagine the rest use a different format.

Aldiko Book Reader:

Java Pocket Guide:

The PS3 backup detected the correct partition and backed up like a charm. The WHS, however, didn't. Instead, it detected the PS3 partition I had created. It would correctly display the full size of the hard drive in the Server Storage tab, but when adding a new drive, it would only detect the PS3 partition (which was much, much smaller).

After some fiddling around (and accidentally reformatting the PS3 partition to NTFS, whoops!), it seems like the WHS will basically just take whichever drive has the lowest drive letter alphabetically. My PS3 partition had been set up with F:\ and the Backup partition was set up with G:\, so it was detecting the PS3 partition first. I swapped the drive letters and it detected the correct partition and everything worked swimmingly.

Kind of annoying, but I'm happy there's at least a workaround. I'm a little curious as to why WHS doesn't let you treat the individual partitions on an external drive separately, though.