Talk:Implementations

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 version bugs

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

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 DST and 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)