Oh the memories of that machine. UIdaho used one as a file server for the rest of the labs (home dirs were //snake/home/$user iirc, with snake = dn10k) and it was also available for use as a speedy workstation. Spaceball + 40bpp graphics made for some fun early forays into graphics programming.

Was also where I happened to hit ctrl-enter after the admin had neglected to flip it back into normal mode. During the middle of a class day. Chaos.

for me "Javascript" + "Window manager" will always mean pyro (http://web.archive.org/web/20100626182331/http://pyrodesktop...). so much wasted potential there :(

except remote contents can change

Store a hash or checksum in the index and also allow the remote API to return the hash/checksum to see if the file has changed

that's exactly how I did it when working on scsharp (https://github.com/toshok/scsharp). you gave it the paths to directories holding assets for starcraft + broodwars. 10 years on github without a dmca knocks on wood

The use of "self-hosting" was addressed in post. I think its use is actually right on the mark, but will grant you that it's slightly different than its use in the context of a static compiler written in the target language.

It basically means "able to host its own development". This means something different in different contexts, e.g. JS JITs "self-host" when some part of their builtin code is written in JS. We share that property with JS JITs, but in this particular case it means we can host our own build/test infrastructure. So we're using pyston to develop pyston. ergo, "self-hosting (qualified)."

---

We're definitely slower than pypy at present - we're only a small fraction faster than cpython after all on our benchmarks, and pypy is scary fast :)

I think we're still in the part of our work where the answer to the "big win with this approach" question is "we don't know." We're confident that we can/will be much faster than we are now, but we have different constraints than pypy, so it will always be something of an apples/oranges comparison.

I see. I think it's a huge stretch :) That's like Go claiming they are self-hosting because some of their tools are written in Go.

On a related note, I have to say that I still don't understand the point of this project. Were you guys unhappy with pypy's performance or development?

I understand that in theory, the approach you guys are taking is incompatible with pypy's, but I can't help but wonder how thing would play out if you Dropbox put their weight behind PyPy. Maybe it could've been the start of every Python programmer's wet dream: Python 2.8.

You really could have just said "dream."

I think "wet dream" captures it better.

That's the first time I've seen someone use self-hosting in that manner, or in the manner you describe in your examples.

To me it was totally misleading.

GitHub doesn't :( I filed one for the craftbukkit takedown a while back, and got a polite response saying it has to be the content owner.

oh god, the 38. a bike would have been helpful, though I can definitely relate to commute angst.

um, interpreters aren't prohibited.

They are prohibited by Apple to be even built with iOS SDK, if they interpret the code downloaded from the Web, which is naturally the case with browsers and JavaScript.

coffeekit!

monotouch apps were never compiled to c/C++/ObjC. they go straight to native code.

or LLVM