Hi,
Before really starting to work on a SWI-client for the BaseX XMLdatabase, I thought that it might be a good idea to refresh my Prolog knowledge (I didn’t use prolog for more then 4 years ).
So after installing the most recent version of SWI, I installed a program I wrote long time ago with the intention of stepping through it with the debugger and seeing in how far I could follow what was happening.
The first thing I noticed was that now I had to start the goal in the console with test:test_inno.
(‘test_inno.’ results in a question if this should be corrected to ‘test:test_inno’). Does this mean that something has changed in SWI?
The second thing I noticed was that execution failed. And after a lot of debugging, I found that format(G_Out, 'node [', _) was no longer accepted. Instead I had to use format(G_Out, 'node [', []) when I wanted to write ‘node [’ to the stream ‘G_out’).
Is using _ not allowed anymore in the format statement? After correcting this, my program executed without problems.
Question:
While working with R, I learned to appreciate working with notebooks as a tool which helps in documenting the source code. In R and Rstudio, it is possible to run notebooks locally.
My question is if it is also possible to use notebooks in a local SWI installation/ SWI-console or can they only be used within the SWISH-environment?
A lot of things changed, but not this. If a predicate called at the toplevel default module (normally user) it searches the modules and proposes a qualified goal in a module if possible.
It should never have been. What is new is that the system checks that the number of elements in the argument lists matches the format specification. This means it always inspects the argument list. In this example the format requires no arguments and (thus) in the old days the argument list was never inspected.
If you install SWISH locally, there is a file ide.pl that you can load into your project after wich you can run
?- swish.
in the Prolog console to open up SWISH. It runs SWISH on the loaded files while you can interact both with the toplevel and SWISH.
It is a bit of work to setup SWISH, depending on the OS. The README of the SWISH repo describes the process.
Today - while searching for information on how to install Swish locally - I also found a Swish tutorial which mentioned the possibility to use R in Swish (SWISH -- SWI-Prolog for SHaring).
Does this mean that, besides your package, there exists already more packages which make it possible to use both R and Prolog? This would be interesting!
Using R from Prolog:
There are two Prolog packs that enable R calls from Prolog, “real” and “rserve_client” that is also used by swish. Plus a third one I wrote for my own purpose, rologp, but that is a bit under development, depending on my needs. Feel free to use it and/or add some functions if needed.
In linux,
swipl
?- pack_install(rologp). % or real or rserve_client
?- use_module(library(rologp)).
?- r_eval(rnorm(3, 100, 15), X).
real is very similar, Rserve_client needs Rserve to run on the R end, but that’s very easily set up.
Using Prolog From R
That’s the R package I was advertising in the other post.
I was under the impression that your work aimed at embedding Prolog in R. Was I wrong or does it have “two faces”? What is then the crucial difference? We have
real that uses the Prolog and R foreign function interface to run both in the same process. This is clean and fast. The downside is that getting it to run on a platform is not always trivial and may require some fiddling with dynamic loading. The other downside, and that was the reason for me to develop rserve_client, is that R is neither multi-threaded nor safe and I needed both for SWISH.
rserve_client implements the Rserve binary protocol, exchanging data and commands using TCP or Unix domain sockets. New R servers are efficiently creating by forking the master server (requires a POSIX OS for efficiency) that may have relevant R libraries already loaded. This allows multiple SWISH Pengines to use R concurrently and provides the required isolation. The safety is provided by running R inside a tightly locked down Docker container (no networking, using Unix domain sockets and practically no tools besides the R executable).
).