Organizing sources of a mixed Logtalk SWI Prolog project

[hnbeck]

I’m bothered with organizing my SWI Prolog/Logtalk sources with respect to the needs of my colleagues. (System is always Win10)

So lets begin the story. We have 3 types of colleagues:

1. Logtalk programmer: writing the application, have SWI Prolog and Logtalk installed
2. Prolog programmer: writing only on one or two special source files in the application, these source files will be pure SWI Prolog. Have SWI Prolog installed, but not Logtalk
3. user (of the in Logtalk written application) Have neither Logtalk nor SWI Prolog installed

All sources are in some Gitlab.

I know that Logtalk can compile into Prolog sources. Some possible use cases then would be:

A) from the Logtalk programmer: compile all sources into SWI Prolog, check in. The Prolog programmer checks out and runs application with SWI Prolog. Problem: as far as I understand, SWI Prolog need to know where the adapter file swi.pl is or get this somehow, respectively.
B) From the Logtalk programmer: compile all sources into SWI Prolog. Do from this with „saved_state“ od SWI Prolog a stand-alone running *.exe and checks in. The User checks out the *.exe and uses the application.

As far as I understand, in principle all Use Case should not be a problem in principle. But how to tell give the SWI.pl adapter file to the Prolog programmer who has no Logtalk on the machine. Do you think the best would be some batch for compilation which also takes the adapter file to the sources?

Assume the Logtalk app uses all kind of stuff: objects, protocols but also SWI Prolog pure source files.

Any hint for a good organization of code would be very welcomed :)

Cheers

Hans

[pmoura]

For deploying (but not developing) your application, the Logtalk pack for SWI-Prolog can be handy. That allows loading Logtalk on demand using the goal use_module(library(logtalk)).

An alternative, at least for the final user, would be to embed Logtalk and the Logtalk code in the application. See the embedding guide for details. At the end of the guide, there are links to embedding scripts that should be useful in creating a *.exe file with both the Logtalk and Prolog code of your application.

[pmoura]

P.S. For your use case A), using the swipl_logtalk_qlf.sh shell script to generate a logtalk.qlf file (and possibly also an application.qlf file with main application code) seems to be a good fit. You would just need to make the QLF files available to the users.

[hnbeck]

Hi Paulo,

thanks for the explanations. I can not say that I understand everything completely. qlf is new to me and embedding sounds interesting. I'll read the related section in Logtalk and SWI Prolog documentation. If there are questions left I come back :) :) :)

[hnbeck]

Hi Paulo,

now I've read the embedded tutorial and set up a little Powershell script to do the things suggested in the tutorial: collecting the *.pl files, cat them, take the adapter file, path_core and core, cat them and put them at the end in one pl file. So far so good.
But the resulting pl file don't run with SWI.
Now, first a word to my app. There is:

• psmserver.pl, an very simple SWI Prolog Webserver from the Web tutorial and containing the :-initalisation(server(3000))
• doedel.lgt, a very simply Logtalk object just creating a message. This is only for trying out to integrate sources SWI / logtalk
• loader.lgt which looks like

:- use_module(psmserver)

:- initialization((
logtalk_load(os(loader)),
logtalk_load(optionals(loader)),
logtalk_load(doedel),
logtalk_library_path(psi_logic, D),
os::change_directory(D)
)).

Thats it. The last two lines want to set the working directory.

So if I do all the steps and try running the resulting main.pl (as I called it), no error but the server don't run. If I query "server(3000)" it says unknown procedure server/1 ( but this is defined in psm_server.pl and therefore should not be unknown) .

If I use Logtalk_load(psm_logic(loader), [clean(off)] to get the loaderlgt.pl, then when running main.pl with SWI the message is "there is now library os".

However, in fact I haven't understand some things. When doing that stuff given in the embedding tutorial, where is the entry point in my application if a) a SWI Prolog file ist the "main" or b) if a Logtalk module is the "main"). Do I use the :- initialization/1 or /2 directive... What does a loader file really do? If I do clean(on) then there is no loaderlgtpl, then how the libraries are loaded and the application started?

You see, although the tutorial is written well, but I have some missing pieces in understanding about what's happening the way from mixed Logtalk SWI prolog sources, compiling, library loading on runtime up to the point where the first predicate of my application is executed.
I'm pretty sure that's all not very difficult, so could you help me :)

Cheers

Hans

[pmoura]

I assume you looked into the swipl_logtalk_qlf.sh script (around line 239) to get the concatenation order of the files correct?

[hnbeck]

yep, this is correct, as far as I can see.

[pmoura]

After a nice and productive video-chat, we found that the main issue was the application loader files being included in the embedded application. The swipl_logtalk_qlf.sh script provides an option, -c, that allows the loader files to be included without causing issues when running the embedded application. As the work is being done in this case on Windows 10, which cannot run Bash scripts without additional, third-party software, the solution was to simply delete the Prolog files that resulted from the compilation of the application loader.lgt files before generating the QLF files.

[hnbeck]

Yes, I learned a lot and my problem is solved. Thanks for the time, Paulo ! :)