There are more and more software libraries being ported to JavaScript. The best example is JavaScript/HTML5 Citadel demo of the Unreal Engine. So why not to try with some chemical stuff? One of the most important chemical software libraries is IUPAC InChi. It's also extremely hard to reimplement as it's written in low-level, functional-style C. On the other hand it's just a few headers and source files, without any dependencies so it's a perfect use case for Emscripten.
Emscripten 'is an LLVM-to-JavaScript compiler'. It can be used as a drop-in replacement for standard tools such as gcc or make. Recently it got support for
asm.js
- optimizable, low-level subset of JavaScript.
I wasn't the first to come up with this idea - one of our local heroes, Noel O'Boyle wrote a set of articles about translating the InChI code into JavaScript on his blog. I didn't know about his work during my experiments, which is good, because I took slightly different approach and came up with different results:
- I decided to compile
inchi-1
binary (by exposing itsmain
function) not the library, because, according to readme file in InChI distribution package, the binary 'does extensively check the input data and does provide diagnostic concerning input structure' so it's the only tool that can be used as an InChi generator with 100% guarantee of having correct results for all input files. - I used '-O2 -s ASM_JS=1' flags to optimize speed.
- The resulting JavaScript code (emscripten generated html with embedded JS) weighted 2.8 MB and 732 kB after zip compression (all modern servers and browsers support compressed files). The original
inchi-1
binary is about 1.1 MB large so this sounds reasonable.
Of course there are some drawbacks of my approach - the most obvious one is IO.
inchi-1
is command line tool expecting a file or plain text as input and printing some text to stdout
and stderr
. JavaScript doesn't have any standard input or output. This means that this behavior must be somehow mapped to browser environment. Emscripten maps output to specific textarea element which is reasonable. On the other hand any request for user input is mapped to javascript prompt window. This prompt can accept one line of text at time. Molfiles contain many lines so putting a molfile line by line is tedious.
The solution to this problem would be adding a file input to the webpage and accessing it via Javascript Blob interface. Having the files selected allocating some memory in Emscripten using hints from this SO question and pass it to
process_single_input
function from inchimain.c
file (this should be exported instead of main
).
So far I haven't solved the last issue. You can check proof-of-concept here. To use it, open link in your browser, open javascript console (
Control-Shift-K
on Firefox, Control-Shift-J
on Chrome), then type (as two separate commands, pressing Enter after each one):bla = Module.cwrap('process_single_input', 'string', 'string')
bla('bla -STDIO')
After that, the standard javascript prompt will pop up. You have to copy there your mol file - line by line. If the line should be empty (usually 1st and 3rd lines are) just press enter in the input box. After last line (
M END
) hit cancel
instead of OK
. Then select a checkbox suppressing all further popups and press OK
. If you entered all mol file lines correctly you will see the result!
michal
Comments