Google Open Source Blog

Agreed re: the quality of Frank McSherry's posts - they're all great fun and push the technical envelope!

I'm glad you brought up Hilbert ordering. It's fascinating but I rarely see it. I usually see Z-order curves in their place - simpler and more intuitive but also less effective. Does anyone know of large scale databases with Hilbert ordering out of the box?

For anyone who hasn't seen them before, or why they help in ordering, I highly recommend "Portrait of the Hilbert curve"[1] and "Spatial indexing with Quadtrees and Hilbert Curves"[2]. The tldr is that they enable efficient multi-dimensional indexing. Given a request like "X < 40 and Y > 80", most databases need to run "X < 40" and then filter over the results for "Y > 80" - Hilbert curves allow you to find the query's intersection and only then perform minor filtering.

As far as large scale use of Hilbert ordering, Google use it internally for much of their geographical work. They even open sourced a Java library specialised in multi-dimensional indexing based on Hilbert curves called Uzaygezen[3].

[1]: http://corte.si/%2Fposts/code/hilbert/portrait/index.html

[2]: http://blog.notdot.net/2009/11/Damn-Cool-Algorithms-Spatial-indexing-with-Quadtrees-and-Hilbert-Curves

[3]: http://google-opensource.blogspot.com/2008/08/uzaygezen-multi-dimensional-indexing.html

> also, since you're into JITs, you might enjoy his "a brief history of Just-in-time"

Indeed, I've bookmarked it, thanks! I couldn't find the other paper you mentioned about fiddling with compiler output; would be very interested in seeing that.

LuaJIT2 was the first interpreter and JIT that I ever studied deeply, so while I am very impressed by it, I don't have a great understanding of how it differs from previous work. How is its interpreter substantially different or more impressive than previous interpreters written in assembly language? Don't all assembly language interpreters need a fixed register allocation?

I've been a big fan of Mike's work for a long time and helped him get some Google funding: http://google-opensource.blogspot.com/2010/01/love-for-luajit.html

By the way, when I was searching for the John Aycock paper I came across your dissertation which I've also bookmarked. I see that you went to Trinity College Dublin -- I visited Dublin a few years ago and what a beautiful university that is! Looks like there's a lot of interesting JIT-related research coming from there lately.

Depending on what you want to do there are some options.

The one that's been around longest but the most limited is the ASE (Android Scripting Environment)
http://google-opensource.blogspot.com/2009/06/introducing-android-scripting.html

Using the ASE you can create some simple programs to do small tasks.

If you're looking to build a full app you're probably going to be looking at either working through Java, or if you're on Gingerbread you can use C++. Previous versions of Android allowed for C++ libraries being linked to your apps but had no way to access the APIs for creating graphical interfaces. That's now changed so I recommend you look into the SDK and NDK if you're really serious about building on Android.
http://developer.android.com/sdk/
http://developer.android.com/sdk/ndk/

The only other option that I know about is that the Mono framework is being ported to android (.NET framework port). So if you know C# or any other .NET language you may be able to start there, although I think it's currently in closed beta.
http://monodroid.net/

Google Code is shutting down this year[1], so the Vim-dev mailing list discussed migration[2]. GitHub is the most popular host for open source projects, and Google Code has an export tool for it[3], so the switch makes a lot of sense.

That said, Vim's development method is rather conservative. Vim was created in 1988, but source control wasn't used until 2004 and Bram is the only one with write access. There are no pull requests. You have to send patches to the mailing list, where they are often dropped or forgotten. Hopefully, GitHub's features will modernize things a little and make it easier for more people to contribute to Vim.

1. http://google-opensource.blogspot.com/2015/03/farewell-to-google-code.html

2. https://groups.google.com/d/msg/vim_dev/ehzfCDccmek/PU1sTZNdsTUJ

3. https://code.google.com/export-to-github/

You miss the point, your list is meaningful only in general compression cases, the Brotli thread (where we are) is all about boosting textual decompression while having/exploiting little resources (RAM mostly) as in the cases of Web Browsers.

As one (Jyrki) of co-authors commented:
```
For more clarity on the situation, you could compare LZMA, LZHAM and brotli at the same decoding memory use. Possibly values between 1-4 MB (window size 20-22) are the most relevant for the HTTP content encoding. Unlike in a compression benchmark, there are a lot of other things going on in a browser, and the allocated memory at decoding time is a critically scarce resource.
```
Source:
http://google-opensource.blogspot.bg/2015/09/introducing-brotli-new-compression.html

Thanks for the info! It seems Google see the need for it - great.

Announcement from Nov 2014: http://google-opensource.blogspot.com/2014/11/lovefield-powerful-javascript-sql-like_17.html

Video of a recent presentation: https://www.youtube.com/watch?v=wRiI4p5Uk4E

Lovefield actually uses WebSQL in certain cases: WebSQL backstore shall be considered a gap-stopping patch
18 and will be removed as soon as Apple fixes IndexedDB bugs in Safari. -- https://github.com/google/lovefield/blob/master/lib/backstore/web_sql.js

I wonder why the would remove WebSQL support? Isn't it faster to rely on a native C library in the case of Safari (WebSQL uses SQLite) than riding piggyback an SQL layer on top of IndexedDB on top of SQLite as it is the case in Firefox?