Hi Jos, Lev, Jonas,
A saved state makes sense for this scenario. Now I do not really
understand what the problem is. The eye package depends on some exact
version of SWI-Prolog, but it is not uncommon for one package to
require some specific version of a library, no?
Is the real problem that we cannot two versions of SWI-Prolog installed
side-by-side, so eye can depend on a specific version? That can be fixed
using -DSWIPL_VERSIONED_DIR=ON to the CMake configure, which installs
swi-prolog in /usr/lib/swi-prolog-<version>. Now we get the problem
that Debian likes -DSWIPL_INSTALL_IN_LIB=ON, installing the shared
object in /usr/lib, but this too should be versioned, no?
The above seems one way out (but probably requires some work). Another
is to have the post-install script of eye create the saved state.
Finally, we could use caching by having eye.sh test for a state at some
cache location (e.g., ~/.cache/swi-prolog/states/eye.pvm) and using this
if available or first call swipl to create the saved state.
Would be nice to have an overall preferred solution for package managers
to deal with SWI-Prolog saved states. I think all three above are
viable, each with pros and cons and no clear winner.
Cheers --- Jan
On 4/28/20 3:11 PM, Jos De Roo wrote:
> Hi Lev,
>
> Yes indeed, eye is using a saved state to have it started 10 times
> faster than normal:
>
> $ time swipl -x /opt/eye/lib/eye.pvm -- --version
> eye --version
> EYE v20.0423.1748 josd
> SWI-Prolog version 8.1.29
> starting 31 [msec cputime] 37 [msec walltime]
>
> real 0m0.041s
> user 0m0.037s
> sys 0m0.004s
>
> $ time swipl -f /opt/eye/src/eye.pl <http://eye.pl> -g main -- --version
> eye --version
> EYE v20.0423.1748 josd
> SWI-Prolog version 8.1.29
> starting 344 [msec cputime] 393 [msec walltime]
>
> real 0m0.401s
> user 0m0.343s
> sys 0m0.015s
>
> and this is quite crucial as eye is typically used as a short running
> process
> which is getting data/rules/query from the web, returning answers/proofs
> for the query and then closing the process as the internal state
(e.g. the
> deductive closure of the forward reasoning run) is of no use to the next
> run.
>
> Kind regards,
> Jos
>
> -- https://josd.github.io/ <http://josd.github.io/>
>
>
> On Tue, Apr 28, 2020 at 1:30 PM Lev Lamberov <dogs...@debian.org
> <mailto:dogs...@debian.org>> wrote:
>
> Вт 28 апр 2020 @ 13:11 Jan Wielemaker <j.wielema...@vu.nl
> <mailto:j.wielema...@vu.nl>>:
>
> > Hi Lev,
> >
> > I most wanted to get Jos in the loop as the developer of eye.
> Packagers
> > working together with developers/maintainers saves a lot of
work :)
>
> Awww... so, CCing Jos De Roo.
>
> Jos, could you be so kind to take a look at the #958561 Debian bug
> report concerning swi-prolog and eye. You can find it there:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958561
>
> > On 4/28/20 12:49 PM, Lev Lamberov wrote:
> >> Hi Jan,
> >>
> >> Вт 28 апр 2020 @ 11:22 Jan Wielemaker <j.wielema...@vu.nl
> <mailto:j.wielema...@vu.nl>>:
> >>
> >>> Hi Lev, Jos,
> >>>
> >>> For Jos, the problem is that eye installs as a SWI-Prolog saved
> state,
> >>> which is highly version dependent and this is difficult to deal
> with
> >>> given the Debian dependency and upgrade policy (Lev, hope this
> is the
> >>> right summary, please correct if not).
> >>>
> >>> I has a little look at eye and I wonder why we need the state.
> eye.pl <http://eye.pl>
> >>> isn't that big and loads in about 0.12 sec on my machine.
> Without a
> >>> state, eye seems to run easily using the simple script
> >>>
> >>> swipl -g main /path/to/eye.pl <http://eye.pl> "$@"
> >>>
> >>> Or by installing eye.pl <http://eye.pl> as the actual
> executable and start is using
> >>>
> >>> #!/bin/env swipl
> >>>
> >>> and use somewhere in the file
> >>>
> >>> :- initialization(main,main).
> >>>
> >>> Would it make sense to go this route? If not, why not? Is the
> >>> somewhat longer startup time an issue?
> >>>
> >>> Thanks --- Jan
> >>
> >> I'm sending your message to the bug report and to Jonas
Smedegaard.
> >> Please, send your further replies to 958...@bugs.debian.org
> <mailto:958...@bugs.debian.org>
> >>
> >> Cheers!
> >> Lev
>
