I try to use SWI with .net.
I try to use SwiPIC.dll and have read the SwiCsPlDocumentation but it doen’t help.
I can reference the SwiPIC64.dll but not the SwiPICs.dll.
I’m using VS 2017.
where is this SwiPlCs? I’d be interested to check out this module, but I can’t find it.
I’ve found it here
SwiPICs
Thanks jaegerbo.
First guess: Is your C# project configured as an x64 build? Then perhaps you aren’t supposed to reference SwiPlCs, despite what the documentation says. I imagine these dlls are different platform builds.
@jan another case to consider for the documentation rearrangement project? I don’t know where contrib is to be found, but it’s not under Add-ons (packs) or documentation (packages).
Also, these links are broken (403 forbidden)
The documentation is online available here. The documentation page also provides a link for downloading. We provide an infrequently updated binary below.
I know very little about .net. As far as I recall, the repo was added to the SWI-Prolog github to avoid it being lost. It would be nice if someone wants to take responsibility for it.
I’ve tried it with different builds. x86, x64 and both.
Are there any other methods to communicate with SWI Prolog?
A more generic way?
The baseline way is with a C extension, and there’s also a C++ version of that. You could with some work develop C++/CLI code and make it work with .net. Otherwise you can comunicate using operating system features: sockets, TCP/IP, etc.
It’s a shame the C# version doesn’t work. If I had time I could fix it given source code, but I can’t promise anything now.
I’m not firm in sockets and other inter process communication, but I will have a look on this.
Thanks for that.
Note that it is unlikely that anything serious is broken with the C# interface. The SWI-Prolog C interface, which is in the end the dependency, is very stable. It is not always binary compatible though, especially between major versions, so you may need to recompile the interface. Other possible reasons are renaming of the SWI-Prolog DLL and its dependencies (although these should be loaded anyway as long as the SWI-Prolog bin directory is in PATH and finally the location of the initial state if this is explicitly loaded by the C# interface. This used to be boot32.prc or boot64.prc, depending on the architecture and is now simply boot.prc as it no longer depends on the architecture.
I’d assume the error message should indicate which of these is the problem.
Thought: It might help to have a test program build alongside swipl.exe (but in a test directory, I suppose), which can test the C interface.
For my part though, I largely abandoned a direct interface with Prolog because I get much better development capabilities when I can use both the swipl-win and Visual Studio development environments concurrently. I can change one program without restarting both.
To get there, it took a bit of programming, but a networked client-server connection lets me do it.
The C interface as such is pretty much tested as most of the extension packages use it. The issue is users compiling against the installed system and, worse, users trying to embed Prolog in something else. Those are problems with lacking or incompatible build tools, different locations of Java, dll/shared object
search paths, etc. I do not see a trivial way to test that in the build environment.
And you are right: in most cases it is a much better idea to run Prolog on itself and setup some communication. If communication overhead is not critical, using HTTP with JSON messages is probably the simplest and most versatile solution. If the latency needs to be very low and/or the amount of data is huge there are many alternatives and the best solution varies from application to application.
Also far less troublesome is to use your C/C++ to create additional Prolog predicates but keep the overall control in Prolog, at least during development. To some extend you can also embed Prolog and use library(prolog_server) to create a telnet server that you can access to (re)load Prolog code and test queries. Use with care as this allows anyone who can connect to your localhost port to run anything in your process! At some point I’d like to use libssh to create an ssh server.