What is the best way to use this on a system with node install but not rust

[tychota]

Context

I'm building my blog on netlify. Netlify have no support of Rust yet.

Blog example: https://blog.tycoach.me/breaking-the-circular-deps-1

Compared the ugly looking diagram to my local version:

For sure, I will try to persuade netlify to support rust so i can cargo install, or at least let me use my own docker image for build. Else i can migrate from netlify to something else. (As an hack i just extracted the svg from the diagram: https://github.com/tychota/blog/commit/7b40f1ccecf38d11f7493e3728f5d36f56fcd7da)

That being said, increasing the reach by supporting Node env seems an ok concern for me. If not, please close the issue.

Ideas

Solution 1: svgbob on npm as childprocess

• i can create a module that package binary with target x86_64-unknown-linux-musl and launch child process

Question:

• are you interesting of supporting it once created (added in the readme)
• what about the licence ? can I redistribute binary ?

Solution 2: svgbob on npm as webassembly

Given rust awesome of webassembly, maybe it is possible to build svgbob as webassembly

Question:

• have someone tried it
• if I try, can this become official ? that will allow client side parsing of markdown with svgbob and thus increase adoption (like mermaid, which is build in gitlab markdown)

[mbarkhau]

I'd like to do something similar and create an extension for Python Markdown, which would simply spawn svgbob in a subprocess.

I think the easiest thing to do would be to package the binaries together with the python distribution. If those were available to download for the various platforms then I could use those. Alternatively I might look into cross compilation.

In the meantime I'll just try and work with my local file ~/.cargo/bin/svgbob.

[mbarkhau]

I took a short look at cross compiling, but I'm really new to the rust ecosystem and feel like I'm wasting my time. If there are any Rustaceans out there who already know how to produce static binaries for these targets, I would greatly appreciate some pointers.

x86_64-apple-darwin
x86_64-pc-windows-gnu
x86_64-unknown-linux-gnu

[ivanceras]

@mbarkhau I'm not sure how are you installing svgbob. Right now, you can easily install svgbob using cargo. If you are using a linux machine, the x86_64-unknown-linux-gnu target should not be a problem to compile to. I haven't done any cross compilation myself, but the simple way to do this is use a mac-osx to compile for x86_64-apple-darwin and compiling for windows can also be easily done in windows machine. I didn't include the binary release for each of the platform, since I don't have access to all of these machines as well, aside from the extra step in maintenance.

[mbarkhau]

@ivanceras I did cargo install svgbob_cli. Installing locally is not the problem, I'm just trying to find out where to get statically linked binaries for other platforms from, as I'm in a similar situation to you and only have access to a linux machine. I'd rather not impose on the users of a python library the requirement to have cargo installed on their machine.

[bjorn3]

Apart from libc and possibly some other system libraries all executables created hy rustc don't link to any library. Because of this it is enough to copy executables to another machine to be able to run them. If you want to create a completely statically linked executable you can compile for x86_64-unknown-linux-musl. After cargo install you can find the executable in ~/.cargo/bin.

[mbarkhau]

all executables created hy rustc don't link to any library. Because of this it is enough to copy executables to another machine to be able to run them.

That's good to know.

[mbarkhau]

I was able to cross compile for windows at least.

I initially ran cross build --verbose which failed, but it seems that cross only invokes docker and I was able to modify the invocation so that the /svgbob directory was added as a volume, not just the /svgbob_cli.

$ cd svgbob/;
$ docker run --userns host \
    --rm \
    --user 1000:1000 \
    -e CARGO_HOME=/cargo \
    -e CARGO_TARGET_DIR=/target \
    -e USER=$USER \
    -e XARGO_HOME=/xargo \
    -v $HOME/.xargo:/xargo \
    -v $HOME/.cargo:/cargo \
    -v $PWD/svgbob:/svgbob:ro \
    -v $PWD/svgbob_cli:/svgbob_cli:ro \
    -v $HOME/.rustup/toolchains/stable-x86_64-unknown-linux-gnu:/rust:ro \
    -v $PWD/svgbob_cli/target:/target \
    -w /svgbob_cli \
    -it japaric/x86_64-pc-windows-gnu:v0.1.14 \
    sh -c 'PATH=$PATH:/rust/bin "cargo" "build" "--target" "x86_64-pc-windows-gnu" "--release" "--verbose"'

Output from wine

user@host:~/workspace/svgbob/svgbob_cli/target/x86_64-pc-windows-gnu/release (master)
$ ls
build  deps  examples  incremental  native  svgbob.d  svgbob.exe

user@host:~/workspace/svgbob/svgbob_cli/target/x86_64-pc-windows-gnu/release (master)
$ wine cmd.exe

Z:\home\user\workspace\svgbob\svgbob_cli\target\x86_64-pc-windows-gnu\release>svgbob.exe --help
svgbob 0.4.1
SvgBobRus is an ascii to svg converter

USAGE:
    svgbob.exe [FLAGS] [OPTIONS] [input] [SUBCOMMAND]

FLAGS:
    -h, --help       Prints help information
    -s               parse an inline string
    -V, --version    Prints version information

[mbarkhau]

I think I have a binary for x86_64-apple-darwin based on this tutorial but I don't have any way to test it myself.

At least superficially it seems to be the right stuff

$ file src/markdown_svgbob/bin/svgbob_0.4.1_x86_64-Darwin
src/markdown_svgbob/bin/svgbob_0.4.1_x86_64-Darwin: Mach-O 64-bit x86_64 executable, flags:<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE|HAS_TLV_DESCRIPTORS>

[mbarkhau]

Binaries are available here if anybody is brave enough to try:

https://gitlab.com/mbarkhau/markdown-svgbob/tree/master/src/markdown_svgbob/bin

[mbarkhau]

I was able to start a MacOS VM and indeed the Darwin binary appears to work.

[mbarkhau]

Here's the package markdown-svgbob on pypi.

This library uses the "Solution 1" approach suggested by @tychota.

[yvt]

FYI, in Foremark, I successfully took Solution 2 to render diagrams on web browsers (example). It works by compiling a facade crate (which is linked to Svgbob) into WebAssembly and hooking things up using wasm-bindgen. The compiled module weighs roughly 200 kilobytes.

When the host application runs in a JavaScript environment, it seems like the most seamless, streamlined option because WebAssembly is architecture/platform-independent and doesn’t require IPC and subprocess management. It could be made into a single, standalone NPM package like they did with source-map and I did with hyper3d-envmapgen.

[breml]

@mbarkhau thanks for the binary releases you provide in your repo.

@ivanceras It would be great and highly appreciated, if you could provide statically linked release binaries for the common platforms (e.g. linux, windows, macos).

[mbarkhau]

Since this issue was opened, I think the situation with GitHub actions has become much better. I'm sure a PR would be welcome.

[erasin]

https://github.com/agoose77/svgbob-wasm has make wasm api for javascript, It can be embedded in any web page.