Any chance for JavaScript version of _js_decode_string

[tolysz]

Hi there
I have been playing with ghcjs compiled against stack nightly with aeson: "1.0.1.0". Compiles fine, however during the runtime I have:

uncaught exception in Haskell main thread: ReferenceError: h$_js_decode_string is not defined

Which translates to JavaScript shim for cbits implementing this function being missing.

[bergmark]

We discussed having a flag to toggle between the C-version and normal haskell (which ghcjs could use), but @winterland1989 said it might be tricky to do. I'd happily accept the addition of such a flag.

The other option, like you say, is translating the C code to JS. I don't know if this would be easier than the alternative a bove. If I understand correctly ghcjs has a bunch of patches like this for libraries, so if someone creates this patch it doesn't really matter for users whether it's included in aeson or in the ghcjs repo, right?

[tolysz]

Should it be something like "PURE_HASKELL" set via .cabal and have pure haskell version of it.
For the last point, it is yes and no, in the ideal world, the packages have all patches.
I would still prefer to have a pure version.
(I will still look for some JS version eg. https://gist.github.com/pekkaklarck/6712255 )

[winterland1989]

I got the feeling that someone really should make an aeson fork specialized for javascript following how elm did, because js runtimes have already provided extremely fast parser from string to aeson Values, I mean using JSON.parse with FFI may be possible. Then we can decode haskell values from Values using aeson's machinery.

So it's not _js_decode_string we should shim, we should shim underline json parser IMHO.

[spl]

I ran into this issue myself (ghcjs/ghcjs-base#71) trying to move from a patched clone of aeson to the 1.0.2.0 release, which has a fix I need. Is the next step to change aeson or ghcjs-shims or something else?

[bergmark]

Is the next step to change aeson or ghcjs-shims or something else?

Either one works but if the shim is written in javascript i think it fits better inside ghcjs-shims.

[alexanderkjeldaas]

Is there any solution to this?
Is there a workaround?

[wereHamster]

If you don't expect any escape codes in the input, you can drop this into your code. It requires TextDecoder which is not available on all browsers, but there is a shim if cross-browser compatibility is an issue. I don't know how to deal with escape codes. I tried to roundtrip through JSON.stringify/JSON.parse but that didn't work.

window['h$_js_decode_string'] = function(dest, destOffPtr, destOffPtrOff, s, sOff, send, sendOff) {
    // Decode the input as UTF-8. The resulting string may still contain escape codes though!
    const input = new Uint8Array(s.buf, sOff, sendOff - sOff);
    const str = new TextDecoder('utf-8').decode(input);

    // Write the string as UTF-16 into the dest buffer.
    var i = 0;
    for (let ch of str) {
        if (ch.length === 1) {
            dest.dv.setUint16(i, ch.charCodeAt(0), true);
            i += 2;
        } else if (ch.length === 2) {
            dest.dv.setUint16(i, ch.charCodeAt(0), true);
            dest.dv.setUint16(i + 2, ch.charCodeAt(1), true);
            i += 4;
        }
    }

    // Write how many UTF-16 code units we've written into the destination buffer.
    destOffPtr.dv.setUint32(0, i / 2, true);

    return 0;
};

[tolysz]

How do you add the above JavaScript to the cabal package?
Once we have something we can start improving it.

[wereHamster]

@tolysz this should go into the ghcjs/shims package, ideally. I have no idea how else to add it so that ghcjs picks it up automatically. You probably need such a yaml file for aeson, somewhere: https://github.com/ghcjs/shims/blob/master/bytestring.yaml

[bergmark]

This was resolved with a haskell implementation in 1.1.1.0!