I pushed a starting point to deal with this. After reading all the warning on emscripten against using dynamic linking I decided for another route I had in mind to resolve this issue: allow adding the foreign extensions to the core system. This is now a new option -DSTATIC_EXTENSIONS to cmake which is enabled by default for Emscripten. This allows building fully static SWI-Prolog executables with extensions, which surely has value on its own
Currently includes some of the clib libraries, the sgml library and some of the http libraries.
I didn’t include this deprecated library. It just loads `library(semweb/turtle)'. Note that the writing part of this library does not yet work as it depends on semweb/rdf_db and the C part of the RDF store heavily depends on threading.
I copied that from somewhere … Guess I should have checked (and tested) the latest version.
In the meanwhile #wasm_demo is updated to include GMP, (6.1.2) providing unbounded integers and rational numbers. Note that the GMP library is untested. It might be wise not to trust the results blindly.
I had bigger plans at first to add Typescript support, lots of tests and examples but currently this package contains the minimal number of things.
You get the original build output files in dist/swipl directory. The files are built using Docker which should make it much easier for people using Windows. The package already contains built files so you don’t need any build tools at all unless you want to experiment with different build options.
The package should probably be versioned in lockstep with main SWI-Prolog releases. @jan can publish new versions of the package. The package files (scripts etc.) should maybe be part of the SWI-Prolog repo.
Thanks, @rla. For any user, please consider the WASM version as a moving target. The interface will be extended and it is not unlikely it will see incompatible changes. There is also a lot of low-level stuff in the current interface that is likely to be removed.
Anyone willing to help to arrive at a clean, functional an documented interface, please make yourself known!
The Prolog end of the WASM port reached a new milestone: most meaningful extensions, including foreign extensions now compile and the corresponding test suites pass. Most of the problems with the test suite was about disabling parts that are require functionality that is not supported (e.g., threads). A remaining issue is that IEEE 754 float rounding seems unimplemented and therefore these tests have been disabled for the Emscripten version.
If the the library builds on Emscripten it should simply mean adding it to the package selection. You might give it a try?
It does touch a general problem though. The libpcre-2.8.so is about as big as SWI-Prolog itself … As the Prolog wrapper supports most functionality of the library we probably get most of the code added to our image The size increment from GMP was not as big as I feared because we use only a fairly small part of libgmp.
The current WASM version is getting really big. Part of this are some large Prolog libraries in the swipl-web.data image. Notably the generated library(chr) is about 1.5Mb. In theory we could only ship the core library in swipl-web.data and (on demand?) load the rest from the internet.
Modularizing the WASM core is a different matter. This can work using dynamic linking. The Emscripten says dynamic linking is possible, but comes at a considerable size increment because it includes the C runtime library into the core WASM file and must consider all interfaces of libswipl reachable. My interpretation of their description is “don’t, unless unavoidable”. That is why I explored the route to link extensions statically.
I guess the best option is to provide a complete (as far as possible) binary through npm and simplify making specific package selections. As is, this is a bit hard and the two most sensible solutions are to build everything or just the core.