matthiaskramm

I... might have to try that. :)

Looks like Pi is still ahead, in the Tau vs. Pi arms race.

Also, feel free to contact us at botrace@scribd.com if you see any more issues.

Uploading bot revisions is broken right now- you can try to upload a new bot, or wait for our fix which should go live in a couple of hours. :)

Log into www.scribd.com, that'll make viewing of the bot pages work. We'll deploy a fix for that later today.

Fixed.

10 seconds as well.

Thanks! We'll fix the API docs.

About the bug: Try to trace() out a few messages in your make_move() function, that might tell you whether something went wrong (the logs will appear at the bottom of the game replays.)

Yeah, we're seeing the first problems with that right now- newly uploaded bots progress faster than they should because they play against a more "diluted" pool of opponents than the oldtimers did. We'll think of something.

Yep! Width and height are between 5 and 15, and there are up to five different types of fruits on the grid.

Fixed, thanks :) We'll deploy a new page tomorrow.

Try creating a new account on www.scribd.com before you go to www.scribd.com/jobs/botrace_upload_bot

It's using SpiderMonkey right now. Using nacl as sandbox is a neat idea though.

Aw, that sucks. We're still fixing glitches in the system, but uploading actually should work.

What kind of error are you seeing?

We're planning to keep this running indefinitely.

We may also add additional languages in the future, like Haskell and Lua, and possibly some advanced playing modes.

We do plan to add some additional languages. Next on our list are: Haskell, Lua, Python.

You can get half a fruit if you and your opponent pick it up at the exact same time.

Fixed, thanks!

Your bot is doing pretty well already. :)

Btw. here's a game, played between our two best bots so far:

http://www.scribd.com/job_game/match/263907

I'll try! I'm a big fan of open source, and I actually have a long list of components I want to open-source at some point, like for example Scribd's PDF to html5 conversion software.

Oh, it's about SOPA, trust me. I felt defenseless when the DMCA (and the "European DMCA", 2004/48/EC) were introduced (I went to a couple of demonstrations, but that only goes so far), and SOPA is even worse. It's nice to work at a place where you can have more of an impact, and take a stance that has an actual chance of being heard.

Browsers are "smart"- they won't let you select text that's 100% transparent. 99% transparency works... but also looks kind of weird if the texts don't overlap perfectly.

You can roll your own text selection in javascript (on top of the bitmap) if you know the glyph positions though- that's what e.g. Google Books does. It's a valid option if you don't care about zoomability.

> but it describes a problem that hasn't been considered 'interesting' for decades

Actually, polygon operations on grids is still an active research area, with the latest papers on the topic less than two weeks old: http://www.sci.utah.edu/socg2010agenda.html

> Why would they need to run the same intersection logic over and over [...]?

We usually don't. It basically depends on the context in which the glyphs appear on the page. For a standard, say, LaTeX document consisting of mostly text and without weird graphic operations taking place around or on top of the text, a given glyph is just processed once.

Absolutely. Modern graphics card hardware can easily process a few hundred million triangles per second. In all fairness, however, that has nothing to do with polygon intersection. Drawing a triangle on the screen with a z-buffer check is something quite different from actually computing an intersection polygon from two (multiply connected) input polygons.

Performance issues, among others. IE's DXImageTransform, as the name suggests, renders an html element to an image and then transforms that entire image.

Well. We're talking about making this work in quite a number of different browsers, including IE6. So yes, it is.

Understandable concern. For now let's just say that we have a blog post in the queue (part 3/3 of the HTML5 series) that describes exactly how (and to which degree) we store and (re-)distribute fonts.

We're looking into releasing as much of our HTML5 conversion as possible as open source. For starters, basic technical details on how our conversion works will appear on our tech blog http://coding.scribd.com in the next few days.

We totally love your j/k keybinding idea. Consider it implemented. Maybe we'll additionally do s/w, a binding that comes more naturally to people unfamiliar with VI, but familiar with computer games :)

does fullscreen help? what's your screen resolution?