From e1da3b144b0ddc1a5df0466767fbc2479c4c9d86 Mon Sep 17 00:00:00 2001
From: "psyc://psyced.org/~lynX" <@>
Date: Tue, 16 Jun 2009 20:07:03 +0200
Subject: [PATCH] float would only last for one more year.. we have to use
 strings for bignum action

---
 world/net/library/jsonparser.pike | 16 +++++++++++++---
 world/net/twitter/polly.c         | 24 ++++++++++++++----------
 2 files changed, 27 insertions(+), 13 deletions(-)

diff --git a/world/net/library/jsonparser.pike b/world/net/library/jsonparser.pike
index 76eb024..cc2a9bb 100644
--- a/world/net/library/jsonparser.pike
+++ b/world/net/library/jsonparser.pike
@@ -527,9 +527,7 @@ PROTECTED mixed nextObject() {
 	if ((b >= '0' && b <= '9') || b == '.' || b == '-' || b == '+') {
 	   int a; float b_; string c_;
 	    sscanf(s, "%d%s", a, c_);
-			// some values of json ints exceed the limits of MAX_INT, in that case we need to use float	-lynX
-			// maybe it is more efficient, if we used float in all cases then
-	   if ((c_ && sizeof(c_)) || (a && s != to_string(a))) {
+	   if ((c_ && sizeof(c_))) {
 #ifdef __PIKE__
 	     sscanf(s, "%f", b_);
 #else
@@ -537,6 +535,18 @@ PROTECTED mixed nextObject() {
 #endif
 	     return b_;
 	   }
+	   if (!a || s != to_string(a)) {
+		// some values of json ints exceed the limits of MAX_INT.
+		// in that case we tried to use float, but rendering floats
+		// will produce something like 2.17734e+09 instead of just
+		// a long integer. we have to return a string here, and risk
+		// to run into runtime errors. we should probably stop trying
+		// to convert json integers into ints in the first place.
+		// javascript and lpc just aren't compatible. do we have a
+		// bignum package for ldmud?
+		P3(("Warning: JSON integer too big. Returning %O as string.\n", s))
+		return s;
+	   }
 	   else return a;
 	}
 	if (s == "") {
diff --git a/world/net/twitter/polly.c b/world/net/twitter/polly.c
index f47400d..b34dbf9 100644
--- a/world/net/twitter/polly.c
+++ b/world/net/twitter/polly.c
@@ -5,7 +5,7 @@
 
 #include <net.h>
 
-persistent float lastid;
+persistent mixed lastid;
 
 volatile object feed;
 
@@ -37,15 +37,20 @@ parse(string body, mapping headers) {
 		    "[_source] received an empty structure.");
 		return;
 	}
-	// this used to fail on MAX_INT turning the ints to negative.. interestingly
-	// it works out of the box now that i convert this to float. funny to run into
-	// such a weird problem only after months of usage, but if twitter never resets
-	// its packet ids, that's where you end up.. bignums!
-	if (wurst[0]["id"] <= lastid) {
-		P1(("%O received %d old updates (id0 %O <= lastid %O).\n", ME, sizeof(wurst), wurst[0]["id"], lastid))
+	// this used to fail on MAX_INT turning the ints to negative.. it would work for
+	// a while longer using floats, but since floating point mantissa in lpc is only
+	// 32 bits wide, it's just a question of time until we hit that roof again (when
+	// status_id reaches 4294967296). so let's try strings instead. funny to run into
+	// such a weird problem only after years that twitter has been in existence.
+	// twitterific may have run into the same problem, as the timing of its breakdown
+	// matches ours.
+	if (lastid && wurst[0]["id"] <= lastid) {
+		P1(("%O received %d old updates (id0 %O <= lastid %O).\n",
+		    ME, sizeof(wurst), wurst[0]["id"], lastid))
 		return;
 	}
 	lastid = wurst[0]["id"];
+	P1(("%O -- new lastid %O\n", ME, lastid))
 	save_object(DATA_PATH "twitter");
 	for (i=sizeof(wurst)-1; i>=0; i--) {
 		d = wurst[i];
@@ -110,9 +115,8 @@ fetch() {
 	feed -> content( #'parse, 1, 1 );
 	// twitter ignores since_id if count is present. stupid.
 	feed -> fetch("http://twitter.com/statuses/friends_timeline.json?"
-	     // +( lastid? ("since_id="+ lastid) : "count=23"));
-	      "count="+( lastid? ("23&since_id="+
-				  sprintf("%F", lastid)) : "23"));
+		 // +( lastid? ("since_id="+ lastid) : "count=23"));
+		  "count="+( lastid? ("23&since_id="+ lastid) : "23"));
 }
 
 create() {