| look before you leap |
[Nov. 12th, 2009|11:45 pm] |
I started to investigate yesterday's idea of a shell implementation in Perl, and immediately got mired in the Byzantine shell quoting rules. The most basic thing about the shell turns out to be unnecessarily hard, and besides, it's already been done. Why did I think this was a good idea again?
Somehow I had got it into my head that msysgit on Windows would only run from the msysgit shell. Since I don't actually use Git on Windows, it turns out I was mistaken. If you run any Git command from the regular Windows command prompt, it already works. The appropriate shell is invoked to execute the shell script (git-rebase is one such shell script, instead of being part of the native C implementation).
Nothing to see here, move along... |
|
|
| git on windows |
[Nov. 12th, 2009|07:59 am] |
Git is mostly written in C, with some important parts in shell and Perl. This works well on Unix-like platforms, but unfortunately suffers on Windows because there is no native Windows (Bourne) shell. Git can be built under the Cygwin environment, but that is a heavyweight solution and Cygwin is not appropriate for general use. msysgit builds a native Windows executable plus uses the msys shell implementation, which provides a workable solution, but still requires Git operations to be done within the msys shell and not the native Windows command shell.
I had a thought the other day, that one could implement a Bourne shell interpreter in a more widely available language such as Python. This would provide a more widely portable option for using Git, and on Windows in particular. Such a shell implementation would provide the minimum implementation necessary to run Git's shell scripts (and which would include minimal implementations of various utitilies such as grep, sed, and awk). That wouldn't solve the Perl script problem, so it seems obvious that a portable shell interpreter designed for use with Git should be written in Perl.
A long time ago there was the Perl Power Tools project, which aimed to provide implementations of various Unix utilities in native Perl. Unfortunately, nobody ever submitted an implementation for sh. Is there any existing implementation of a Bourne-like shell in Perl? More generally, is this a viable plan to make Git work better on Windows?
Update: See the next post to find out just how far I got with this. |
|
|
| Almost |
[Nov. 9th, 2009|10:34 am] |
As happens pretty often, a photo ends up being liked but not loved. I'll go out and try to shoot this shot again and get more in focus while keeping the colors and composition I like. I like it enough to post, but only this once and never on alderflats.com.
 |
|
|
| lnk.nu and google app engine |
[Nov. 7th, 2009|09:38 pm] |
Last week, I was quietly working on my web server when all of a sudden the whole thing ground to a near-halt. It wasn't completely dead, because it would still ping and every few minutes I would receive another packet of characters (I was literally in the middle of refreshing a screen I was looking at). Not knowing what was happening and not having any way to find out, I went and did something else for a while.
45 minutes later, my server returned to normal operation as if nothing had happened. This did not appear to be just a network congestion problem, it was definitely something my server was busy doing. A bit of investigation showed that the culprit was in fact lnk.nu. Hundreds of machines all across Canada had all accessed the same short link at the same time, and completely pegged the PostgreSQL database processes, and also run my server out of memory. It's quite a testament to both FreeBSD and PostgreSQL that they survived at all.
What I believe happened was that somebody had sent an email containing a lnk.nu link to a mailing list to which lots of people from Canada were subscribed. (The link in question happened to be a job opening at who.int.) Looking up the reverse PTR records for the machines that loaded the URL, there are names like "mail", "barracuda", "filtre", "antispam", "mx1", "incoming-smtp", "guardian", etc. It seems that they all accessed the link for purposes of virus checking, all at pretty much exactly the same time. This was not good for my poor server.
I decided that it might be time to move lnk.nu to a different server. It's written in Python, so it's an ideal candidate for Google App Engine, and I've been looking for an excuse to play with GAE. So I downloaded the SDK, converted the code over to GAE (using Google's datastore instead of SQL), and made it work locally. This part was refreshingly easy and worked well.
The next step is to set up the Google site so it responds to http://lnk.nu and handles the requests appropriately. Given that I've already got the code working locally, that should be straightforward. However, there is one gigantic caveat when using Google web site services (that I've actually already run into for another project): You cannot have Google's servers respond to a "naked" domain name that doesn't have a hostname. This means that having Google respond to http://lnk.nu is not possible.
(There is in fact a good technical reason for the above restriction. When you set up a site with Google hosting, you add a CNAME record to the DNS for your hostname, ie. "www.example.com. CNAME ghs.google.com.". This lets Google completely manage the association between "ghs.google.com" and any particular IP address(es), which is critical for their load balancing setup. The caveat is that a record with a CNAME must not have any other DNS records associated with it, including an SOA record. The SOA record is required on a "naked" domain name like lnk.nu, so you can't add a CNAME there.)
To work around this, I'll have to set up a hostname that Google can respond to, something like http://a.lnk.nu. Of course, that's a pretty lame name for a link shortener to use, so I'll still want the published link to be http://lnk.nu/blahblah. This means that I'll have to have some other, non-Google server respond to a http://lnk.nu/blahblah request with a redirect to http://a.lnk.nu/blahblah. This adds another level of indirection to the resolution process for a shortened link, which adds another browser round-trip, which might slow the whole experience down no matter how fast GAE hosting ends up being.
It turns out that Namecheap (my registrar for lnk.nu) offers "URL redirection" where their server will respond to a particular hostname and redirect the browser somewhere else. It can also be configured to retain URL path information, so http://lnk.nu/blahblah would redirect to http://a.lnk.nu/blahblah. This would completely take my own server out of the loop, hopefully avoiding any more problems like those last week. |
|
|
| earthquake widget update |
[Nov. 6th, 2009|12:20 am] |
Over the last couple of days, a few people have emailed me about my Earthquakes Widget which displays the most recent earthquakes on a small world map on your desktop (it's a Yahoo! Widget). It seems that it had stopped displaying earthquakes due to an error loading the data file from the earthquake.usgs.gov server.
It turns out that it was due to an URL change on the usgs.gov server, and the widget framework's XMLHttpRequest object doesn't seem to automatically follow the redirect. So I changed the link and it all seems to work again. I sent a new widget to the people who had emailed me to make sure that it solves their problem, and if it's all okay then I'll submit it to Yahoo! again (they approve widgets manually, so it pays to make sure it's right before submitting).
If you're looking for the latest version (1.5) before it gets submitted to Yahoo!, see the Earthquakes Widget page which has a direct download link.
I've uploaded the quake-widget repository to GitHub. |
|
|
| navigation |
| [ |
viewing |
| |
most recent entries |
] |
| |
|
|
![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small}
mduell's Friends Page