Re: Modules, include paths, swipl-ld etc

On 01/28/2014 09:47 PM, Kaitain Jones wrote:
> I'm trying to get my head around how SWI gets hold of its modules, both in
> general operation and when compiling a C executable that uses SWI.
>
> Take a case such as the predicate intersection/1. SWI manual says of this:
>
> Availability::-
> use_module(library(lists)<http://www.swi-prolog.org/pldoc/man?section=lists>
> ).(can be autoloaded)
>
> Okay. Now in the REPL it's available immediately. Indeed it seems that
> everything (?) is always available in the REPL. Is this because we don't
> care about memory footprint in the REPL but want to control it in an
> independent program?

The critical word is _autoloading_.  The normal installation will trap
any undefined predicate and compare it to an index of the library. If
found, the library is (silently) loaded and the goal is restarted.  This
of course only works if the library can be found.  This isn't normally the
case if you embed SWI-Prolog.  You can still make this possible however.
Basically, it suffices to make sure that the library is somewhere and that
that there is a rule for the file_search_path(library,Path), pointing to
it.  One way (for development) is to set the environment SWI_HOME_DIR
to point to the installation.  For a real runtime embedding, that is
probably not what you want, but you can still ship code in a library
that can both be loaded using use_module or autoloading. Takes a bit
of a learning curve though.  It was recently raised that the file search
system needs a tutorial.  It is powerful, but not obvious.

> Next: I am trying to have my exe consult files dynamically at runtime,
> including those which make use of (say) intersection/1. However, I can't do
> this right now. (At least, not when using swipl-ld on Linux; I'll come to
> Win32/Visual Studio later.) If I put
>
>      :- use_module(library(lists)).
>
> ...in the .pl file, the exe is having none of it at runtime:
>
>      ERROR: /MyDir/common_scenario_rules.pl:1:
> source_sink `library(lists)' does not exist
>      Warning: /MyDir/common_scenario_rules.pl:1:
> Goal (directive) failed: user:use_module(library(lists))
>
> If I remove that line, though, it (predictably) just fails in another way:
>
>      ERROR: can_traverse_link_between/4: Undefined procedure: intersection/3
>
> Now, I am assuming in the first case that your exe needs to have all the
> modules it will ever need at the time it is compiled, and can't pull them
> in dynamically at runtime, i.e. if you want the lists library, it has to be
> pulled in as part of the swipl-ld compilation process. (Is this correct?) I
> don't really want to do that, though, because I can't use swipl-ld for
> building my Win32 exe in Visual Studio. Ideally I'd like my Linux and Win32
> builds to operate functionally in the same way, i.e. to pull everything in
> dynamically at runtime, which is what I'm doing on Win32. Which brings me
> on to...
>
> On Win32, everything works fine. So far as I can tell, compiling with the
> libswipl.lib and running with the appropriate dlls works out just fine. I
> don't even need to add the use_module directives; all my predicates work
> just fine anyway.
>
> So what's the big difference between how Win32 is working and how my
> Linux/swipl-ld build is working? Is there a way I can get my files  to load
> at runtime without baking the modules in at compile time on Linux?

I think all the above is answered?

> One other complication: I think I am now running with SWI V7 on Windows,
> whereas I am still on 6.6 on Linux. (Is there any way to get 7 on Linux
> without building from sources?)

Dependens on the distro.  For Ubuntu there are PPAs.  For some others there
are some form of development versions too.  Else, there is the source.  It
is quite easy though.  Might take a little time first time, but than you can
upgrade in a few minutes whenever you think it is needed.  The above is not
a V6/7 issue though.

	Cheers ---- Jan

>
> Thanks for any illumination anyone can offer,
>
> KJ
> -------------- next part --------------
> HTML attachment scrubbed and removed
> _______________________________________________
> SWI-Prolog mailing list
> [email protected]
> https://lists.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog
>