Trealla in the browser about trealla HOT 9 OPEN

Which browser is this supposed to work with?
Doesn't work in Chrome browser:

from trealla.

It should work in Chrome. Did you enter a query or just submit a blank one? Gotta put something in there.
I need to improve the error messages.

Here's the Socrates one: https://php.energy/trealla.html?src=person%28socrates%29.%0Amortal%28X%29+%3A-+person%28X%29.&q=mortal%28Who%29.&x=0

from trealla.

It is still a little browser dependent:

Now I get in Chrome, pressing the query button:

And in Seamonkey:

from trealla.

The demo uses top level await which it looks like Seamonkey doesn't support. The actual library should be OK though. I can write an example later, but the idea is use unpkg.com or webpack or whatever instead of em.sh. It's on NPM: https://www.npmjs.com/package/trealla

from trealla.

Using Wizer to pre-initialize the interpreter has significantly lowered the overhead. Now it's more like 4-8ms on my computer instead of 180ms.
However, the interpreter is still ephemeral (or more like it gets rewound to its initial state) and assertz and such doesn't persist yet.

The downside is it doubles the binary size 🙂

from trealla.

Got the interpreter persistent now! It might be useful for stuff. Finally figured out how to pass strings to WASM, it's quite an ordeal. Using the pl_* APIs and stdin/stdout for communication, works pretty well. It is quite fast on my computer, but still slower than native of course.

Next step is to asynchronously return one answer at a time instead of findall'ing everything, should be possible now I think, although I might need to hack in some helper functions.

from trealla.

With some recent changes the WASM bridge is even faster. I just ditched the json library for writing {}/1 terms, thanks to @Jean-Luc-Picard-2021 for the idea. Now a X=1 kind of query is around 0.3ms on my computer.
Getting close to v1.

from trealla.

Next step is to asynchronously return one answer at a time instead of findall'ing everything, should be possible now I think, although I might need to hack in some helper functions.

Why do you need that? Trealla Prolog itself could write the answer into the browser.
I don't see any need for an iterator interface. This is adopting some ideas of SWI-Prolog.
But if you only want a playground, why not put more responsibility into Prolog code itself?

from trealla.

It's not just to make a playground, that's really more of a proof of concept.
Trealla uses WASI for its WASM stuff (not Emscripten like SWI, Ciao, etc) so it can target non-browser runtimes too. I haven't tried it yet but it should theoretically work in FaaS runtimes like Cloudflare Workers. Trealla is also small enough to fit in these (CF Workers has a 1MB limit). For these, it's important that queries can run async because users don't have control over the scheduler. Multiple "threads" could be accessing the same interpreter. Air quotes around threads because it's more nuanced than that.
For browsers, the WASM code runs in the main thread and blocks the UI so it doesn't matter so much. We can work around this using Web Workers (IIRC Ciao already has this implemented). The Web Worker API is pretty horrible for library authors though so it'll take some finesse.
One of my main motivations for getting WASM Trealla working is that I ran into a lot of performance issues with Tau in my worker-prolog project. I would like to replace Tau with Trealla eventually.

from trealla.