Cloudant PouchDB sync (not) CORS error

The other day, I spent more time than I should have looing into an issue syncing between a local PouchDB instance in Firefox and a remote CouchDB hosted by IBM Cloudant. The error messages were less than helpful, even outright misleading. Google was of little help. I have the vague feeling that I ran into this before, so this time I’m writing it down.

Cloudant provides CouchDB hosting. This is very convenient, if like me, you loathe dealing with hosting infrastructure. They even have a free tier, which gets you a small CouchDB server for free. The free tier is limited to 1 GB storage, 20 reads/second, 5 writes/second. This is plenty for small personal projects that don’t have much data, are not particularly sensitive, and just need an always-on backend to sync with.

Even in an offline-first browser application with PouchDB, you might want to synchronise data before rendering most of the UI, if possible. This avoids users of the application being greeted with a blank screen or less than up to date data. The naive way of doing one-shot downwards replication is doing something like this:

await PouchDB.replicate(remoteDB, localDB);

At first, this might fail because you haven’t set up CORS. So you go to Cloudant settings, enable CORS for the relevant domains, or the wildcard domain (not recommended). You try again, and everything is fine.

After a while, you accumulate a couple of hundred documents in your DB. In new browser instances (new device, wiped DB, maybe incognito mode), it will start to fail. In Firefox, this runs for a bit, then fails with error messages seemingly blaming CORS settings.

The weird thing is, you’re sure CORS is set up correctly. In fact, the synchronisation kind of works, but only a couple of documents at a time.

After much head scratching, I finally, more or less by accident, had the Cloudant DB load page open while trying to sync. Turns out I was exceeding the request limit. What I got back from Cloudant where HTTP 429 Too Many Requests responses. The error message kind of says it, it’s just drowned out by the CORS stuff.

I’m still not really sure who’s to blame here.
Cloudant are not setting the Access-Control-Allow-Origin header on 429 responses. That’s inconvenient, but I guess it’s understandable since the rate limiting responses should naturally be as cheap as possible. Also, their load graphs don’t show historical data. You have to have them open to spot the problem as it occurs. Still, they’re providing me with a very convenient, free as in beer service, so I really can’t complain.
Firefox tries to be helpful and links to CORS documentation. Unfortunately it’s a bit misleading. It says “Cross-Origin Request Blocked”, but in fact the request was made just fine, but happened to return a 429 response. (Maybe the response doesn’t make it to JS, because of the missing A-C-A-O header, I don’t know.) They provide me with a free as in speech browser, so I can’t really can’t complain.

What to do about it? I can think of three bad options and one good option:

1. Retry in a loop.

   This is obviously not the right thing to do. But it makes some progress each time, so… I’m not proud to admit it, but I actually briefly tried this while figuring out what’s going on.

2. Make one big request.

   This works due to a quirk in Cloudant’s accounting. They reject requests if the previous requests have exceeded the 20 reads/second window. If you bump the PouchDB limits to make one request for all documents at once, it just slips by.

3. Make many small requests.

   PouchDB has options for number of concurrent replication batches and batch size. Setting them to very, very small values avoids the rate limit at the cost of making way too many requests. You basically replace being explicitly rate limited by Cloudant with being implicitly rate limited by network latency.

   await PouchDB.replicate(remoteDB, localDB, { batch_size: 5, batches_limit: 1 });

4. Make PouchDB aware of rate limits.

   This is of course the correct thing to do. I haven’t done it, at least not yet. PouchDB already has code for continuous background replication, which can deal with errors and has a configurable retry policy. It might not be too hard to adapt this to one-shot replication.

I’m currently doing 3 and feeling bad about it. At the moment, I’m the only user of this application and I don’t typically use it on new machines. This definitely needs fixing, though.

I packaged the Frink programming language for nix. Give it a go:

$ NIXPKGS_ALLOW_UNFREE=1 nix-shell --packages frink --run frink

Frink is a programming language with great support for units of measure. It is my go to desktop calculator these days.

Here’s Hillel Wayne on Frink: https://www.hillelwayne.com/post/frink/

Fiftyfive bytes of WebAssembly

I implemented a persistent hash map in JavaScript some time ago. It uses the popCount function to count the number of 1-bits in the binary representation of a number to save space, it’s really cool.¹ JavaScript’s standard library (unlike some other languages) does not have this function defined, so people use this implementation (which is from Hacker’s Delight, I think).

function popCount (n) {
    n = n - ((n >> 1) & 0x55555555);
    n = (n & 0x33333333) + ((n >> 2) & 0x33333333);
    return ((n + (n >> 4) & 0xF0F0F0F) * 0x1010101) >> 24;
}

To be honest, I only have a vague idea of how it works and currently no time to think about it. However, I do know that there’s a POPCNT instruction in my CPU (apparently introduced with SSE4 around 2007²).

I also recently read a nice article about the future of WebAssembly.³ Before, I did not really view WebAssembly very favourably. JavaScript is attractive as a compilation target because you get a high quality JIT compiler and runtime system for free. This is not yet true of WebAssembly and I don’t want to execute C++ applications in a browser.

It turns out that WebAssembly also has a POPCNT instruction, though. Wouldn’t it be cool to use that instead of three lines of bittwiddling?

Off I go to write the following WebAssembly program in the WebAssembly s-expression representation. This defines a module with one exported function called popcnt that takes a 32 bit integer and returns a 32 bit integer. The body of the function applies the 32 bit integer popcnt instruction to local 0 — the function’s first argument.

(module
  (func (export "popcnt") (param i32) (result i32)
    (i32.popcnt (get_local 0))))

Now, the typical workflow for serious WebAssembly use is way overkill. You use a compiler to compile your code (C, C++, Rust) to WebAssembly bytecode. You probably need some special cross compilation stuff too. Then you put the bytecode file onto some webserver somewhere, so your browser can see it and load it over the network. Then you need to feed the bytestream to the WebAssembly compiler in the browser.

I don’t want to write a C/C++/Rust program for a single instruction and install their WebAssembly toolchains. There is a small tool to turn s-expression .wat files into a .wasm bytecode files called wat2wasm. I don’t want to install that either. Luckily there’s a demo website where you can also download the compiled .wasm file.⁴

I do that and use some Emacs macros to turn the binary file into a JavaScript source representation of an array of bytes. My WebAssembly popcount function comes out at 55 bytes, and they look like this:

var bytes = Uint8Array.from([0x00,0x61,0x73,0x6d,0x01,0x00,0x00,0x00,0x01,0x06,0x01,0x60,0x01,0x7f,0x01,0x7f,
                             0x03,0x02,0x01,0x00,0x07,0x0a,0x01,0x06,0x70,0x6f,0x70,0x63,0x6e,0x74,0x00,0x00,
                             0x0a,0x07,0x01,0x05,0x00,0x20,0x00,0x69,0x0b,0x00,0x0c,0x04,0x6e,0x61,0x6d,0x65,
                             0x02,0x05,0x01,0x00,0x01,0x00,0x00]);

Fun fact: the sequence 70 6f 70 63 6e 74 on the second line spells the name of the exported function: popcnt. (The other bytes probably mean something, too.)

Great! We have some bytes without having to set up a webserver somewhere. Now let’s feed them to WebAssembly. We instantiate something with our bytecode in bytes and an empty record of JavaScript bindings to expose on the WebAssembly side. We get back a Promise of something which has an instance which has the exports of our WebAssembly module. In our case there’s only popcnt.

WebAssembly.instantiate(bytes,{}).then(function (webassemblythingy) {
  var popcnt = webassemblythingy.instance.exports.popcnt;

  // rest of the code goes here where popcnt is in scope!

I have no idea how to synchronize on a Promise to go from async land back into sync land, so imagine the rest of the code being inside the callback.

What can we do? Call popcnt! And it works!

console.log(popcnt(0)); // => 0
console.log(popcnt(1)); // => 1
console.log(popcnt(2)); // => 1
console.log(popcnt(3)); // => 2
console.log(popcnt(-1)); // => 32

We can also compare the JavaScript popCount against the WebAssembly popcnt.

    var count = 1000000;
    var res = 0;
    console.time("wasm");
    for (var i = 0; i < count; i++)
        res += popcnt(i);
    console.timeEnd("wasm");
    console.log(res);

    // Let's run the JS version for comparison.
    res = 0;
    console.time("js");
    for (var j = 0; j < count; j++)
        res += popcount(j);
    console.timeEnd("js");
    console.log(res);

Here are some numbers out of this highly scientific benchmark:

Cool to see that Firefox 63 did indeed make WebAssembly calls faster.⁵ Shame though that the JavaScript version is so much worse and the WebAssembly version is still only as fast as what v8 manages to generate from the JavaScript.

Future work procrastination: check what all of this actually compiles to. Obviously these are not proper benchmarks. However, the numbers are all suspiciously close. It would be a shame to go through all of this trouble only to find out that they just use the same software implementation of POPCNT. On the other hand, I would be quite impressed if it turns out that v8 actually recognizes the software implementation and emits a POPCNT instruction. Also, check whether they work around the performance bug in Intel’s implementation.⁶

Find the code here.

Efficient updates for closed records in PureScript

In JavaScript you can change the value of a field in a record like this:

var r = {a: 5, b: 7};
r.b = 9;                // or r["b"] = 9;
console.log(r);         // {a: 5, b: 9}

PureScript’s records are immutable. “Updating” a record field returns a new record with the updated field, but leaves the original record untouched.

-- assume some unsafe  log :: forall a. a -> Eff ()
do
  let r = {a: 5, b: 7}
  let r' = r { b = 9 }
  log r                  -- {a: 5, b: 7}
  log r'                 -- {a: 5, b: 9}

The record update itself compiles to something like this:

var r = {a: 5, b: 7}
var r' = (function () {
  var res = {};
  for (var f in r) {
     if (Object.prototype.hasOwnProperty.call(r, f)) {
        res[f] = r[f];
     }
  }
  res.b=9;
  return res;
})()

First we make a copy of the record being updated, r in this case. Then we (destructively) update the field in the copy. PureScript compiles to ES3, otherwise we could use Object.assign (ES6, not in IE) instead like this: Object.assign({}, r, {b: 9}).

Enter types

PureScript is a statically typed language and has built-in record types. The type of r and r' above is {a :: Int, b :: Int}. Given this information, we can generate better code for record updates. Because we know exactly which fields get new values and which fields take their value from the input record, we can just construct the right new record without iterating over the input record. In our example that would look something like this:

var r = {a: 5, b: 7}
var r' = {a: r.a, b: 9}  // no update, just construct the right record

This is around 100 times faster in both Firefox and Chrome.¹

Open records

PureScript supports row polymorphism. Which means that expressions, in particular functions, can operate on records of different shapes. An open record type looks like this: {b :: Int | foo}. This indicates a record that has at least a field b with type Int, but the rest of the record’s fields are indicated by the type variable foo. This allows us to write a function like the following which increases the integer-valued field count of any record:

incCount :: forall row. { count :: Int | row } ->  { count :: Int | row }
incCount r = r { count = r.count + 1 }

Because we don’t know exactly what fields the record will have, we cannot use this trick to compile incCount. We have to fall back to using the loop, or perhaps Object.assign in the future.

Conclusions

This turned out to be very easy to implement,² so PureScript 0.12 will generate better code for closed record updates thanks to types.

In this iteration of provenance in the wild we have John Wiegley writing about no less than three topics I’m interested in:

1. provenance
2. nix
3. recursion schemes

The context is hnix, a Haskell reimplementation of the nix expression language. It is a pure, lazy, dynamically typed, functional language. On top of that the nix package manager is built. And on top of that NixOS, a Linux distribution. If you don’t know about nix, check it out. It’s awesome.

Here is the Github issue that describes the new --trace option to hnix. Hnix takes a nix expression as input and evaluates it. With the new --trace option, it also outputs a nix expression that is somehow smaller than the original input but produces the same output. I haven’t looked at the implementation, and I don’t see a formal definition of how the output nix expression is related to the input nix expression, but it sounds like program slicing to me, which is related closely enough to provenance for this to make it into the provenance in the wild series.

I have thought about the possibility of doing something similar before, because Weili Fu, who started her PhD at the same time as me, works on provenance in the context of the configuration language Puppet. I’m happy similar things are happening in the real world.

If you want to read more about slicing, my advisor and other Edinburgh people recently wrote an ICFP paper on slicing functional programs: Imperative Functional Programs that Explain their Work, Wilmer Ricciotti, Jan Stolarek, Roly Perera and James Cheney. ICFP 2017.

Here’s the blog post about the implementation: http://newartisans.com/2018/04/win-for-recursion-schemes/ Turns out hnix is based on recursion schemes and this allows for a very neat implementation. I really need to find time some day soon to have more than a cursory glance at recursion schemes.

PureScript and Google Closure notes

I have played around with PureScript and Google Closure sometime in the last couple of weeks. The interesting part is of course advanced compilation. It doesn’t work out of the box and there are some hurdles to getting it to work even in principle. I’m not going to work on it in the near future, but I want to write down some observations, just in case.

The reason I have looked at Closure at all is that I keep thinking of ways to generated better JavaScript code from PureScript. We could not emit dictionaries for classes with no methods. We do not need an object as a dictionary if the class has only one method, we could pass the function itself. Specialize if the type is known. General inlining. Common subexpression elimination. Whatnot. Generating optimal code is a huge time sink. It would be nice if we could rely on Closure to do all the boring optimizations and only do cool language-specific optimizations in PureScript.

Closure as a bundler only (simple optimizations)

In addition to its own goog.module-based module system, Closure nowadays also handles CommonJS modules and ES6 modules. The PureScript compiler purs produces CommonJS modules in the output/ folder by default. This is how to call Closure to produce a single JavaScript file bundle.js with all modules bundled into one:

closure-compiler --process_common_js_modules --module_resolution NODE --dependency_mode STRICT --entry_point main.js --js main.js --js 'output/**.js' --js_output_file bundle.js

Note the --entry_point main.js argument. PureScript does not actually generate code that invokes any main function. Assuming you have a module Main, this is a main.js file that actually causes side effects to happen:

require('output/Main').main();

There can be multiple entry points. I think these are just modules assumed to be called from external code, and Closure will omit bundling any modules that are not transitively required by any entry point.

You might want to add --isolation_mode IIFE which wraps the output in an immediately called function and enables further optimizations.

This seems to work okay. It is not particularly fast (about the same as browserify). It is also not particularly good at reducing code size. In fact, in my tests it has been much better to use purs bundle and use Closure with simple optimizations on the resulting bundle. However, I think purs bundle cannot deal with npm dependencies. Closure does find modules in node_modules.

Advanced optimizations

Just adding -O ADVANCED to the above command does not work.

Constructors

Advanced optimizations require every function that is used as a constructor/with the new keyword to be annotated with /** @constructor */. PureScript generates constructors for typeclass dictionaries (I think) and datatypes.

I hacked the PureScript code generation to add @constructor annotations to capitalized functions. Note: the constructor annotation needs to be on the binder, not the function itself. This took me ages to figure out.

// This is okay
/** @constructor */
var Foo = function (...) { ... };

// This is okay
/** @constructor */
function Foo(...) { ... }

// This is NOT okay
var Foo = /** @constructor */ function ( ... ) { ... };

Records

The obvious problem, and what makes Closure advanced compilation so great/difficult are records. Just briefly: Closure renames record fields consistently if you use the non-string syntax for construction and projection. Closure would rename field in this {field: 5}.field, to a, or something. Well, this example would optimize to just 5, but you get the idea. However, Closure does not rename fields that introduced with the string syntax {"field": 5} or projected using the string/array syntax record["field"]. Now, if you mix these you are in trouble, because the "field" you are trying to project will likely have been renamed to a. The solution in JavaScript and ClojureScript is basically: people mostly use the non-string syntax because it’s shorter anyways, and you just have to be a bit careful to be consistent when you use strings.

PureScript has an interesting challenge: RowToList and all the record stuff that builds on it like records, simple-json, and so forth. I think in theory the set of record labels that will possibly be projected is computable at compile time and with enough compiler smarts we could generate specialized getters and setters to enable consistent non-string label records. In practice, it’s pretty hopeless right now. I think the way to go would be to always emit record construction and projection using the string syntax.

Note: the same is not true for datatypes and typeclass dictionaries. These should use non-string syntax. Their runtime representation is meant to be hidden from JavaScript anyway, so not even FFI code should be affected (much).

I thought of another approach. We could have different kinds of labels, those that get renamed and those that don’t. PureScript already has string syntax for labels (for labels with names of keywords and similar parser-related reasons). I suppose one could hijack those to have basically the same distinction as in Closure, where plain labels are subject to renaming, and string labels are guaranteed to be preserved. This is a massive change to the language though, and almost definitely not worth it now.

Other thoughts

One can annotate JavaScript with types that are used by Closure mostly for “typechecking” or at least linting and, supposedly, optimizations. While we could annotate at least some simple types, it is not clear how much would be gained.

The PureScript culture uses fairly little foreign code and it tends to be well-isolated into a few FFI files. This could make writing/checking “externs” files a lot nicer than in less disciplined languages and communities.

Conclusions

Closure with simple optimizations is not much better than other bundlers/minifiers. If you can, use purs bundle first, then run Closure on the result.

My codegen hacks to the PureScript compiler made it possible to compile some very simple experiments (that did no use records) with Closure’s advanced optimizations to really, really good JavaScript. No curried functions. All typeclass indirection gone. Pretty much perfect. It will not work as well for more abstract code than just printing results of arithmetic expressions, of course.

I don’t think it would be too hard to either change PureScript itself, or write an alternative backend, to produce Closure-compatible code. I still think the easy way to better performance is through using Closure, rather than reimplementing optimizations in the PureScript compiler.

Fail better

I have tried to use Idris a number of times in the past. I never got much further than copy & pasting the definition of Vect and writing append : Vect n t -> Vect m t -> Vect (n + m) t and zip : Vect n s -> Vect n t -> Vect n (s, t).

I have glanced at Agda and its ternary mixfix operators and dabbled in Coq, where you can write all the fancy dependent types, but none of the functions.

It never clicked, but I guess I must have learned something.

Last week I started another toy project in Idris. I had problems with types, and solved them by adding proofs of properties and using them. I even made Idris generate some proofs for me. It is so much fun!

Watch this space for an upcoming series on a tiny language with traced evaluation.

What’s my point? Not sure. Persistence pays off in learning?

My computer science teacher in high school had this quote from Worstward Ho by Samual Beckett on his door and I liked it even then.

Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.

We did so much cool stuff. Program Turing Machines and microcode for some simulated CPU, write a meta-circular evaluator in Racket (which was called PLT Scheme back then), discuss the Entscheidungsproblem and proofs by diagonalisation. I did not appreciate it at the time. I wanted to write real programs™, in a real language, like Java™. 🤦

Grades vs Politicians

Marginal Revolution linked to this article: Guy Who Got a C on Constitutional-Amendment Paper GETS CONSTITUTION AMENDED.

My first thought was “oh no, some idiot passed some idiotic legislation”.

Turns out the amendment in question seems reasonable. Congress can’t just raise its pay with immediate effect, there have to be elections in between, which would presumably give the new congress opportunity to undo it. But the amendment is not my point here.

My concern is “some idiot”. I don’t think of myself as someone who always assumes the worst of people. I do think grades are a poor reflection of ability or aptitude. So why would I go into this article expecting to read about some idiot passing an idiotic law?

I could have thought “see, grades are overrated”.

This had me thinking. One option is, that I actually updated my prejudices to take into account recently acquired knowledge about grades. I used to think that grades are a complete waste for everyone involved. I was wrong. Standardized test scores predict all sorts of success metrics very well. But this is in aggregate. I maintain my belief that variance is high. One person getting a C for one essay should not cement my opinion of them.

But apparently my opinion of politicians and the likelihood of any of them passing a good law is even lower than that of teachers and their ability to give proper grades. Signs of our times or me being an ass? Probably a bit of both.

It’s easier to ask forgiveness than it is to get permission

Four emails later, I have graciously been permitted to swap desks with my office mate.

At least I learned that the title is a Grace Hopper quote.