Entries from May 2009 ↓

It is amazing how much information can be displayed on even the smallest map, yet we sometimes forget that geographic content is not always available visually.

If you’re out and about, you can call GOOG-411 and get local information about businesses. Now we’ve made it even easier to orient yourself without a map in front of you: call GOOG-411, ask for ‘details’, and in addition to the address and phone number of the business, we’ll also point you to the nearest street intersection or adjacent streets.

You can try it now: call 1-800-466-4411, look up ‘Google in New York’, ask us for more ‘details’, and we’ll tell you that our Chelsea office is ‘near the intersection with West 16th Street’. Unless you’re a seasoned New Yorker, this might very well save you from walking up or down a few blocks.

The nearby intersections are available for most businesses in the US and Canada. They are derived automatically by an algorithm written on 20% time by Googlers in New York and London. Tell us other ways you would want to use this new feature — we hope to expand it to other products soon!

Posted by Vincent Vanhoucke, Research Scientist and Arnaud Sahuguet, Geo Product Manager

Posted by: Nicholas Weininger, Software Engineer

Custom Search enables anyone to create a tuned search experience that’s contextually relevant. For example:

• Individuals can create a personalized search experience around their bookmarks, blogs, and public web sites
• Web site owners can provide Site Search
• Publishers can provide search across multiple publications
• Communities can collaborate to create topical search engines across thousands of web pages

For bloggers, blogging platforms typically provide in-built search tools that allow searching across published blog posts, or across tags and categories. With Custom Search, you can go one step further: you can define a search experience that evolves over time, and includes not just your blog posts, but links extracted from those posts, as well as links from your blog’s link lists and blog lists – in short, all items of interest related to your blog.

If you author a blog on Blogger, we’ve built a search gadget for you that does this – the AJAX Custom Search gadget creates a Linked Custom Search engine that automatically updates to allow your readers to search your blog’s entire neighbo(u)rhood. It is a uniquely flavo(u)red search experience that gets richer over time. Search results appear inline, so your users don’t have to leave your blog. The results inherit the look and feel of the blog, as shown in the screenshot below.

On Blogger, you can add the gadget with a couple of clicks:

1. Edit your blog’s layout (Page Elements tab)
2. Click on “Add a Gadget” and configure the new “Search Box” gadget.

You can configure tabs that will allow your blog’s readers to restrict their search to specific link lists or blog lists; you decide which ones you want to configure.

If you are using this gadget, we’d love to hear your feedback in our discussion group.

The AJAX Search and the Custom Search APIs have also been combined to create the Custom Search element that we recently announced at Google I/O.

I spent my youth writing games on a computer hooked up to my parents’ television but despite saving my pennies to buy a 300-baud modem, I was never able to realize my dream of writing a game that my best friend and I could play against each other on two computers. In all my games the I,J,K and M keys were used by player 1 while player 2 was stuck with W,A,S and Z on the same keyboard.

This was in the back of my mind when I started putting my 20% time towards building a simple javascript library on top of our Google Talk web client. After some demos, my 20% project grew to an 80% project, and we’re now ready to show off — and get feedback on — the gadgets.realtime set of APIs. These APIs will let Google gadgets hosted in different user’s browsers communicate with each other. The first API, gadgets.sharedstate, is available on the new Talk Developer Sandbox. With this API, you can share an object between instances of a gadget, and be notified in realtime when the other instance modifies it. More APIs and UI improvements to allow gadgets.realtime gadgets to be used on orkut and iGoogle are in the works and coming soon.

For more information and for sample applications, see the documentation.

We’ve set up a discussion group to collect feedback. So, help me out, fellow geeks! Try out this API and let me know what you think and share any cool gadgets you write.

Moishe Lettvin, Software Engineer

The Reader team is happy to announce that another 20% project has come to fruition: a Reader Google Desktop gadget! Post by 20% volunteer and Google Desktop expert, James Yum.

Wherever there are gadgets, RSS feed readers are never lacking, and Google Desktop gadgets are no exception. Until now, there hasn’t been a good way to combine all your feeds into a single gadget. With the new Google Reader gadget, you can now track your feeds and Google Reader subscriptions directly from your desktop. The Google Reader gadget is designed to be familiar for existing Reader users, yet compact like our other Desktop gadgets.

To get started, download the gadget (you might need to install Google Desktop first) and sign-in to your Google account. If you select a subscription, your gadget will update automatically with new posts. Clicking an item opens a larger view where you can see the item preview and perform familiar actions such as star, share, and email. Due to a technical limitation of Google Desktop gadgets, full HTML feeds won’t render fully, but clicking on an item title will take you to the original website in your browser.

The Google Reader gadget runs with the latest Linux and Windows releases of Google Desktop gadgets and is open sourced under the Apache 2.0 license. We hope this gadget is a fun and useful way to access your Google Reader subscriptions. Please give it a try and tell us what you think.

Posted by: Rajat Mukherjee, Group Product Manager and Nicholas Weininger, Software Engineer

Google Web Elements, unveiled today at Google I/O, build on your favorite Google products so you can easily add richness, interactivity and monetization to your website with the simplicity of copy and paste. We’ve packaged this simplicity into the new Custom Search element, making it even easier for you to add Google-quality search to your website. By helping your users find information faster, you can retain users on your website and monetize search with relevant Google ads. The element will allow you to create an interactive, inline search experience, so users don’t need to leave the web page they are on in order to search.

You can create a Custom Search element in two convenient ways: via the Custom Search element wizard, or by selecting the appropriate options within the Custom Search control panel.

When you log on to the control panel, you’ll see links to the Custom Search element wizard if you list your search engines (My search engines). If you click through to the wizard from the control panel, the appropriate search engine information is automatically extracted by the wizard — all you need to do is preview your search results, and copy and paste the generated code into your website.

You can also generate the right code for embedding the Custom Search element into your website by going to the updated Get code tab in the control panel. A new option allows you to generate element code.

The Custom Search element supports Promotions, which let you highlight specific information for specific queries. Refinement Labels automatically appear as separate tabs in the element, so you can navigate quickly to the category of results that you’re looking for. The screenshot below shows a preview of the search results in the element wizard.

While the Custom Search element is designed to help you get started quickly without spending time on the deep technical details, it is powered by Google’s scalable and flexible developer APIs, including the AJAX Search and Custom Search APIs, offering a world of customization.

Let us know if there are further improvements we can make to this user experience. To learn more about Google Web Elements, check out the AJAX API blog.

By Avi Drissman, Google Chrome Team

(Note: this is one of our occasional extra-geeky technical posts. If this isn’t your thing, don’t worry; our usual non-technical stuff will be back soon.)

If you’re a programmer, there are many reasons why you might want to go exploring the inner workings of Mac OS X. You might want to learn how how Apple achieves interesting effects. Or perhaps you’re just curious about how things work. (We’re all adults here, so I won’t lecture you about the dangers of using private or undocumented interfaces in your apps.)

In any case, though, you need to know how to read assembly, either PowerPC (if you have an older Mac) or x86 (if you have anything recent). While there are good resources available to learn about reading PowerPC assembly for exploration, there are fewer about x86. Despite the present and future of the Mac being x86, it seems like people have lots of anxiety about having to work with it.

I think the problem is not a lack of documentation on x86 assembly, but a surfeit of it. Most of it is Windows- or DOS-centric, usually with syntax that doesn’t apply (Intel syntax vs the AT&T syntax that GCC uses), and with the aim of teaching how to write it. But reading x86 assembly really isn’t that hard. If all you want to do is learn how to read the code generated by GCC, it’s probably just as easy as PowerPC.

The other day I was investigating how window minimization and window titles work. While exploring, I took notes of my discoveries. Let’s touch on two functions, in both PowerPC and x86 flavors.

Before we begin, I’m going to assume that you’re comfortable with assembly in general (though not necessarily with any particular one). If you have the latest developer tools, launch Shark (in /Developer/Applications/Performance Tools) and in the Help menu you can access various ISA references. In addition, Apple has ABI documentation for both the PowerPC and x86. I’m going to go over each function twice (once for PowerPC and once for x86); feel free to skim the PowerPC version if you’re accustomed to it. And finally, this is only for the 32-bit version of each platform; things change even more with 64 bits.

SetWindowTitleWithCFString

The trail always begins with a public call that uses the SPI that you want to figure out. In this case, I chose SetWindowTitleWithCFString because it has to somehow set the title of a window even if it’s minimized. I went with Carbon because sometimes the dynamic nature of Objective-C with Cocoa makes tracing code harder.

PowerPC

<+0>: mflr    r0          // save linkage<+4>: stmw    r30,-8(r1)  // stash r30, r31<+8>: mr      r30,r4      // save r4 (new title)<+12>: stw     r0,8(r1)    // make stack frame<+16>: stwu    r1,-80(r1)  // make stack frame

This is the prologue of the function. The PowerPC doesn’t have a dedicated stack pointer (convention is to use r1 for that), so the common way of implementing branches by pushing the PC onto the stack doesn’t work. Instead, the PowerPC has a link register and a command bl to branch and put the old PC value into the link register. Thus, almost every function starts with mflr r0, to pull the old PC into a usable register. Then in <+4> we save off some registers that we’re going to smash. Every function needs scratch registers to hold local variables, and usually the high-numbered registers are used. The stmw (store multiple words) instruction is useful for ditching many high registers on the stack. Then in <+12> we drop the old PC onto the stack and allocate 80 bytes on the stack.

A note on parameter passing. Integer-sized parameters (the only kind we’ll be dealing with today) are passed into a function starting with r3 and going up through the registers. Return values are returned in r3. So we see that in <+8> we stick away the pointer to the new name in r30 (whose previous value was stored on the stack earlier).

<+20>: bl      0x92881384 <_Z13GetWindowDataP15OpaqueWindowPtr><+24>: li      r0,-5600    // errInvalidWindowRef<+28>: cmpwi   cr7,r3,0    // if no window data, bail<+32>: beq-    cr7,0x928d2ae0 <+60><+36>: cmpwi   cr7,r30,0   // if no string to set, bail<+40>: li      r0,-50      // paramErr<+44>: beq-    cr7,0x928d2ae0 <+60><+48>: mr      r4,r30

This is where we must start making inferences as to what the code is doing. Fortunately, we have the symbols so it’s not too hard. We see that we use the WindowRef as a parameter to a C++ function GetWindowData(OpaqueWindowPtr), as the WindowRef was passed in as r3 and r3 wasn’t altered before the call. In addition, note that the function return value, being in r3, will overwrite the WindowRef value which wasn’t saved in a high register. That’s fine, as the WindowRef was just an index into a table and won’t be needed further.

At this point we run some checks. We compare both r3 and r30 to zero, and if either are zero we jump to the end with r0 set to the appropriate error code. (The end of the function will move r0 into r3 for return.)

The PowerPC condition register has eight condition sets. Why are we using cr7 here? Probably because cr7 is volatile and we can get away with not saving/restoring it.

<+52>: bl      0x928d2af8 <_ZN10WindowData14SetTitleCommonEPK10__CFString><+56>: li      r0,0        // return noErr<+60>: addi    r1,r1,80    // tear down stack frame and return<+64>: mr      r3,r0<+68>: lwz     r0,8(r1)<+72>: lmw     r30,-8(r1)<+76>: mtlr    r0<+80>: blr

The rest is pretty simple. We call a member function WindowData::SetTitleCommon(CFString*), and then do common tear down. We restore the stack pointer, put the return value into r3, restore the registers, move the old PC back into the link register, and branch to the link register (blr), returning us to our caller.

x86

The PowerPC register file is really easy: r0, r1, r2 … r31. x86 has fewer registers and they’ve historically had different roles (accumulator, base, source index, destination index, and so on). Seriously, forget about that. There are eight registers you care about. eax, ebx, ecx, edx, esi, and edi are all general-purpose registers. esp is the stack pointer. ebp is the frame pointer. That’s it.

PowerPC assembly reads right-to-left (except for stores). x86 AT&T syntax in general reads left-to-right.

<+0>: push   %ebp             // make stack frame<+1>: mov    %esp,%ebp        // make stack frame<+3>: push   %esi             // stash %esi<+4>: sub    $0x14,%esp       // make stack frame

x86 is stack-based. Parameters to a function are put at the top of the stack, and the rightmost parameters have the highest addresses. To execute the function, the call instruction was used. This instruction pushes the PC onto the stack, so even before we hit <+0> the parameters are four bytes above the stack pointer. In <+0> we save off the old stack frame value and in <+1> we establish our stack frame. At this point ebp is fixed for the entire function. In <+3> we save the old values of registers we’re going to use, and in <+4> we allocate space on the stack.

This is a perfect example of an ideal stack frame. ebp is the frame pointer. It points (to the stack) at the old frame pointer. ebp+4 is the PC of the function that called us. ebp+8 is the first parameter passed in, ebp+12 is the second, etc. Immediately below ebp are the values saved from the registers, which will be restored before the return. And below that is a bunch of stack space used for either register spillage or calling subsequent functions. One interesting note is that rarely are parameters pushed onto the stack for a call. The stack pointer doesn’t move once we make it past the prologue. We just set the memory right above esp (the stack pointer) and make the call.

<+7>: mov    0x8(%ebp),%eax   // get WindowRef in %eax<+10>: mov    0xc(%ebp),%esi   // get new title in %esi

The parameters are passed on the stack. Since fiddling in memory is slow, we pull the values into registers. It’s actually pretty analogous to how things go in PowerPC. There, lower registers like r3 are reused for parameter passing so important values are kept in the high registers. On x86 the parameters go on the stack and values are kept in registers when possible. Why eax and esi? Why not?

<+13>: mov    %eax,(%esp)      // put WindowRef on the stack<+16>: call   0x92dfb8f6 <_Z13GetWindowDataP15OpaqueWindowPtr>

With the PowerPC, you can tell how many parameters a function has by seeing how many registers starting with r3 are loaded. Here, we just look at the register indirect addressing with esp.

<+21>: mov    %eax,%edx        // stick WindowData into %edx<+23>: mov    $0xffffea20,%eax // errInvalidWindowRef<+28>: test   %edx,%edx        // if no window data, bail<+30>: je     0x92e4bb04 <+54><+32>: test   %esi,%esi        // if no string to set, bail<+34>: mov    $0xffce,%ax      // paramErr<+38>: je     0x92e4bb04 <+54>

Return values come back from functions in eax, but otherwise this is pretty much the same. The only thing of interest to note is the clever use of the peculiar register structure. In <+23> the constant 0xffffea20 is loaded into eax. But on <+34> the constant 0xffce is loaded in ax. But since ax is just an alias for the lower 16 bits of eax, the upper half of the word is left as 0xffff and we get the full constant 0xffffffce in eax. Why do this? Because loading a 32 bit constant takes 5 bytes while loading a 16 bit constant only takes 4.

<+40>: mov    %esi,0x4(%esp)   // load new title as param 2<+44>: mov    %edx,(%esp)      // load WindowData as param 1<+47>: call   0x92e4bb0c <_ZN10WindowData14SetTitleCommonEPK10__CFString><+52>: xor    %eax,%eax        // return noErr

Same stuff as before. The one note is the zeroing of eax with an xor. Just a fancy trick as the generated code is faster and smaller than the equivalent mov $0x0,%eax.

<+54>: add    $0x14,%esp       // tear down stack frame and return<+57>: pop    %esi<+58>: leave<+59>: ret<+60>: nop<+61>: nop

The mirror image of the stack frame creation.

That’s one function down and one left to go. Next time, we’ll take a look at a function that behaves a little differently than this one did.

Posted by: Ronald Ho, Product Manager, Google Docs

This next post in our Spotlight on Developers series highlights a gadget that combines spreadsheets and the My Map feature in Google Maps. In addition to using it while househunting like our guest author did, you might even find it useful to plot out points of interest for a vacation or a road trip this summer.

Last year, I was looking to move into a new apartment. Using a spreadsheet in Google Docs was a convenient way to list the apartments I was interested in, and creating a My Map in Google Maps was a great way to plot their locations. But, I wished there was a way to see both the map and spreadsheet at the same time. Some tools already existed to convert spreadsheets into KML, but these don’t work well when you’re updating a spreadsheet on a daily basis.

Thus the Spreadsheet Mapper gadget was born. The idea is simple: within a spreadsheet, generate a map based on address information in any column. This allowed me to quickly list the apartments I was interested in, while seeing how far they were from work.

Developing the gadget was easy. I was already familiar with programming a Google Gadget, and it was wasn’t difficult to use the extensions that pull spreadsheet data into the gadget.

Try it out using this template or insert it in your own spreadsheet using Insert > Gadget.

Or add the gadget to your own spreadsheet with these instructions: http://spreadsheets2kml.appspot.com/help

Posted by: Alec Go, AdWords Sales Engineer (and spreadsheet fan)

Guest post by Mike MacDonald, Founder and CTO, gWhiz LLC

gFlashPro, the first offering in the iPhone App Store from our company, gWhiz, is a popular mobile flashcards application used by students of all ages to study on the go. Google Spreadsheets provide a key element of the gFlashPro architecture.

To create a gFlashPro flashcard set, students or teachers open up a new Google Spreadsheet and put questions in the first column, and answers (including multiple choice) in the adjacent columns. Meta-data (set description, search tags, runtime options, and so on) isn’t required, but can be entered into a separate worksheet as simple key-value pairs. Then, on the iPhone or iPod touch, from within gFlashPro, users are given a list of the available flashcard sets (i.e., spreadsheets) for easy download. Alternatively, they can select flashcard sets from our catalog: a searchable repository of thousands of shared flashcard sets covering virtually any subject.

Once selected, the card set (spreadsheet) is downloaded into gFlashPro and presented to the user for mobile study and quizzing.

A few reasons we chose to use Google Spreadsheets:

• We didn’t want to have to write our own server-side flashcard creation code. If we “rolled our own”, it would have been code that we’d need to maintain going forward. Using Google Spreadsheets allowed us to leverage the strength of Google’s development team, the many built-in functions (e.g., importing .xls), and in the future, Google Gadgets.
• Google’s server infrastructure reliability is far better than anything we could possibly afford.
• User authentication is handled by Google. While this is not a huge problem, it’s just one more thing that our small development team doesn’t need to deal with.

And a few lessons learned:

• There are document limits for each account. In our case, the number and storage of documents is distributed across many thousands of users. Having a shared document in your account doesn’t count against that limit.
• While the Objective-C libraries for connecting to Google Docs are incredibly powerful, they are also fairly heavyweight for content-heavy apps like ours. We found that flashcard sets with more than 300 rows would blow out memory on the iPhone because of the substantial number of objects being created for each spreadsheet cell. One alternative we’re considering in another application is to write our own XML parser to exclusively process spreadsheet data coming from Google.

Any questions? Just email us at info@gwhizmobile.com.