Press [this button]

void((function(A){var B=document.createElement("SCRIPT");B.type="text/javascript";B.src=A;document.body.appendChild(B)})("http://www.antimatter15.com/misc/pisect/pisect.js"));

Please note that this is a distributed effort and there is no simple way to get the final value as of yet.

I donno why, but i’m revisiting this. I was trawling across Wikipedia one day, and I got to the article about Pi. I tried distributing Pi a while ago, actually, before I did the hashes. But I never ended up implementing it because it didn’t seem feasable, as all the algorithims I encountered (or tried porting) required lots of memory, something very hard to distribute for this scenario. But this time, I found these. Looking through them, and googling in the process, I found http://www.omegacoder.com/?p=91, and ported it over to Javascript. It was relatively slow compared to the SuperPi implementation in Javascript, but it was easily distributed.

One problem though, is that it gets slower every iteration (to find the net block of digits). Finding .141592653 will be roughly 20ms faster than the next 9 digits (it processes in blocks of 9). Not only would it take longer, but it occupied 100% of the CPU, and it would pop up that ever-annoying “This script may make your computer non responsive” window. So I implemented this pattern to make it not lock up any browser other than Chrome (and possibly WebKit Nightly).

Still, it would take up 100% of the CPU. I ran it overnight and got to digit 17,000.

Eventually, it would take about half an hour for a single iteration (at the 20000th digit). With web-based distributed computing, I can’t rely much more time than what Google Analytics reports to be 00:02:24 (my Average Time on Site). And that’s half an hour with a 3ghz Intel Core 2 Duo (it’s dual core, but the script, is single threaded).

I then split the function into smaller parts. the main function was split up, and the loops were divided across users. Now, it can scale easily. It uses virtually no visible CPU. and fits well into that 2 minute timeframe.

Try it out here, but don’t stay too long, because i only set there to be 500 “jobs”.

who’s the lucky spammer to post the 4000th spam?

2.0 isn’t an actual version number, but i’ve added the new one.

it’s basically

Parent ID (or _body) > Element tag name : Parent Index > format type = patch/innerhtml data

or

_body>div:0>span:1>d=hello!

the formats are p, d, and o, or Patch, HTML, and Legacy, respectively. Patch uses diff-match-patch, unidiff style data. Patch is the same, and Legacy is an intermediate format of sorts, which is easily converted to from the old formats, but still follows the general pattern of location>type=data. The only difference between Legacy and HTML is that legacy uses a different location scheme.

The pluses of this new system, is that it’s more accurate, and your edits are more resistant to page changes. The data is more human readable, the system is more reliable, and stores less data on the server. The cons, are that there is a 20kb overhead in wikify core, and saving may take some more time.

Well, I was trying to iron out a IE bug for project wikify. Interestingly, that bug I encountered, crashes every IE since 5.5 (not sure if it crashes 5.0 yet, browsershots are still loading)

http://wikify.googlecode.com/svn/trunk/v2/crashie.htm

really, this just is just another IE issue….

So i built a pretty crappy tree-diff system for Wikify. It completely ignores the creation of new nodes, or the deletion of the nodes, but it works most of the time. It’s tree based, so the data is fine-grained to the level of however small the nodes are made to be. But many pages with huge paragraphs or such, have huge nodes, and editing a single word would mean saving a huge amount of data.

So Wikify will now use both the tree-based diff (which is great for HTML/XML docs, as they are trees) and divide the changes into text and do text diff for that. Right now, the only thing sutable is the google-diff-match-patch project, which is absolutely amazing, except for how huge it is. But I figure its okay, because I’m already including the (relative) bloatness of jQuery… (especially compared to vX)

I just got accepted into beta for it, and it’s insanely great! There are some disconnect issues, but the latency is awesome, etc. If only syntax hightlighting was better.

And yes, i’m killing their servers by contributing to their viral growth :P

as a sidenote, i’m actually hyperlinking my links! (freaky, I know), and my posts are getting less and less mature over the months/years

So the issue with Adobe AIR, is that there’s no SVG support, but I have a hunch that this might support SVG, as it’s not Adobe’s fork of Webkit, but hopefully the real one :)

It has tons of awesome components like WebKit, Chromium (hope it doesn’t have that rotate bug…), Gears, GTK+, jQuery, Appcelerator SDK, NSIS, Ruby.

But this will hopefully satisfy those wishes for a Desktop version.

updating! it looks insanely great.

I’m posting this from the entire awesomeness which is Wordpress 2.7!

Okay, so 0 = false, so it makes sense that !0 = true. but also 1 = true, so that saved 1 byte.

Since there’s no .readyState attribute > 4, instead of .readyState == 4, you can do .readyState>3

the big one was ActiveX, which was originally

x=new(this.ActiveXObject?ActiveXObject:XMLHttpRequest)('Microsoft.XMLHTTP')

I noticed how this.activeXObject was repeated unnecessarily. So i added a new variable y

y=this.ActiveXObject

then I did:

y=this.ActiveXObject;x=new(y?y:XMLHttpRequest)('Microsoft.XMLHTTP')

thanks to dynamic languages, I could use x, and just reset it to something else (saving a variable declaration!)

x=this.ActiveXObject;x=new(x?x:XMLHttpRequest)('Microsoft.XMLHTTP')

Now I just need to find a way to shrink

x.setRequestHeader('Content-type','application/x-www-form-urlencoded')

I updated Wikify with the new Toolbar UI.

http://wikify.antimatter15.com/