Wiki Discussion: SWI-Prolog in the browser using WASM

[jan]

@j4n_bur53

Interesting! FF=FireFox? Do you have Chrome?

Only Chromium. Times are pretty much the same.

[josderoo]

Got the following error while building:

[10/11] Generating wasm-preload/boot.prc
FAILED: src/wasm-preload/boot.prc
cd /home/jdroo/github.com/SWI-Prolog/swipl-devel/build.wasm/src && /usr/bin/cmake -E make_directory wasm-preload && /usr/bin/cmake -E copy /home/jdroo/github.com/SWI-Prolog/swipl-devel/build.wasm/home/boot.prc wasm-preload/boot.prc && /usr/bin/cmake -E copy_directory /home/jdroo/github.com/SWI-Prolog/swipl-devel/build.wasm/home/library wasm-preload/library && /usr/bin/cmake -E copy ../packages/chr/chr.pl ../packages/chr/chr_translate.pl wasm-preload/library
Error copying file "../packages/chr/chr.pl" to "wasm-preload/library".
Error copying file "../packages/chr/chr_translate.pl" to "wasm-preload/library".

but can temporarily work around by removing it from cmake/EmscriptenTargets.cmake

[jan]

@josderoo

Got the following error while building:

I know. Need to find a clean work around

[josderoo]

@jan

@josderoo

although I am not sure why the latter return undefined instead of true

The foreign yield has a bug that causes the block of “well known terms”, among which the well formed semantics (WFS) delay list to be garbage collected That is my TODO for this morning … Thanks for reporting.

This is now working fine i.e. returning true

[EricGT]

If you want to keep up with the changes as fast as they are committed and can read Prolog, C, CMake, JSON, HTML and JavaScript then just check the SWI-Prolog development repository commits that start with WASM

Commits · SWI-Prolog/swipl-devel

Note: AFAIK there is no way on GitHub to limit the search for commits by name.

[josderoo]

Nice to see that many people love it https://twitter.com/josderoo/status/1554960976553844743 esp. also for semantic web https://twitter.com/josderoo/status/1555934486545801217

[jfmc]

Excuse me but I need to clarify some things:

• 48 hours do not reflect all the work and people involved in this work
• academic papers are not just code that do what others have done before (if it does not teach anything that people knew before, there is no point in publishing it)
• there exists excellent research papers about implementation details, where multiple decisions were considered and benchmarking evaluates them

Research is complementary to this industrial work. Sometimes 3 years are really necessary to find, write, and review a solution. Usually it is much less (around 6 months).

I sincerely believe that Prolog ignoring research is shooting oneself in the foot. If the language is nice, runs fast, or can do things that others cannot do, it is because someone did really hard research work.

[jfmc]

Thanks @jan. We have the same set of benchmarks then. I’m curious about other aspects of the execution (loading code, indexing, etc.) that may affect uses of Prolog code in real life.

[herme]

I would not like to get into a discussion of “industrial work” vs “academia”, first because this is not the forum and also because it should be obvious to everyone that they are both necessary and quite complementary, but an important characteristic of academic research is that it is refereed, to ensure correctness, relevance, and originality. All of this is important and takes time, and is how we ‘build on the shoulders of giants’. Without this process we are condemned to reinvent the wheel, as mentioned by @jfmc.

@j4n_bur53

Well the requirements for industry work are much harder:

Industry: Having 10 ideas in 1 program code page.
Academy: Presenting 1 idea on 10 publish paper pages.

But this doesn’t dimish the value of academy. Especially when you
want to get slow paced careful introductions to some topics, reading
a paper might or might not be the choice.

[jan]

@jan

@josderoo

Got the following error while building:

I know. Need to find a clean work around

Pushed some cmake magic to fix this. Note that the build dependencies are still incorrect in the sense that just pulling the source and running ninja doesn’t always get the preload directory right. The ugly but safe way to rebuild after pulling the source is

rm -rf src/wasm-preload && ninja

The src/wasm-preload directory must be populated with what must appear in the /swipl directory of the WASM version (the Prolog home). That needs to be assembled from home and generated Prolog files for the various packages and may (unlike home) not use symlinks as that will result in symlinks to nowhere in the final WASM .data file So, we copy some directories using cmake -E, but this is not automatically redone if some Prolog library file changes

[herme]

As for Lightweight compilation of (C)LP to JavaScript I think you are being a bit dismissive? Just to give some examples, it talks about several problems and possible solutions, and, it provides some performance figures, which have allowed other people to have an idea about how far you can get with that approach, without having to redo all the work (which is the point of publishing research). And all of that checked by reviewers, with references, etc. I honestly do not understand why you have a problem with it.
And yes, if to explain something well it takes several papers or a book, there is no problem with that. And note that that paper came with publicly available code in a repo.

I do agree that blogs, stack overflow, etc., are wonderfully useful, but they do not replace academic publications. Looking at some language implementations nowadays this is painfully obvious: many great ideas that are very carefully described in papers are systematically ignored and the mistakes and solutions are repeated over an over again, with the respective authors living in the illusion that they have invented something.
But, hey, I may just be an oldtimer, totally willing to accept that.

@j4n_bur53

Lightweight compilation of (C)LP to JavaScript

[jfmc]

bar :- bar.

Seems to hang forever in SWI WASM and it cannot be aborted.

[jfmc]

BTW, we do not need 10 years to produce something useful

[jfmc]

Good to know that the traditional Prolog toxic discussions are also possible in Discourse

[herme]

Long live Prolog!
Thanks @j4n_bur53 for the nice words on Ciao, btw.

[jan]

@EricGT

Now that we have persistent Prolog files need way to remove or delete the files since they are stored in the browsers cache.

Tried this for Chorme but it does not work.

Press F12 to open developer tools.
Go back to Chrome, right click reload button, select hard reset and clear cache

It is not the cache but the browser localStorage. The cache merely avoids re-fetching pages. The localStorage is a way to associate key/value pairs with a given document (web page) that persist. Deleting works (for me) in Chromium as well. Note that it deletes the current file and switches to “program.pl”. You cannot delete “program.pl” itself (but you can blank it).

@EricGT

Seems that file names with _ in them are not valid.

That is now allowed. It only allows for a limited set of characters to avoid nasty injection attacks. Simple but effective

@EricGT

The hello world example from SWISH behaves badly.

hello_world :-
    writeln('Hello World!'),
    sleep(1),
    hello_world.

That was a bit of a challenge. That it behaves badly was to be expected: it executes a sleep in WASM, so if all is right it nicely writes, but as the browser event loop isn’t triggered nothing appears. This is now handled by redefining sleep/1 in library(wasm) to use js_yield/2. Then the wrapper around yieldable calls returns an object classified as builtin that can be executed and aborted. The execution calls setTimeout() and the abort clearTimeout() followed by resuming using wasm_abort.

[EricGT]

@jan

It is not the cache but the browser localStorage.

Thanks.

For others using Chrome and wondering how to see Local Storage see

View and edit local storage - Chrome for Developers

---

Of note to other using Chrome on Windows

While I can see the entry for the key and value removed (deleted) in the Chrome developer tools (F12) I can not see the file removed on the site. At present I am not worried about this nor is it high enough on my list to hunt down the root cause for this.

---

---

@jan

@EricGT

Seems that file names with _ in them are not valid.

That is now allowed.

Thanks.

Saw the commit yesterday.

---

---

@jan

@EricGT

The hello world example from SWISH behaves badly.

hello_world :-
    writeln('Hello World!'),
    sleep(1),
    hello_world.

That was a bit of a challenge.

Thanks.
Now works as expected.

WASM: Handle sleep/1 using JavaScript setTimeout()

---

Note that this defines sleep/1 in user, overruling system:sleep/1.

That just reaffirms

“Learn the rules like a pro, so you can break them like an artist.”

― Pablo Picasso

[EricGT]

@jan

So as not to overload you with a large number of possible issues by doing this all at once I plan during those short pauses in the day to use code I find on SWISH and try them with #wasm_demo.

Are there items you want me to prioritize and others that I should disregard?

[rla]

To me it seems that having a working terminal for wasm version of SWI-Prolog is essentially a solved problem

The last commits by @jan are especially nice.

Since we use some JSON to communicate with JavaScript now (WASM: Handle sleep/1 using JavaScript setTimeout() · SWI-Prolog/swipl-devel@7be5b60 · GitHub) then would it be possible to use full JSON support (from http package) so that we would not have to manually construct JSON strings? Could we extract it from http and put it into the core?

[jan]

@EricGT

Are there items you want me to prioritize and others that I should disregard?

I’m still not sure how to continue. The current shell.html is a demo and experimentation platform to get the communication working and verify that the WASM version functions normally. Eventually it should be able to verify the core Prolog engine using ctest under Node.js.

The open question is how to interact with JavaScript. There are several issues to that

• Calling Prolog from JavaScript. This is ultimately done through the C API but we surely want something more high level.
• Calling JavaScript from Prolog. Now there is js_call/1 that takes a string that is passed to emscripten_run_script(). If the script raises an exception the page is broken Still wondering how to handle this.
• Yield still has its limitations

@rla

To me it seems that having a working terminal for wasm version of SWI-Prolog is essentially a solved problem

Well, I’m not that far The progress has been better than I feared. One issue is how to call JavaScript from Prolog, so we can manipulate the DOM. I see:

• emscripten_run_script() can call anything, but we get no return value and I’m unsure we can handle exceptions.
• EM_JS() allows calling a fixed JavaScript function. Possibly we can make this work by first placing the function (name) and arguments somewhere, use this and fetch the results from some other well known place?
• We could use js_yield(Request, Response)

First step seems a good bidirectional default translation between Prolog data and JavaScript.

@rla

then would it be possible to use full JSON support (from http package) so that we would not have to manually construct JSON strings? Could we extract it from http and put it into the core?

Unfortunately this makes another problem surface: the http package contains too much. json support should never have been there and neither should most of the html support. The whole HTTP infrastructure requires threads. The WASM version clearly wants the HTML, JavaScript and JSON support, but not the HTTP server libraries.