cc1.exe: error: unrecognized command line option ‘-mno-cygwin’
All I was really trying to do was install the hg-git extension, but somehow this led me to have to install:
- Python
- Cygwin
- 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...).
[Javascript] Internet Explorer namespacing
We just ran into a ridiculous bug here that doesn't seem to be mentioned in many places. The best post I've seen about it is here:
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.
[jQuery] Plugins putting developers in a bind
So I've been working on a Chrome extension for a little while that utilizes jQuery. In the true spirit of being smart and lazy, and taking advantage of the huge community that jQuery has, I've naturally pulled in a number of plugins from other developers.
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:
[OAuth] A Space-Escaping Gotcha
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.
[PHP] Still using MDB2? Getting a “no such table” error?
So we're currently stuck using MDB2 at work. Like a vast majority of PEAR's repositories, it's just awful, awful code. I'm sure it served some kind of purpose before PDO came along (like what 5 or more years ago??), but now it's just a thorn in the side of any decent developer stuck dealing with it.
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.