Unfortunately not. This algorithm is so closely tied to the architectural constraints of the memorial that it probably won't be useful out of context.

Hi - the source code is here:

http://blog.blprnt.com/blog/blprnt/text-comparison-tool-source-code

Hi David,

First, I apologize for any offense that you took from my 'your browser sucks' line (which has been changed), or my terse reply. I certainly didn't mean to be hateful or bullying.

As for WebGL, you are right, it is a choice. However, this tutorial uses Processing.js, which uses WebGL to render 3D content, so in order to see it you'll need to have a WebGL enabled browser. If you don't want to download one, then you won't see the finished content.

I'm not on the Processing.js team, so I can't really speak for them - but I for one am very excited about the prospect of hardware-accelerated graphics in the browser. I'm not a GL expert, so I can't speak about the WebGL security concerns - maybe someone from the Processing.js team will be able to give some insight.

-Jer

Hi,

The graphic at the top requires WebGL, which may not be supported by your video hardware.

Can you view this:
http://www.chromeexperiments.com/detail/webgl-wat...

?

-J

Nice catch - copy paste bug from the IDE. Fixed.

Dave,

Chrome doesn't allow you to load local Javascript content. It's a security thing. Strange, but as far as I can see, there's nothing that can be done about it. If you load the files to a web server, you'll see everything running beautifully.

The upcoming Processing 2.0 release actually loads web content in a little local web server to get around this issue.

-J

Roger,

Thanks for your reply. I am a fan of your work with Hyperstudio (I'm not sure if you've read my previous posts about Hypercard), and I appreciate your taking the time to comment.

Actually, I appreciate and respect all of the comments that I receive. Dave's initial one caught me off guard because I honestly didn't think (and still don't think) that my language was anywhere near hateful or bullying. It seemed like a gross overreaction. I'll admit that my own reply was terse, but I take an accusation of bullying quite personally, having been a victim of severe bullying in my school years.

I've been teaching programming to 'newbies' since 1993. While I don't have the depth of experience that you have, I'm sure that we share a similar dedication to learning and belief in the transformative power of programming.

I've apologized to Dave for any offense he may have taken and have changed the initial line of the tutorial. Which, for posterity's sake, read:

[The above graphic is an interactive 3D bar graph. If you can't see it, it's probably because your browser sucks. Maybe try Chrome or Firefox?]

-J

Dave,

Bullying? Hateful? Really?

If you are so attached to your choice of web browser that a tongue-in-cheek comment about its inadequacies feels like a 'smack in the face', I think you need to start taking software a little less seriously.

I suppose I could have written the line like this:

[The above graphic is an interactive 3D bar graph. If you can't see it, it's probably because your browser doesn't have the ability to render WebGL content. Maybe try Chrome or Firefox?]

But frankly, if I'm going to put hours of my own time into writing a tutorial (one of dozens that I've written on this site), I think I'm allowed to indulge in a 'snarky laugh line' or two.

** edit - in order to keep everyone happy and to keep the focus on the red hot learning action, I've redacted the original caption.

-Jer

1. We don't claim that the April announcement was the first time this has was discovered or reported. Only that in April researchers announced that they had discovered this cache. Which is true. 99% of people who are aware of this issue are aware of it because of that announcement.

2. The local cache that we are using with openpaths is not being sent to Apple. However, location data from your phone is undoubtedly being sent to Apple on a semi-regular basis (at the very least to request this 'subset' of geolocated wifi hotspots that Apple says makes up the cached data). It may very well be that Apple is not storing or using this data, in which case I'd be pleased and surprised. Regardless, the issue is that these stored location files contain information that may be useful to both researchers and owners of these devices. The intent of openpaths is to make this kind of access easier.

Thanks for your comment.

-Jer

1. We don't claim that the April announcement was the first time this has was discovered or reported. Only that in April researchers announced that they had discovered this cache. Which is true. 99% of people who are aware of this issue are aware of it because of that announcement.

2. The local cache that we are using with openpaths is not being sent to Apple. However, location data from your phone is undoubtedly being sent to Apple on a semi-regular basis (at the very least to request this 'subset' of geolocated wifi hotspots that Apple says makes up the cached data). It may very well be that Apple is not storing or using this data, in which case I'd be pleased and surprised. Regardless, the issue is that these stored location files contain information that may be useful to both researchers and owners of these devices. The intent of openpaths is to make this kind of access easier.

Thanks for your comment.

-Jer