Pads a string left or right to a certain length. If the length of the string is bigger than the value of n, the string is truncated.
str is the value to pad; n is the total length. Positive for right padding and negative for left padding. ch is optional and denotes the pad character. It defaults to a space, when str is a string. When str is a number, ch defaults to a zero.function pad(str,n,ch) { if(typeof str=='number') { str=String(str); if(arguments.length<3) ch='0'; } var N=Math.abs(n); if(str.length>=N) { return n>=0 ? str.substr(0, n) : str.substr(str.length-N); } return (n>=0 ? str : '') + new Array(N-str.length+1).join((ch||' ').charAt(0)) + (n<0 ? str : ''); }
Some examples used as unit-test, inspired by Python's doctest.
function tst(a,b) { if(arguments.length==1) console.log("Starting: "+a); else console[a==b ? "info" : "error"]("[%s|%s]", a, b); } tst("PAD test"); tst("doe", pad('doeke', 3)); tst("doeke", pad('doeke', 5)); tst("doeke ", pad('doeke', 7)); tst("eke", pad('doeke', -3)); tst("doeke", pad('doeke', -5)); tst(" doeke", pad('doeke', -7)); tst("0123", pad("123", -4, "0")); tst("0123", pad(123, -4));
After downloading and installing the most recent WebKit too much times, I wanted to update it with one simple command. Since I know a lot of languages, but most of them not too well, I ended up with two scripts. Not very flexible, but it works for me.
I save both scripts in my ~/bin folder. The WebKit image is saved on the desktop. If you have a better solution, give me a ring.
This one gets a link to the most recent (better: first) build of webkit, and echo’s it.
import urllib from xml.dom.minidom import parseString f = urllib.urlopen("http://nightly.webkit.org/builds/trunk/mac/rss") dom = parseString(f.read()) item = dom.getElementsByTagName("item")[0] link = item.getElementsByTagName("link")[0] print link.firstChild.nodeValue
This is a bash script which does all the work and can be called to update the WebKit installation. Note: I keep WebKit in my (personal) ~/Application folder.
#!/bin/bash curl `python ~/bin/webkiturl.py` -o ~/Desktop/lastest_webkit.dmg hdiutil mount ~/Desktop/lastest_webkit.dmg cp -Rf /Volumes/WebKit/*.app ~/Applications hdiutil detach `df | grep WebKit | perl -pe 's@^/dev/([a-zA-Z0-9]+).*@$1@'` rm ~/Desktop/lastest_webkit.dmg
At the blog Flagrant Badassery I found some very thorough javascript trim research. I was really amazed by his findings. Did you know there’s a (performance) difference between /\s+/ and /\s\s*/? I thought the regular expression engines would optimize these differences away.
Please do read the article, for it’s pretty interesting. After reading the piece, I had two questions. What was the situation on Mac OS, and of course I had to test my own implementation. After coding, I realized the implementation was similar to the trim10 implementation. The code:
var trim12=function(s) { var whitespace = ' \n\r\t\v\f\u00a0\u2000\u2001\u2002\u2003\u2004\u2005\u2006\u2007\u2008\u2009\u200a\u200b\u2028\u2029\u3000'; var i=0, j=s.length-1; while(i<s.length && whitespace.indexOf(s.charAt(i))!=-1) i++; while(j>i && whitespace.indexOf(s.charAt(j))!=-1) j--; return s.substring(i,j+1); }
It turns out, this code is pretty fast. The difference with trim10 is it only makes one copy of the string.
But now to more interesting territory: How is the Mac doing? These figures are from my old iMac G4 @ 700Mhz, which is serving me well. I couldn’t test for Internet Explorer, since I installed OS X 10.4 from scratch. But it’s dead anyways. So is Netscape 4.
The results:
| Layout engine | WebCore | Gecko | Presto | ||
|---|---|---|---|---|---|
| method\browser | Safari 2.0.4 | Webkit 24064 | Firefox 2.0.0.4 | Camino 1.5 | Opera 9.21 |
| trim1 | 11.9ms | 12.3ms | 6.5ms | 6.8ms | 28.7ms |
| trim2 | 12.8ms | 13.8ms | 10.6ms | 10.3ms | 30.6ms |
| trim3 | 17.1ms | 17.7ms | 15.5ms | 16.6ms | 44.3ms |
| trim4 | 17.9ms | 18.4ms | 16.0ms | 14.8ms | 43.7ms |
| trim5 | 29.4ms | 43.3ms | 29.4ms | 27.8ms | 39.3ms |
| trim6 | 29.6ms | 44.8ms | 38.8ms | 31.9ms | 84.2ms |
| trim7 | 29.3ms | 43.4ms | 25.9ms | 26.6ms | 41.1ms |
| trim8 | 12.2ms | 12.6ms | 29.8ms | 27.7ms | 33.2ms |
| trim9 | 17.5ms | 11.3ms | 32.1ms | 32.5ms | 1038.5ms |
| trim10 | 0.4ms | 0.4ms | 0.3ms | 0.1ms | 0.3ms |
| trim11 | 0.7ms | 0.6ms | 0.9ms | 0.8ms | 1.5ms |
| trim12 | 0.3ms | 0.3ms | 0.3ms | 0.2ms | 0.3ms |
I ran every test 20 times. For every test, I did a “cold start” (loaded the page fresh into memory). After pressing start, I didn’t touch my computer until it was finished. One of the very odd things is, trim9 really takes forever on Opera. Further, there are no surprises. Except maybe the observation, all Mac browsers (well, all three layout engines) perform pretty much the same.
Conclusions:
trim9 for our Opera friendstrim12 is well suited for trimming big strings in all browsersYou can do the tests yourself on the testpage.
updated: The browser doesn’t hang now when you feed it an empty or all whitespace string
Most Operating Systems implement the concept of default buttons. One of the buttons on a form is visually recognizable as such. On Mac OS X, the button is painted deep blue. The reason why it is called default button, is when you press enter, this button is “virtually” pressed.
Why I am telling this? Not every body is familiar with this concept. But also, there are two other similar concepts. The cancel button is one of them. Normally it isn’t visually distinct, but it usually sports the text “cancel”. Also, this button has a shortcut. When you press the escape key, the cancel key is chosen.
But what me surprised on Mac OS X was what I call the pre-selected button, see the button with the blue outline on the screenshot. This key has the focus, and when you press the spacebar, this key is “pressed”. The brilliant part of this: they didn’t pick just a random button for this (the default or cancel button don’t have the focus). Somebody picked it carefully. So all three buttons are accessible by just one keystroke.
Normally, this behavior is not available. You need to change a setting in the system preferences. Open the System Preferences from the Apple menu. Choose Keyboard & Mouse, and then the Keyboard Shortcuts TAB. On this panel, select the “All controls” radio button (see this screenshot).
I just got this errormessage in Firebug's console. What the F? What’s wrong with this code?
var d=new Date(); console.info("offset: %s, utc hours: %s", d..getTimezoneOffset(), d.getUTCHours());
Oops. Notice the two dots before getTimezoneOffset.
That triggers an E4X error, which is apparently switched on in the Firebug console…