eclipse-clp-users — ECLiPSe Users List

Re: [eclipse-clp-users] Predicate search/6 over Real Numbers

[<ms...@an...>]

On Sat, 17 Apr 2021, Amine Marref wrote:
> My understanding from this page is that search/6 also works for real values;
> why is search/6 complaining about integer bounds?

I don't think search/6 works for real values.  The page you linked to says
"It can currently be used with either the finite domains (if loaded via
lib(fd_search)), integer IC finite domains, and GFD integer finite domains
(if loaded via lib(gfd_search))."

Reals aren't on that list, and since search/6 depends on indomain/2 -
which only works on finite domain variables - it's reasonable to guess it
wouldn't work on reals.  Maybe at the absolute outside you could implement
your own replacement for indomain/2 and use that as argument 4 of search/6
to do a search on real-valued variables.  But you may also get better
results with locate/4 and friends, which are meant to work with reals.

-- 
Matthew Skala
ms...@an...                 People before tribes.
https://ansuz.sooke.bc.ca/

[eclipse-clp-users] Predicate search/6 over Real Numbers

[Amine M. <ami...@gm...>]

Hello,

I am trying to use search/6 in my CSP but I am getting an "type error in
get_integer_bounds" error.

This is an example that does not do anything particularly useful:
test:-
    Vars = [V1, V2, V3],
    Vars $:: 0.0..100.0,
    V1 $= 5.5,
    search(Vars, 0, largest, indomain_max, complete, []),
    writeln(V1), writeln(V2), writeln(V3).

If I am not asking for too much, my expectation from running this example
is that I get [V1,V2,V3]=[5.5,100,100]. However, search/6 complains about
integer bounds saying "type error in get_integer_bounds(5.5__5.5, _6844,
_6845)".

My understanding from this page
<https://eclipseclp.org/doc/bips/lib/ic/search-6.html> is that search/6
also works for real values; why is search/6 complaining about integer
bounds?

Cheers.
-- 
marref.org

[eclipse-clp-users] Logtalk 3.44.0 released

[Paulo M. <pm...@lo...>]

Hi,

Logtalk 3.44.0 is now available for downloading at:

https://logtalk.org/

This release features new and improved linter checks; adds a new Handbook nomenclature section on the differences between Logtalk and Prolog; adds new Handbook glossary entries; adds libraries for CSV files reading/writing, option handling, and term input/output from/to atoms, chars, and codes; improves existing libraries; provides fixes and improvements for several developer tools; adds a shell script for generating Allure reports from test results; adds support for exporting test result in the xUnit.net v2 XML format; improves exporting of results in the JUnit/xUnit format; includes new and improved programming examples; adds new examples to the ToyCHR port; adds tests sets for the de facto standard hyperbolic arithmetic functions; adds additional tests for several arithmetic functions; adds Windows installer experimental support for creating an integration shortcut for Tau Prolog; updates the macOS installer support for users of the zsh shell; removes support for Qu-Prolog and for the multi-threaded version of XSB; and includes portability updates for LVM, SICStus Prolog, SWI-Prolog, Tau Prolog, Trella ProLog, YAP. For details and a complete list of changes, please consult the release notes at:

https://github.com/LogtalkDotOrg/logtalk3/blob/master/RELEASE_NOTES.md

You can show your support for Logtalk continued development and success at GitHub by giving us a star and a symbolic sponsorship:

https://github.com/LogtalkDotOrg/logtalk3

Happy logtalking!
Paulo

-----------------------------------------------------------------
Paulo Moura
Logtalk developer

Re: [eclipse-clp-users] Question about installation process under Windows

[David <dfk...@gm...>]

All the directories listed above are there, and both the command line and
GUI versions start up without error. Maybe Norton considers adding a URL to
the start menu to be a security risk.

Thanks for your help.

David.

On Sun, Dec 27, 2020 at 1:01 PM Joachim Schimpf <jsc...@co...>
wrote:

> On 25/12/2020 17:25, David wrote:
> > Hi!
> >
> > While installing ECLiPSe (version 7.0 #54 x86_64_nt) on Windows 7 SP 1
> (64 bit), Norton blocked a
> > process being executed by the install program (see attached screen
> print). The installation program
> > itself didn't issue any error messages, however. Can I assume that the
> installation is complete? Do
> > I need to worry about this?
>
> Hi David,
>
> your error message suggests that Norton stopped the ECLiPSe installer from
> creating a Start Menu
> shortcut to the ECLiPSe web site eclipseclp.org, which is strange and has
> never caused a problem
> before.
>
> To see whether the installation otherwise succeeded, you could check both
> the installation
> directory and the start menu directory and see whether all files/dirs are
> there:
>
>   Directory of C:\Program Files\ECLiPSe 7.0
>
> 27/12/2020  17:16    <DIR>          .
> 27/12/2020  17:16    <DIR>          ..
> 27/12/2020  17:16    <DIR>          doc
> 26/02/2020  22:12             1,403 ecl_inst.js
> 27/12/2020  17:15    <DIR>          include
> 27/12/2020  17:15    <DIR>          legal
> 27/12/2020  17:15    <DIR>          lib
> 27/12/2020  17:15    <DIR>          lib_public
> 27/12/2020  17:15    <DIR>          lib_tcl
> 27/12/2020  17:16    <DIR>          man
> 26/02/2020  22:12            13,881 README_WIN.TXT
> 27/12/2020  17:15    <DIR>          tcltk
> 27/12/2020  17:16            95,039 uninst-eclipse.exe
>
>
>   Directory of C:\ProgramData\Microsoft\Windows\Start
> Menu\Programs\ECLiPSe 7.0 (64 bit)
>
> 27/12/2020  17:33    <DIR>          .
> 27/12/2020  17:33    <DIR>          ..
> 27/12/2020  17:16               970 Documentation.lnk
> 27/12/2020  17:16             1,113 DosEclipse.lnk
> 27/12/2020  17:16                47 ECLiPSe Homepage.bak
> 27/12/2020  17:33                48 ECLiPSe Homepage.url
> 27/12/2020  17:16               906 Readme.lnk
> 27/12/2020  17:16             1,312 TkEclipse.lnk
> 27/12/2020  17:16             1,308 TkRemoteTools.lnk
> 27/12/2020  17:16               635 Uninstall ECLiPSe 7.0.lnk
> 27/12/2020  17:21                47 xxx.url
>
>
> If this is all ok, just try starting ECLiPSe from the start menu (as
> TkECLiPSe or DosECLiPSe).  You
> should then get the GUI or the eclipse prompt, respectively.
>
>
> Regards,
> Joachim
>
>
> _______________________________________________
> ECLiPSe-CLP-Users mailing list
> ECL...@li...
> https://lists.sourceforge.net/lists/listinfo/eclipse-clp-users
>

Re: [eclipse-clp-users] Question about installation process under Windows

[Joachim S. <jsc...@co...>]

On 25/12/2020 17:25, David wrote:
> Hi!
> 
> While installing ECLiPSe (version 7.0 #54 x86_64_nt) on Windows 7 SP 1 (64 bit), Norton blocked a 
> process being executed by the install program (see attached screen print). The installation program 
> itself didn't issue any error messages, however. Can I assume that the installation is complete? Do 
> I need to worry about this?

Hi David,

your error message suggests that Norton stopped the ECLiPSe installer from creating a Start Menu 
shortcut to the ECLiPSe web site eclipseclp.org, which is strange and has never caused a problem 
before.

To see whether the installation otherwise succeeded, you could check both the installation 
directory and the start menu directory and see whether all files/dirs are there:

  Directory of C:\Program Files\ECLiPSe 7.0

27/12/2020  17:16    <DIR>          .
27/12/2020  17:16    <DIR>          ..
27/12/2020  17:16    <DIR>          doc
26/02/2020  22:12             1,403 ecl_inst.js
27/12/2020  17:15    <DIR>          include
27/12/2020  17:15    <DIR>          legal
27/12/2020  17:15    <DIR>          lib
27/12/2020  17:15    <DIR>          lib_public
27/12/2020  17:15    <DIR>          lib_tcl
27/12/2020  17:16    <DIR>          man
26/02/2020  22:12            13,881 README_WIN.TXT
27/12/2020  17:15    <DIR>          tcltk
27/12/2020  17:16            95,039 uninst-eclipse.exe


  Directory of C:\ProgramData\Microsoft\Windows\Start Menu\Programs\ECLiPSe 7.0 (64 bit)

27/12/2020  17:33    <DIR>          .
27/12/2020  17:33    <DIR>          ..
27/12/2020  17:16               970 Documentation.lnk
27/12/2020  17:16             1,113 DosEclipse.lnk
27/12/2020  17:16                47 ECLiPSe Homepage.bak
27/12/2020  17:33                48 ECLiPSe Homepage.url
27/12/2020  17:16               906 Readme.lnk
27/12/2020  17:16             1,312 TkEclipse.lnk
27/12/2020  17:16             1,308 TkRemoteTools.lnk
27/12/2020  17:16               635 Uninstall ECLiPSe 7.0.lnk
27/12/2020  17:21                47 xxx.url


If this is all ok, just try starting ECLiPSe from the start menu (as TkECLiPSe or DosECLiPSe).  You 
should then get the GUI or the eclipse prompt, respectively.


Regards,
Joachim

[eclipse-clp-users] Question about installation process under Windows

[David <dfk...@gm...>]

Hi!

While installing ECLiPSe (version 7.0 #54 x86_64_nt) on Windows 7 SP 1 (64
bit), Norton blocked a process being executed by the install program (see
attached screen print). The installation program itself didn't issue any
error messages, however. Can I assume that the installation is complete? Do
I need to worry about this?

Thanks.

[eclipse-clp-users] Logtalk 3.43.0 released

[Paulo M. <pm...@lo...>]

Hi,

Logtalk 3.43.0 is now available for downloading at:

https://logtalk.org/

This release
focus once again on improved testing support and improved test suites for both Logtalk features and Prolog standards compliance of supported backends. It also provides compiler improvements and bug fixes, provides experimental support for Trealla ProLog; updates support for LVM and Tau Prolog; improves the top-level shortcut for loading files; includes a new "git" library; adds new predicates to the "queues" library; provides portability fixes for the "os" library; provides new predicates, improvements, and fixes for the "lgtunit" tool; provides fixes for the "debugger" and "lgtdoc" tools; improves the portability of the "bench" and "metainterpreters" examples; provides UltiSnips support for the Vim text editor, kindly contributed by Paul Brown; and includes other portability updates for most of the supported backends. For details and a complete list of changes, please consult the release
notes at:

https://github.com/LogtalkDotOrg/logtalk3/blob/master/RELEASE_NOTES.md

You can show your support for Logtalk continued development and success at GitHub by giving us a star and a symbolic sponsorship:

https://github.com/LogtalkDotOrg/logtalk3

Happy logtalking!
Paulo

-----------------------------------------------------------------
Paulo Moura
Logtalk developer

Re: [eclipse-clp-users] How to compile for Raspberry Pi 4

[Joachim S. <jsc...@co...>]

On 11/07/2020 11:27, Vasily Kartashov wrote:
> Hello,
> 
> I see a commit hinting that aarch64 is supported, but I cannot find detailed instructions on how to compile eclipse on Raspberry Pi 4.


Hi Vasily,

The default Raspberry Pi OS is still a 32-bit operating system.
It corresponds to the ECLiPSe 'armv7_linux' architecture, for
which you can find binaries at our various download sites via
http://eclipseclp.org/download.html

This should work on both the Pi 3 and Pi 4.

There exists a Beta 64-bit Raspberry Pi OS, which I am currently trying.
ECLiPSe's architecture name for this is going to be 'aarch64_linux'.
It seems to build there without problems, but some some small
configuration updates are required, which I'll publish soon.

All the best,
Joachim

[eclipse-clp-users] How to compile for Raspberry Pi 4

[Vasily K. <in...@ka...>]

Hello,

I see a commit hinting that aarch64 is supported, but I cannot find detailed instructions on how to compile eclipse on Raspberry Pi 4.

Thanks,
Vasily

[eclipse-clp-users] Logtalk 3.38.0 released

[Paulo M. <pm...@lo...>]

Hi,

Logtalk 3.38.0 is now available for downloading at:

https://logtalk.org/

This release adds a new lint check for non-tail recursive predicate definitions, improves the lint checks for deprecated predicates, includes fixes and improvements for the "arbitrary" library category, implements several new QuickCheck options, simplifies error handling and reporting for the QuickCheck predicates and test dialects, improves the documentation of several developer tools, improves the usability of the SVG diagrams generated by the "diagrams" tool by adding CSS support, and updates support for the Kate text editor. For details and a complete list of changes, please consult the release notes at:

https://github.com/LogtalkDotOrg/logtalk3/blob/master/RELEASE_NOTES.md

You can show your support for Logtalk continued development and success at GitHub by giving us a star and a symbolic sponsorship:

https://github.com/LogtalkDotOrg/logtalk3

Happy logtalking!
Paulo

-----------------------------------------------------------------
Paulo Moura
Logtalk developer

[eclipse-clp-users] Property-based testing

[Paulo M. <pm...@lo...>]

Hi,

I published yesterday the third blog post on property-based testing. The solutions discussed in the posts can be used to test, besides Logtalk code, also plain Prolog and Prolog module code:

https://logtalk.org/2020/04/23/building-trust-on-property-based-testing.html

The blog is focused on logic programming best practices. Hope you enjoy reading it. Feedback and suggestions for upcoming content are most welcome.

Cheers,
Paulo

-----------------------------------------------------------------
Paulo Moura
Logtalk developer

[eclipse-clp-users] Logtalk 3.37.0 released

[Paulo M. <pm...@lo...>]

Hi,

Logtalk 3.37.0 is now available for downloading at:

https://logtalk.org/

This release adds a new meta-message to the message printing mechanism, allows the "user" pseudo-object to be used as an event monitor, fixes a reflection API bug that could result in duplicated or redundant entity operator properties, improves support for compiling modules as objects, includes significant updates to the Handbook with new and improved sections, includes new and improved glossary entries, provides new library hook objects, adds and improves notes on applying the developer tools to Prolog codebases, improves the "lgtunit" tool automation support, adds a simple example of Aspect-Oriented Programming using hot patching and event-driven programming support, and provides updated support for SWI-Prolog and YAP. For details and a complete list of changes, please consult the release notes at:

https://github.com/LogtalkDotOrg/logtalk3/blob/master/RELEASE_NOTES.md

You can show your support for Logtalk continued development and success at GitHub by giving us a star and a symbolic sponsorship:

https://github.com/LogtalkDotOrg/logtalk3

Happy logtalking!
Paulo

-----------------------------------------------------------------
Paulo Moura
Logtalk developer

Re: [eclipse-clp-users] Propagation question for IC

[Joachim S. <jsc...@co...>]

There is already a solution for this on the ECLiPSe web site
http://eclipseclp.org/examples/dmc_challenge_2019_sep.ecl.txt

It does not solve by propagation alone either, probably for
the reason you have discovered yourself.

Regards,
Joachim


On 01/04/2020 10:34, Panagiotis Stamatopoulos wrote:
> Thank you very much for your reply, Joachim!
> 
> Actually, the origin of my question is a puzzle I was trying to solve:
> https://alexis.lindaikejisblog.com/photos/shares/5d56b650ce177.jpg
> 
> I wanted to stick to IC, as I intended to use it for a course I teach.
> In addition, I wanted to get the answer just by propagation, without
> any labeling, as the puzzle can be solved just by logical inferences.
> Following your suggestion to use the reified form of #::, I ended with
> the program that follows. Do you believe that there could be a better
> solution, as far as readability is concerned (and advertisement of the
> advantages of CLP)? Anyway, this program works fine.
> Thank you very much, again.
> 
>       Takis
> 
> -------------------------------------------------------------------------
> 
> :- lib(ic).
> 
> code(X1, X2, X3) :-
>     [X1, X2, X3] #:: 0..9,
>     corcor(X1, X2, X3, 6, 8, 2, 1),
>     corwro(X1, X2, X3, 6, 1, 4, 1),
>     corwro(X1, X2, X3, 2, 0, 6, 2),
>     corcor(X1, X2, X3, 7, 3, 8, 0),
>     corwro(X1, X2, X3, 7, 3, 8, 0),
>     corwro(X1, X2, X3, 7, 8, 0, 1).
> 
> /* corcor/7: N is the number of correct and well placed
>   * digits of code X1/X2/X3 compared to N1/N2/N3 */
> 
> corcor(X1, X2, X3, N1, N2, N3, N) :-
>     #::(X1, N1, B1),
>     #::(X2, N2, B2),
>     #::(X3, N3, B3),
>     N #= B1 + B2 + B3.
> 
> /* corwro/7: N is the number of correct but wrongly placed
>   * digits of code X1/X2/X3 compared to N1/N2/N3 */
> 
> corwro(X1, X2, X3, N1, N2, N3, N) :-
>     #::(X1, [N2, N3], B1),
>     #::(X2, [N1, N3], B2),
>     #::(X3, [N1, N2], B3),
>     N #= B1 + B2 + B3.
> 
> -------------------------------------------------------------------------
> 
> On 01-Apr-20 11:20 AM, Joachim Schimpf wrote:
>> On 31/03/2020 19:22, Panagiotis Stamatopoulos wrote:
>>> Hello All,
>>>
>>> I hope you are healthy and safe. May I ask a (maybe trivial) question
>>> in the context of the IC library? Why the query
>>>
>>> ?- X #:: [1, 3], B #= (X #= 2).
>>> X = X{[1, 3]}
>>> B = B{[0, 1]}
>>> There is 1 delayed goal.
>>>
>>> does not enforce Β to be equal to 0?
>>
>>
>> IC's arithmetic equality and inequality constraints generally
>> enforce bounds-consistency, that's why the hole in the domain
>> of X is not taken into account.
>>
>> On could argue that for simple cases like X #= Y+Const stronger
>> domain-consistency should be enforced, this is the reason for
>> having http://eclipseclp.org/doc/bips/lib/ic/ac_eq-3.html .
>> Unfortunately, a reified version of ac_eq/3 is missing!
>>
>> If, as in your example, the equation contains only one variable,
>> you could use the reified form of #::, i.e.
>>
>> ?- X #:: [1, 3], #::(X, 2, B).
>> X = X{[1, 3]}
>> B = 0
>>
>>
>> By the way, lib(gfd) also does what you expect:
>>
>> ?- lib(gfd).
>>
>> ?- X #:: [1, 3], B #= (X #= 2).
>> X = X{[1, 3]}
>> B = 0
>>
>>
>> Cheers,
>> Joachim

Re: [eclipse-clp-users] Propagation question for IC

[Panagiotis S. <ta...@di...>]

Thank you very much for your reply, Joachim!

Actually, the origin of my question is a puzzle I was trying to solve:
https://alexis.lindaikejisblog.com/photos/shares/5d56b650ce177.jpg

I wanted to stick to IC, as I intended to use it for a course I teach.
In addition, I wanted to get the answer just by propagation, without
any labeling, as the puzzle can be solved just by logical inferences.
Following your suggestion to use the reified form of #::, I ended with
the program that follows. Do you believe that there could be a better
solution, as far as readability is concerned (and advertisement of the
advantages of CLP)? Anyway, this program works fine.
Thank you very much, again.

      Takis

-------------------------------------------------------------------------

:- lib(ic).

code(X1, X2, X3) :-
    [X1, X2, X3] #:: 0..9,
    corcor(X1, X2, X3, 6, 8, 2, 1),
    corwro(X1, X2, X3, 6, 1, 4, 1),
    corwro(X1, X2, X3, 2, 0, 6, 2),
    corcor(X1, X2, X3, 7, 3, 8, 0),
    corwro(X1, X2, X3, 7, 3, 8, 0),
    corwro(X1, X2, X3, 7, 8, 0, 1).

/* corcor/7: N is the number of correct and well placed
  * digits of code X1/X2/X3 compared to N1/N2/N3 */

corcor(X1, X2, X3, N1, N2, N3, N) :-
    #::(X1, N1, B1),
    #::(X2, N2, B2),
    #::(X3, N3, B3),
    N #= B1 + B2 + B3.

/* corwro/7: N is the number of correct but wrongly placed
  * digits of code X1/X2/X3 compared to N1/N2/N3 */

corwro(X1, X2, X3, N1, N2, N3, N) :-
    #::(X1, [N2, N3], B1),
    #::(X2, [N1, N3], B2),
    #::(X3, [N1, N2], B3),
    N #= B1 + B2 + B3.

-------------------------------------------------------------------------

On 01-Apr-20 11:20 AM, Joachim Schimpf wrote:
> On 31/03/2020 19:22, Panagiotis Stamatopoulos wrote:
>> Hello All,
>>
>> I hope you are healthy and safe. May I ask a (maybe trivial) question
>> in the context of the IC library? Why the query
>>
>> ?- X #:: [1, 3], B #= (X #= 2).
>> X = X{[1, 3]}
>> B = B{[0, 1]}
>> There is 1 delayed goal.
>>
>> does not enforce Β to be equal to 0?
> 
> 
> IC's arithmetic equality and inequality constraints generally
> enforce bounds-consistency, that's why the hole in the domain
> of X is not taken into account.
> 
> On could argue that for simple cases like X #= Y+Const stronger
> domain-consistency should be enforced, this is the reason for
> having http://eclipseclp.org/doc/bips/lib/ic/ac_eq-3.html .
> Unfortunately, a reified version of ac_eq/3 is missing!
> 
> If, as in your example, the equation contains only one variable,
> you could use the reified form of #::, i.e.
> 
> ?- X #:: [1, 3], #::(X, 2, B).
> X = X{[1, 3]}
> B = 0
> 
> 
> By the way, lib(gfd) also does what you expect:
> 
> ?- lib(gfd).
> 
> ?- X #:: [1, 3], B #= (X #= 2).
> X = X{[1, 3]}
> B = 0
> 
> 
> Cheers,
> Joachim
> 
> 
> _______________________________________________
> ECLiPSe-CLP-Users mailing list
> ECL...@li...
> https://lists.sourceforge.net/lists/listinfo/eclipse-clp-users

Re: [eclipse-clp-users] Propagation question for IC

[Joachim S. <jsc...@co...>]

On 31/03/2020 19:22, Panagiotis Stamatopoulos wrote:
> Hello All,
> 
> I hope you are healthy and safe. May I ask a (maybe trivial) question
> in the context of the IC library? Why the query
> 
> ?- X #:: [1, 3], B #= (X #= 2).
> X = X{[1, 3]}
> B = B{[0, 1]}
> There is 1 delayed goal.
> 
> does not enforce Β to be equal to 0?


IC's arithmetic equality and inequality constraints generally
enforce bounds-consistency, that's why the hole in the domain
of X is not taken into account.

On could argue that for simple cases like X #= Y+Const stronger
domain-consistency should be enforced, this is the reason for
having http://eclipseclp.org/doc/bips/lib/ic/ac_eq-3.html .
Unfortunately, a reified version of ac_eq/3 is missing!

If, as in your example, the equation contains only one variable,
you could use the reified form of #::, i.e.

?- X #:: [1, 3], #::(X, 2, B).
X = X{[1, 3]}
B = 0


By the way, lib(gfd) also does what you expect:

?- lib(gfd).

?- X #:: [1, 3], B #= (X #= 2).
X = X{[1, 3]}
B = 0


Cheers,
Joachim

[eclipse-clp-users] Propagation question for IC

[Panagiotis S. <ta...@di...>]

Hello All,

I hope you are healthy and safe. May I ask a (maybe trivial) question
in the context of the IC library? Why the query

?- X #:: [1, 3], B #= (X #= 2).
X = X{[1, 3]}
B = B{[0, 1]}
There is 1 delayed goal.

does not enforce Β to be equal to 0?

Best Regards,
Takis

Re: [eclipse-clp-users] link to the "ECLiPSe ELearning Course" not working

[Joachim S. <jsc...@co...>]

On 14/03/2020 14:51, matteob8 via ECLiPSe-CLP-Users wrote:
> Dears,
>      I'm writing about a dead link in the page "ECLiPSe Documentation"
> [http://www.eclipseclp.org/doc/].
>     
>      More precisely the link of "ECLiPSe ELearning Course by Helmut
> Simonis" [http://4c.ucc.ie/~hsimonis/ELearning/index.htm] do not work.
>     
>      Should it point to [http://www.eclipseclp.org/ELearning/] instead?
> 
> 
> Cheers,
> Matteo

Thank you - fixed!

[eclipse-clp-users] link to the "ECLiPSe ELearning Course" not working

[matteob8 <mat...@ya...>]

Dears,
    I'm writing about a dead link in the page "ECLiPSe Documentation" 
[http://www.eclipseclp.org/doc/].
   
    More precisely the link of "ECLiPSe ELearning Course by Helmut
Simonis" [http://4c.ucc.ie/~hsimonis/ELearning/index.htm] do not work.
   
    Should it point to [http://www.eclipseclp.org/ELearning/] instead?


Cheers,
Matteo

[eclipse-clp-users] Logtalk 3.34.0 released

[Paulo M. <pm...@lo...>]

Hi,

Logtalk 3.34.0 is now available for downloading at:

https://logtalk.org/

This release adds support for defining predicate shorthands in "uses/2" and "use_module/2" directives, allows local operators to also be declared in scope directives to simplify compilation of included files, adds support for the legacy Prolog database built-in predicates that take a clause reference argument, improves detection of deprecated Prolog built-in predicates, improves compilation of modules as objects, includes a new and improved Handbook sections, improves "lgtunit" tool documentation and code coverage support, provides an updated "expecteds" library, includes new and updated tests for Prolog built-in predicates, includes new and updated programming examples, updates the Debian installer to define default values for the Logtalk environment variables, and provides updated support for ECLiPSe, SWI-Prolog, and YAP. For details and a complete list of changes, please consult the release notes at:

https://github.com/LogtalkDotOrg/logtalk3/blob/master/RELEASE_NOTES.md

This January makes two years of full time development with 20 releases with significant updates, a new website, and a reactivated tech blog. Your support is key for Logtalk continued development and success. Counting on you. If not already, consider giving us a star and a symbolic sponsorship at GitHub.

Happy logtalking!
Paulo

-----------------------------------------------------------------
Paulo Moura
Logtalk developer

Re: [eclipse-clp-users] BAD_TERMs in the C/C++ interface

[Joachim S. <jsc...@co...>]

On 15/12/2019 03:39, Victor Mataré wrote:
> On Samstag, 14. Dezember 2019 02:21:33 CET Joachim Schimpf wrote:
>> Hello Victor,
>>
>> On 13/12/2019 18:46, Victor Mataré wrote:
>>> I'm making extensive use of the C++ interface, and the aggressive garbage
>>> collection in eclipse-clp is still giving me trouble. So as I understand
>>> it, any term goes BAD after it's been given to the eclipse engine once.
>>>
>>> Now I already have infrastructure in place to deal with that, but in my
>>> control flow it's becoming a huge issue that I never really know whether a
>>> term has gone BAD or not. Is there any way to query whether a certain term
>>> (handle) has already been garbage collected?
>>
>> I'm quite confident that the C++ interface has the functionality to solve
>> your problem in a clean way, no strange workarounds should be necessary.
>>
>>   From what you say, I suspect that you may not be using term references
>> where they are needed.
> 
> It's not that. I don't need persistent term references because I'm not pulling
> information out of the eclipse engine.

You don't need them in principle, but you _do_ need them if you want to reuse 
subterms (such as variables) across invocations of EC_resume().  The rules are 
really quite simple:

  - All EC_words must be considered invalid after an EC_resume()

  - EC_Refs remain valid after EC_resume() (although the term they refer to may 
have changed)

In C++ parlance, you might think of EC_words as raw pointers, and of EC_refs as 
smart pointers.


In your case, you seem to repeatedly construct terms and invoke EC_resume(). 
Because you don't _need_ to share variables between the constructed terms, you 
have two choices:

  - you can construct fresh terms each time, and assign them either to your old 
invalid EC_words, or to new EC_words.  [I think this is what you are doing now]

  - you can choose to reuse old subterms, but then you must assign them to 
EC_refs to carry them across invocations of EC_resume()


> In the part I'm talking about, I'm
> basically just using compile_term/1 to "compile" a C++ object structure into a
> bunch of prolog clauses. The problem is that some of those C++ objects
> represent variables that are referenced in other objects (i.e. they are not
> singleton variables).
> 
> So I can't simply re-initialize the variable terms whenever they're referenced
> because that would make them singletons. I've now resorted to initializing
> these variable terms once before building a term or clause that has variables,
> but that is error prone because I didn't expect to have that problem when I
> designed the control flow.
> 
> Now that I think of it, some clearer documentation might have helped me in the
> beginning. There is just this rather vague half-sentence in the Embedding and
> Interfacing Manual:
> 
> "terms do not survive the execution of ECLiPSe"
> 
> None of these words are really clear. What terms are really affected and how,
> what does "survive" mean and what does "execution" mean?

"Term" has its standard meaning in Prolog/ECLiPSe, namely the universal data 
type (everything is a term: constants, structures and lists, even variables). 
Everything you can assign to an EC_word is a term.

"Execution of ECLiPSe" means passing control to ECLiPSe, either by calling 
EC_resume(), or (in case your code was called from ECLiPSe as an external) by 
returning.

"not survive" means your EC_words may contain nonsense.

The meanings were probably crystal clear to the implementer who once wrote them, 
but less so from a user's perspective ;)


> 
> I think the Embedding Manual should have at least a short section about memory
> management that clearly states what happens. In fact, it should have a big fat
> warning along these lines:
> 
> ==============================================================================
> Every EC_word that has been put into post_goal() is invalid after EC_resume().
> That includes all pieces of complex terms. Putting an invalid EC_word into
> another post_goal() leads to undefined behaviour, which might cause the
> eclipse engine to corrupt data, crash immediately, crash randomly, or to never
> crash.
> ==============================================================================

post_goal() has nothing to do with it, only EC_resume() is important.

The C++ interface is a thin layer on top of the C interface.  It is a low-level 
interface involving pointers etc, and thus of course capable of causing crashes. 
  One could design a safer, less direct, higher-level interface (like the Java 
or TCL one), but that's not what we have here.


> ...
> Hope I did get the problem across ;-)

Sure, I hope I could help a little.


-- Joachim

Re: [eclipse-clp-users] BAD_TERMs in the C/C++ interface

[Victor M. <ma...@fh...>]

On Samstag, 14. Dezember 2019 02:21:33 CET Joachim Schimpf wrote:
> Hello Victor,
> 
> On 13/12/2019 18:46, Victor Mataré wrote:
> > I'm making extensive use of the C++ interface, and the aggressive garbage
> > collection in eclipse-clp is still giving me trouble. So as I understand
> > it, any term goes BAD after it's been given to the eclipse engine once.
> > 
> > Now I already have infrastructure in place to deal with that, but in my
> > control flow it's becoming a huge issue that I never really know whether a
> > term has gone BAD or not. Is there any way to query whether a certain term
> > (handle) has already been garbage collected?
> 
> I'm quite confident that the C++ interface has the functionality to solve
> your problem in a clean way, no strange workarounds should be necessary.
> 
>  From what you say, I suspect that you may not be using term references
> where they are needed.

It's not that. I don't need persistent term references because I'm not pulling 
information out of the eclipse engine. In the part I'm talking about, I'm 
basically just using compile_term/1 to "compile" a C++ object structure into a 
bunch of prolog clauses. The problem is that some of those C++ objects 
represent variables that are referenced in other objects (i.e. they are not 
singleton variables).

So I can't simply re-initialize the variable terms whenever they're referenced 
because that would make them singletons. I've now resorted to initializing 
these variable terms once before building a term or clause that has variables, 
but that is error prone because I didn't expect to have that problem when I 
designed the control flow.

Now that I think of it, some clearer documentation might have helped me in the 
beginning. There is just this rather vague half-sentence in the Embedding and 
Interfacing Manual:

"terms do not survive the execution of ECLiPSe"

None of these words are really clear. What terms are really affected and how, 
what does "survive" mean and what does "execution" mean?

I think the Embedding Manual should have at least a short section about memory 
management that clearly states what happens. In fact, it should have a big fat 
warning along these lines:

==============================================================================
Every EC_word that has been put into post_goal() is invalid after EC_resume(). 
That includes all pieces of complex terms. Putting an invalid EC_word into 
another post_goal() leads to undefined behaviour, which might cause the 
eclipse engine to corrupt data, crash immediately, crash randomly, or to never 
crash.
==============================================================================

At least that is the behaviour I observed so far when I made mistakes with 
this. I assume that the undefined behaviour helps performance, but what would 
also be really useful for debugging these things is a switch that makes it 
crash immediately. Sure, I can design my client application so that it cannot 
happen, but I failed to do that initially because there was neither a fat 
warning nor a fail-fast behavior. It's really a huge pitfall if you're 
designing a larger application.

Hope I did get the problem across ;-)

Best regards & thanks for your helpful support,
Victor

PS: If you look at e.g. SWI Prolog, they expose a GC frame object which makes 
their (also non-trivial) memory management explicit, controllable and 
therefore obvious. Lacking that, I believe one does need very clear 
documentation.

Re: [eclipse-clp-users] BAD_TERMs in the C/C++ interface

[Joachim S. <jsc...@co...>]

Hello Victor,

On 13/12/2019 18:46, Victor Mataré wrote:
> I'm making extensive use of the C++ interface, and the aggressive garbage
> collection in eclipse-clp is still giving me trouble. So as I understand it,
> any term goes BAD after it's been given to the eclipse engine once.
> 
> Now I already have infrastructure in place to deal with that, but in my
> control flow it's becoming a huge issue that I never really know whether a
> term has gone BAD or not. Is there any way to query whether a certain term
> (handle) has already been garbage collected?

I'm quite confident that the C++ interface has the functionality to solve your 
problem in a clean way, no strange workarounds should be necessary.

 From what you say, I suspect that you may not be using term references where 
they are needed.

To give some background: "terms" are always stored and managed by an ECLiPSe 
engine.  When an engine runs, it may (a) attempt to garbage-collect terms, and 
(b) move terms as a side effect of garbage collection.  For that reason, the 
engine must know about any references to terms that you are keeping in your own 
C++ data structures.

The way to do that is to use the EC_ref/EC_refs class: terms assigned to an 
EC_ref/EC_refs will not be garbage collected, and the references will be 
correctly relocated when the term is moved in memory.  In contrast, the EC_word 
class must be considered volatile: the content of an EC_word becomes invalid 
once you pass control to the engine (the reason EC_words exist at all is that 
they have less overhead, and are good enough to hold subterms temporarily while 
constructing or deconstructing complex terms).


That's my best guess without knowing your code.  It would also be helpful to 
know whether you observe this problem already in ECLiPSe 6.1, or whether it is 
new in 7.0.

Cheers,
Joachim

[eclipse-clp-users] BAD_TERMs in the C/C++ interface

[Victor M. <ma...@fh...>]

Hi,

I'm making extensive use of the C++ interface, and the aggressive garbage 
collection in eclipse-clp is still giving me trouble. So as I understand it, 
any term goes BAD after it's been given to the eclipse engine once.

Now I already have infrastructure in place to deal with that, but in my 
control flow it's becoming a huge issue that I never really know whether a 
term has gone BAD or not. Is there any way to query whether a certain term 
(handle) has already been garbage collected?

Thanks in advance,
Victor

[eclipse-clp-users] Logtalk 3.33.0 released

[Paulo M. <pm...@lo...>]

Hi,

Logtalk 3.33.0 is now available for downloading at:

https://logtalk.org/

This release adds make tool support for detecting duplicated library aliases, fixes silent loading of settings files when used to load libraries and tools, updates the documenting tool to list inherited public predicates in entity API documentation, improves tool documentation, adds new library predicates, includes fixes and improvements for libraries and tools, adds new library tests, adds new multi-threading programming examples, adds an example of using the question-asking mechanism, fixes example issues, and provides updated support for ECLiPSe, SICStus Prolog, SWI-Prolog, XSB, and YAP. For details and a complete list of changes, please consult the release notes at:

https://github.com/LogtalkDotOrg/logtalk3/blob/master/RELEASE_NOTES.md

Logtalk marketing and sponsoring goals for the current year include:

- 200 GitHub starts (currently at 153)
- 20 sponsors (currently at 3)

Next January, it will make two years of full time development with 19 releases with significant updates, a new website, and a reactivated tech blog. Your support is key for Logtalk success. Counting on you.

Happy logtalking!
Paulo



-----------------------------------------------------------------
Paulo Moura
Logtalk developer

[eclipse-clp-users] GitHub Actions and Workflows for Logtalk and Prolog repos

[Paulo M. <pm...@lo...>]

Hi,

For the past few weeks, I have been implementing a set of GitHub Actions and Workflows (https://help.github.com/en/github/automating-your-workflow-with-github-actions/about-github-actions) for Logtalk repos, available from:

https://github.com/logtalk-actions

These necessarily include actions for setting up supported backend Prolog compilers. I currently make available actions for setting up ECLiPSe (https://github.com/logtalk-actions/setup-eclipse), GNU Prolog (https://github.com/logtalk-actions/setup-gnu-prolog), and SWI-Prolog (https://github.com/logtalk-actions/setup-swi-prolog) environments.

Also available are some demo repos illustrating the provided workflows (https://github.com/logtalk-actions/workflows). Notably, the "demo" repo (https://github.com/logtalk-actions/demo) shows how to automatically run tests, publish test reports, and regenerate API documentation and diagrams on a push event.

The "setup-eclipse" action (https://github.com/logtalk-actions/setup-eclipse) can also be used for repos that don't make use of Logtalk. The community challenge here is twofold:

- Get users with open source repos into the habit of writing tests and documentation and then benefit from automatically running those tests and regenerating and publishing documentation every time they commit and push a new version.
- Writing and sharing actions and workflows for common usage scenarios.

Feedback and contributions welcome.

Enjoy!
Paulo


-----------------------------------------------------------------
Paulo Moura
Logtalk developer