Good news: sequelize no longer has opaque global leak errors when using mocha: https://github.com/sequelize/sequelize/pull/1051
The errors are MUCH less opaque and much more relevant to the test failure when watching your tests fail. For example, when you try to create a model with a column that does not exist in your schema:
Error: SQLITE_ERROR: table articles has no column named ‘new_column’
Which is much more useful than a notification that the library that you’re using is leaking globals. Yay!
While trying out sequelize, I was TDD’ing some code using mocha and reached this error from mocha while watching a test fail:
Error: global leak detected: columnTypes
So I looked through the code and found https://github.com/sequelize/sequelize/blob/f16f39221d9f3be64d7fd58235d5420eba4e10be/lib/dialects/sqlite/query.js#L38 which certainly looks like it would be a global leak, since the code is referring to “this” inside of an anonymous function.
However, inside the sequelize tests, “this” was referring to some sort of representation of the query, likely due to an “apply” or “call” somewhere. Some time later, I just tried to get the test to pass, and once I sync()ed the table and added some columns to the model, it did.
Long story short: that is the error that you get when:
- the table does not exist
- the model does not have any attributes
I went to spend a bit of time with Go today, and attempted to update go from 1.03 to 1.1. I tried:
sudo add-apt-repository ppa:gophers/go
sudo apt-get update
sudo apt-get install golang-stable
But this resulted in nothing; still 1.03. I went to the PPA page for Go and saw version 1.1, but it was not showing up on my local box. Perplexed, I started poking around and found the package details page for golang-stable. The build had failed on the 15th and it hasn’t been updated since.
So, it’s simple enough to build from source:
sudo apt-get build-dep golang-stable
dpkg -i ../golang-stable*.deb
And now I have the newer version. Hopefully the build will be fixed when the package is published next and I won’t have to do this again.
Back in the day when I needed to share files, I would do:
sudo apt-get install thttpd && thttpd -p 8001 -D
This serves the current directory via http. I would then send a link to someone using either my machine’s IP or (better) its mdns name. It was a simple way to send large files to other people on the local network. Once files were transferred, I closed the server.
I had need of it again yesterday, but was surprised to find that thttpd was no longer in Debian/Ubuntu. I fell back to another alternative:
python -m SimpleHTTPServer
But found it astoundingly slow even for the simple use case I had. After looking around at alternatives, I ended up with:
sudo apt-get install cherokee && cherokee -p 8002 -r ./
Hopefully by writing this, I can remember it.
I spent a fair amount of time tracking down this most recent problem with firefox, which manifested itself when a large amount of whitespace was entered into a textarea (or a pre). Firefox did not add line-breaks, even though the textarea CSS has “white-space: pre-wrap” and “word-wrap: break-word”. This resulted in the textarea overflowing.
Searches yielded nothing, but a few minutes on irc.mozilla.org#firefox gave me a bug:
I did learn something about CSS, though: long chains of whitespace are considered a word from CSS’ perspective. Without “word-wrap: break-word”, the chain of whitespace should not be broken.
As an amusing aside, Google autocompletes “firefox is the new” to “firefox is the new ie”. After mentioning this in the #firefox irc channel, someone was quick to reply that Google also autocompletes “chrome is the new” to “chrome is the new ie”. However, “opera is the new” does not get autocompleted to “opera is the new ie”.
The end result was falling back to “white-space: normal” for the affected elements. Not ideal, but good enough for now.
For the past few weeks, I’ve been trying to figure out why my app was mysteriously gobbling up memory. From a practical standpoint, it doesn’t matter since I have 32GB of memory. However, my customers likely don’t have that much memory, so seeing one of chrome’s processes eating up 600MB of memory bothered me and I spent a while every week trying to figure out what was going on.
I also found that the process would get unstable and slow after a while, likely due to the excessive amount of memory being marked and swept during garbage collection.
The one consolation is that it was not just my app; gmail and (oddly enough) the google instant autocomplete process gobbled up even more memory.
I tried out firefox and it didn’t have the same memory leak problem (that I could tell.) I tried chromium and it did not have the same memory leak problem (though it did/does randomly crash when I monitor its memory usage.)
I use three extensions with chrome:
I experimented with disabling them, but that did not seem to change anything. Finally, I removed all three today and the memory leak disappeared.
I’ve now added them back, with the exception of Vrome. I am now without my vi keybindings in my browser, but at least I can better judge memory usage.
Which resulted in the first browser-dependent conditional in my browser-side code.
Unfortunately, jQuery 1.9 removed jQuery.browser. So I had to reimplement it using some jQuery-migrate code as the basis.