headers
Nicolas Pelletier | 7 Oct 15:24

Tail call optimisation

Hello,

I am using SWI 5.6.61 on Linux and am wondering, out of curiosity, how
I can verify that the compilation of a predicate leads to a tail call
optimized blurb of code. Is there already such a thing in SWI ?

Regards,

--

-- 
Nicolas
_______________________________________________
SWI-Prolog mailing list
SWI-Prolog <at> iai.uni-bonn.de
https://mailbox.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog
Permalink | Reply | 0 comments |
headers
Günter Kniesel | 7 Oct 14:20

Inconsistent display of variable bindings in visual debugger


I just noted that the visual debugger displays different names for
the same internal variable in its "normal" binding view and in the "detail
binding view" that appears when double-klicking one of the bindings.
For instance, in the attached screenshot, _G4968, which appears in
both arguments, changes to two different names in the detail view
of each argument. The screenshot shows that in the detail view for
the first argument, _G4968 is displayed as _G1486.

This behaviour can be quite confusing. Worse, it might lead to errors.
When using the detail view to access large values and to assemble
a test call that exposes a problem, the consistency of variables
shared among the bindings will be lost. For instance, replacement
of _G4968 by two different variables, say A and C, leads to

  Arg1 = calls(a2,A), Arg2 = (f=B, C=D, ...), testcall(Arg1,Arg2).
                  ^                ^
instead of

  Arg1 = calls(a2,A), Arg2 = (f=B, A=D, ...), testcall(Arg1,Arg2).
                  ^                ^
Is this possibly a result of a recent change? I am pretty sure
that I used to cut and paste large values from detail views in
order to create test cases for identified bugs. Or did it only
work by accident because the different bindings didn't share any
variables?

Could this be changed (back) in a future release?

-- Günter
(Continue reading)

Permalink | Reply | 0 comments |
headers
Florian Pommmerening | 6 Oct 14:56

[JPL] Reset Prolog session

Hi all,

I read in the chanegelog that one can initialize JPL only once to avoid inconsistencies. My problem is that a
prolog program I'm trying to use from Java works only once per session. I'm trying to fix this bug at its
source of course but this is not my code and debugging foreign code is ... well lets just say I'm looking for a
workaround in case I cannot find a way to fix this bug. 

Is there any way to start a new prolog session with JPL?
Are there other possibilities to reset prolog? (I tried retractall(x(_)) for every dynamic x but it did not help)

thanks
Florian
--

-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
_______________________________________________
SWI-Prolog mailing list
SWI-Prolog <at> iai.uni-bonn.de
https://mailbox.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog
Permalink | Reply | 2 comments |
headers
Jan Wielemaker | 5 Oct 17:37

Re: 5.7.X : problem with attributed variables and memberchk ?

On Sunday 05 October 2008 17:14:47 Bart Demoen wrote:
> > "_ = something" is simply replaced by `true'.
> > I'm still considering GCC-like warnings here, such as
> >
> >     'Goal has no effect'
> >     'Goal always fails'
>
> I had the message "Stupid unification" in the BIM-Prolog compiler long
> ago. Just before shipping it to customers, someone would replace it
> with something more gentle because it upset the customers :-)

The SWI-Prolog customers don't pay, but still I prefer to be a bit more
polite :-)

> I think that flagging such code is a really nice thing, because it
> almost always is due to typos.
>
> Don't stop there though - flag first occurrences of variables in
> arithmetic expressions, uses of functor/3 with a non-integer in third
> argument, ..., and look (at compile time) inside what is asserted,
> meta-called, etc.

The interesting question of course is, what is better left to a type
checker and what is better done by the compiler? Your functor/3 example
appears to be as a clear example of an issue for the type checker.

Of course, "_ = something" is not a type error, so at least strickly
speaking it isn't the domain of the type checker. It could still be
argued it must be the responsibility of some sort of static analysis
tool outside the compiler proper. On the other hand, the compiler does a
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jan Wielemaker | 5 Oct 13:30

Re: 5.7.X : problem with attributed variables and memberchk ?

Hi Ulrich,

On Sunday 05 October 2008 02:01:33 Ulrich Neumerkel wrote:
> The current bug is that a syntactically failing unification still
> invokes accumulated unification-hooks in stead of failing.
>
> Sometimes this works, and sometimes not.
>
> g3> /opt/gupu/pl-57x/bin/pl -f none
> Welcome to SWI-Prolog (Multi-threaded, 64 bits, Version 5.7.1-46-g32a4502)
> ...
> ?- put_attr(V1,user,10),(V1,4)=(0,1).
> ERROR: uhook/3: Undefined procedure: attr_unify_hook/2

Is this a bug? Nobody says it is not allowed to call the wakeup in the
middle of a unify. I think implementations are allowed to do many things
with this code, including replacing it by 'fail'. SWI-Prolog 5.7 already
does a few of these. E.g. "_ = something" is simply replaced by `true'.
I'm still considering GCC-like warnings here, such as

    'Goal has no effect'
    'Goal always fails'

That was my first intuition and I still think that is a valid
observation, but a little digging showed this should not be the case
here and the bug was diagnosed as an error due to changes of handling
the wakeup list. Only applies to 5.7.x. Fixed.

	Cheers --- Jan
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jan Wielemaker | 5 Oct 12:07

Re: 5.7.X : problem with attributed variables and memberchk ?

On Saturday 04 October 2008 22:08:59 Bart Demoen wrote:
> > ?- A in 0..5, B in 6..7, memberchk(A, [B, C]).
> > false.
> >
> >
> > Shouldn't the last one return :
> > A = C,
> > C in 0..5,
> > B in 6..7.
> >
> > ?
>
> First a look at:
>
>        ?- help(memberchk).
>        memberchk(?Elem, +List)
>            Equivalent to member/2, but leaves no choice point.
>
> This is enough to answer your question: yes, you are correct about
> your expectation.
>
> In fact, the implementation of pl_memberchk in pl-list.c cuts the
> choicepoint before executing woken goals. It is a bit tricky to get
> this correct (from within C), but currently it doesn't deliver what
> the manual promises I think. If memchk/2 is written in Prolog, you get
> what you expect.

Thanks Bart. There is a call foreignWakeup() that executes delayed calls
and can be used (only) at places where C code is about to do something
that is effectively a cut. Also used by (e.g.) \=. Fixed in 5.6.x and
(Continue reading)

Permalink | Reply | 0 comments |
headers
Victor NOEL | 5 Oct 12:03

Re: 5.7.X : problem with attributed variables and memberchk ?

On Sun, Oct 05, 2008 at 08:39:53AM +0200, Bart Demoen wrote:
> 
> Which version of SWI are you using ?
> Your queries give the expected results in Version 5.6.50.

It is written in the title : 5.7.X git (5.7.1-46-g32a4502-DIRTY)

:)

Victor
Permalink | Reply | 0 comments |
headers
Victor NOEL | 5 Oct 00:21

Re: 5.7.X : problem with attributed variables and memberchk ?

On Sat, Oct 04, 2008 at 10:08:59PM +0200, Bart Demoen wrote:
> 
> > ?- A in 0..5, B in 6..7, memberchk(A, [B, C]).
> > false.
> > 
> > 
> > Shouldn't the last one return :
> > A = C,
> > C in 0..5,
> > B in 6..7.
> > 
> > ?
> 
> First a look at:
> 
>        ?- help(memberchk).
>        memberchk(?Elem, +List)
>            Equivalent to member/2, but leaves no choice point.
> 
> This is enough to answer your question: yes, you are correct about
> your expectation.
> 
> In fact, the implementation of pl_memberchk in pl-list.c cuts the
> choicepoint before executing woken goals. It is a bit tricky to get
> this correct (from within C), but currently it doesn't deliver what
> the manual promises I think. If memchk/2 is written in Prolog, you get
> what you expect.

I come back on this, I think it is is more complex than just
a pl_memberchk problem.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Victor NOEL | 4 Oct 22:46

Re: 5.7.X : problem with attributed variables and memberchk ?

On Sat, Oct 04, 2008 at 10:08:59PM +0200, Bart Demoen wrote:
> 
> > ?- A in 0..5, B in 6..7, memberchk(A, [B, C]).
> > false.
> > 
> > 
> > Shouldn't the last one return :
> > A = C,
> > C in 0..5,
> > B in 6..7.
> > 
> > ?
> 
> First a look at:
> 
>        ?- help(memberchk).
>        memberchk(?Elem, +List)
>            Equivalent to member/2, but leaves no choice point.
> 
> This is enough to answer your question: yes, you are correct about
> your expectation.
> 
> In fact, the implementation of pl_memberchk in pl-list.c cuts the
> choicepoint before executing woken goals. It is a bit tricky to get
> this correct (from within C), but currently it doesn't deliver what
> the manual promises I think. If memchk/2 is written in Prolog, you get
> what you expect.
> 
> How did you find this bug ?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Victor NOEL | 4 Oct 21:24

5.7.X : problem with attributed variables and memberchk ?

Hello, I found something strange, I am wondering if there isn't a
problem with attributed variables (at least clpfd ones) and
memberchk (and maybe other predicates ...).

I am using current git for 5.7.X swi-prolog, and if I run the
following commands, this is the results I get :

Welcome to SWI-Prolog (Multi-threaded, 32 bits, Version
5.7.1-31-g8d293e0-DIRTY)
Copyright (c) 1990-2008 University of Amsterdam.
SWI-Prolog comes with ABSOLUTELY NO WARRANTY. This is free
software,
and you are welcome to redistribute it under certain conditions.
Please visit http://www.swi-prolog.org for details.

?- use_module(library(clpfd)).
%  library(error) compiled into error 0.00 sec, 9,704 bytes
% library(clpfd) compiled into clpfd 0.05 sec, 220,728 bytes
true.

?- A in 0..5, B in 6..7, member(A, [B, C]).
A = C,
C in 0..5,
B in 6..7 ;
false.

?- A in 0..5, B in 6..7, memberchk(A, [B, C]).
false.

Shouldn't the last one return :
(Continue reading)

Permalink | Reply | 0 comments |
headers
HeavyDelta | 2 Oct 07:37

List of Predicates... help


So I'm completely new to Prolog and am coding a shift reduce parser. My first
step is to transform a list of tokens...

[1,+,2,*,3]

into a more meaningful list of predicates (called compound terms??)

[term(int,1), term(plus,_), term(int,2), term(times,_), term(int,3)]

After 15 hours of staring at a blank screen, I produced this, which seems to
work.

term(int,A) :- number(A).
term(plus,A) :- A = '+'.
term(times,A) :- A = '*'.
transform(T,A) :- term(T,A).
map([],[]).
map([A|B],[X|C]) :- map(B,C),transform(T,A),X = term(T,A).

eg.
map([1,+,2,*,3], X).
X = [term(int,1), term(plus,_), term(int,2), term(times,_), term(int,3)].

My problem is that (I think) each element in the list is really just an
atom/string to Prolog instead of a predicate... does that make sense?

I tried replacing "X = term(T,A)". with "X is term(T,A)" (I don't even know
the difference) but then it says "term is not a function you woodpecker!!"
(Continue reading)

Permalink | Reply | 0 comments |

Gmane