Talk:Implementations
Contents
Shell script broken?
Is it just me, or is the shell script implementation broken? --Psud 08:21, 26 May 2008 (UTC)
- Actually, please refer to my comments on the main page discussion. --Psud 12:41, 26 May 2008 (UTC)
- I've rewritten the script to incorporate some earlier suggestions I made (they were left on the main page's talk page when the implementations were moved) about portability (you seem to have been bitten by the slicing issue I was worried about). However, you will need to have dc installed no matter what.
- Perhaps all the implementation discussion in Talk:Main_Page and its archives should be moved here? I don't even have an account, so I'll leave it to someone who knows what they're doing. --Decklin
Shell script implementation
While it runs on sh, ksh, and bash now, it still doesn't work on OpenBSD. If GNU date (which has the -d option) is not detected, I assume FreeBSD's -v is available; OpenBSD doesn't appear to have a comparable feature. Could someone test on OS X? No idea what's there (pretty sure they ship with wget, though).
Super brownie points if you can make it fallback to wget *or* fetch in one line so I can delete that stupid usage warning and have it run on FreeBSD out of the box. --Decklin
Could the user at 63.201.144.114 explain what broke? No math is being done in the shell in any case, and nothing added requires the script to be run under GNU bash instead of any POSIX sh. Extra features are nice, if they can only be implemented in the script itself, but that's an entirely separate issue.
iPhone Implementation
Last night I finished a rough implementation of this to the iPhone 2.0 Beta SDK. Right now it uses your current location and date and then does the math, then gives you a map with the destination address along with directions to there from where you are at. This will be even more useful if the next 3G iPhone come with GPS, until then it uses it's less accurate cellular and wifi location tools to locate you. I plan on adding a way to select your date and your desired graticule as well. Eventually I'll also investigate filtering of the results in watery areas. I can't distribute it currently, but as soon as I can I'll make it available. -- Shakedown
Atom feed 30W-compliance
I just added the atom feed and it seems to be 30W-compliant
- After some thought, I suppose it would be somewhat compliant. However, in some cases it's too compliant, or compliant in the wrong ways. After 00:00 local time, it automatically switches to the next day, but keeps the old Dow value and rehashes. East of 30W that behavior is desired, since you want to use the previous day's Dow anyway. West of 30W, however, it means we get an "intermediate" hash that's invalid for us. This much has always been a problem with the implementation. Then, sometime after 09:30 ET (I don't know precisely when), it detects the new Dow value and updates the hash... but it does it both west of 30W where it is needed, and east of 30W where it is undesired. In that case, you would get some other "intermediate" using the current Dow with the current day, which isn't what you want. That's a new problem the 30W Rule created.
- In summary, it seems to produce invalid hashes between 00:00 (local) and ~09:30 EDT (UTC-4) west of 30W, and between ~09:30 EDT (UTC-4) and 24:00 (local) east of 30W. That is, it's invalid from 00:00-~06:30 in US Pacific Daylight Time (UTC-7), from ~14:30-24:00 British Summer Time (UTC+1) or from ~21:30-24:00 Australia Western Standard Time (UTC+8). I'm not even sure I know what would happen with the feed in New Zealand, where 09:30 USEDT = 01:30 NZST the next day. It'll be even worse come late October/early November, when Australia/NZ switch into DSTand the US switch out... the gap will become 2 hours wider over a couple weeks' time. And of course, these problems are mitigated over weekends, when you have several identical Dow values in a row. Someone should check this out before the weekend, as I'll be busy until Friday 17:00 UTC. If anyone does, and has thoughts, hit me up on my talk page.
- Sincerely, your friendly
local(global?) 30W-compliance "expert"... --Tim P 15:34, 29 May 2008 (UTC)
Mapping tool appears borken (5/25/2008)
My test case:
- Go to Mapping tool.
- Zoom out a few, to see the US West coast.
- Center-up on Santa Cruz (if you don't know where that is, use San Francisco.)
- Zoom in a few, to get a nice view.
- Press UPDATE button. (Btw, I'm on Safari, on Mac OS-X/Leopard-latest.)
EXPECTED: A map-pin and coordinates that you can review. ACTUAL: Pin & coordinates flash for a brief moment, then map recenters on Boston, with information gone.
NOTE: Things all worked fine yesterday and the day before (5/23-24.)
Aside: Is there a "bug reporting system", or is this it? :)
Thanks! Ted 18:55, 25 May 2008 (UTC)
- I can't seem to reproduce this in FF or Safari on OSX 10.4.11. Does safari have a javascript error console where it might be logging the error? Zigdon 19:10, 25 May 2008 (UTC)
- As far as bug reporting, this is one way, a better was is to come into IRC and talk to me there. Go to http://mibbit.com, select "foonetic" from the pulldown server, and #geohashing for the channel. Zigdon 19:10, 25 May 2008 (UTC)
Is it just me, or is the shell script borked?
Shell script bombs out for me in two places :(
This:
[[ "$DOW" != +([0-9.]) ]]
Was always returning true, so exiting the script with a "DOW not available yet.". I replaced that with
[[ -z "$DOW" ]]
to get past it.
then it falls over elsewhere with:
./geo.sh:1: unrecognized modifier `0' ./geo.sh:1: unrecognized modifier `1' ,
For reference, the script reads:
#!/bin/zsh
DOW=$(wget -qO- http://irc.peeron.com/xkcd/map/data/$(date +%Y/%m/%d))
[[ "$DOW" != +([0-9.]) ]] && echo "DOW not available yet." && exit 1
MD5=$(echo -n "$(date -dW30 +%Y-%m-%d)-$DOW"|md5sum|cut -d' ' -f 1|tr a-f A-F)
echo "$1$(echo 10k16i0.${MD5:0:16}p|dc), $2$(echo 10k16i0.${MD5:16}p|dc)"
does it work for other people?
And by the way, is the date modifying in the right place? Shouldn't it retrieve yesterday's dow and caculate with today's date in 30W cases - rather than retrieving today's dow and using yesterday's date for the hash?
I've so far worked out that it's failing on the line:
echo "$1$(echo 10k16i0.${MD5:0:16}p|dc), $2$(echo 10k16i0.${MD5:16}p|dc)"
Better yet, I've further narrowed it further. The parts my system doesn't like are:
echo "$1$(echo 10k16i0.${MD5:0:16}p|dc), $2$(echo 10k16i0.${MD5:16}p|dc)"
^ ^^ ^^ ^^ ^^
It doesn't understand the numbers and it reports "command not found" for "dc"
--Psud 08:49, 26 May 2008 (UTC)
The Perl reference implementation
I've been playing with the Perl reference implementation, and as I'm in Australia, I found it annoying to deal with its poor 30W capability. So I "fixed" it. Perhaps.
- <snip> I updated the sample.pl to have a '-e' flag. If you run it with it, it will report the values according to the 30W rule:
$ ./sample.pl 2/1/08 Downloading DJIA from google: http://finance.google.com/finance/historical?cid=983582&startdate=Jan+25,+2008&enddate=Feb+01,+2008 DJIA opening for 2008-02-01 is 12638.17 Date: 2008-02-01, DJIA: 12638.17 MD5(2008-02-01-12638.17): 917a4419e1345e42569bad9fa5ef5a17 Split: 917a4419e1345e42, 569bad9fa5ef5a17 Fractions: 0.5682718814070582, 0.3383129610792229
$ ./sample.pl -e 2/1/08 Adjusting for 30W Downloading DJIA from google: http://finance.google.com/finance/historical?cid=983582&startdate=Jan+24,+2008&enddate=Jan+31,+2008 DJIA opening for 2008-01-31 is 12438.28 Date: 2008-02-01, DJIA: 12438.28 MD5(2008-02-01-12438.28): ec6464f6d4d0da51c0c8fe874be8601c Split: ec6464f6d4d0da51, c0c8fe874be8601c Fractions: 0.9234068968406207, 0.7530669288934475
Zigdon 21:36, 26 May 2008 (UTC)
- Thanks --Psud 10:58, 27 May 2008 (UTC)
