Wavedrom support

[JmyL]

It would be nice to have Wavedrom(https://github.com/drom/wavedrom) as an preprocessing extension.
It is 4 years old open-source software, It's really cool to adding waveform in documents.
It's implemented with javascript, but it also served as an executable cli version on here: https://github.com/wavedrom/wavedrom.github.io/releases

[pepijnve]

Looks like a perfect fit for asciidoctor and the diagram extension.

I couldn't find any documentation on the CLI interface. Just as a note to self, based on the code, the way to invoke it is wavedrom <input file> <output type> <output file>.

[pepijnve]

@JmyL I've made an initial attempt at integrating wavdrom support using the CLI version. On Mac OS X it doesn't work correctly yet. The command line arguments that I pass to nw.js aren't reaching the application (argv is an empty array in wavedroms init.js). I tried directly calling the nwjs binary and starting the application using open WaveDromEditor.app, but both failed to produce the correct results. This seems to be a known issue (see wavedrom/wavedrom.github.io#7)

I have some unfinished code lying around that used phantom.js to run javascript code. I'll have a look at using that to drive the javascript code directly rather than using the nw.js wrapper.

[drom]

Proper CLI would be:

WaveDromEditor source <input file> <output type> <output file>

I have some old phantomjs version of CLI tool, but I was thinking that pure nodejs CLI tool would be better. Working on it now.

[pepijnve]

Adding the missing 'source' keyword did the trick. Thanks!

[drom]

@JmyL @pepijnve let me know how successful integration is 👍

[pepijnve]

The code is all there and the unit tests are passing. I manually inspected the PNG and SVG files that get generated during the tests and they correct to me. Once Travis gives the green light on Linux, I'll merge the feature branch and cut a new release.

[pepijnve]

I had to disable the unit tests in the end since wavedrom can't run headless at the moment. I've merged what I have already, but using phantom.js is probably the way forward after all since that's designed to run on servers.

[JmyL]

Incredible! 👍

[pepijnve]

You're welcome. Let me know if you run into any issues with the integration. You'll probably be the first to kick the tires...

[mojavelinux]

I second that. 👍

[drom]

@pepijnve Great job!
Will it help if I have pure nodejs module that does not require DOM, NW.JS or PhantomJS?

[pepijnve]

@drom for the asciidoctor-diagram integration itself it doesn't really matter. It invokes wavedrom as a subprocess so it isn't dependant on the technology you're using to implement it.

The consequence of using nw.js for the WaveDrom CLI is that it can't run on a headless server. This restricts where asciidoctor-diagram users can use this integration. Running it on your typical CI server for instance is not possible. There's an issue open for this in the nw.js project (nwjs/nw.js#769).

I think the simplest solution for this problem is to also provide a CLI wrapper for wavedrom that uses phantom.js. phantom.js is explicitly designed to run in headless server environments.
I personally wouldn't try to remove all DOM dependencies from your code. That feels like a lot of work for very little added value. phantom.js provides an entire headless browser environment (including the DOM) so I don't think this will be necessary either.

The Mermaid diagram generator has a phantom.js based CLI wrapper that provides a good example of how this can be done (see https://github.com/knsv/mermaid/blob/master/bin/mermaid.js and https://github.com/knsv/mermaid/blob/master/lib/cli.js).

[mojavelinux]

provide a CLI wrapper for wavedrom that uses phantom.js

100%

[drom]

@pepijnve @mojavelinux Done! PhantomJS version of WaveDrom CLI tool is here:
https://github.com/wavedrom/cli
Try it, let me know

[pepijnve]

d0b09c7 makes asciidoctor-diagram look for wavedrom-cli first and falls back on wavedromeditor. Just ran the specs and seems to work as intended.

I ran into one small quirk: if the output file does end with '.png' then no output is generated. This doesn't happen when generating svg files. Not a big deal; I worked around it in the code.