I can't reproduce in v3.1.24-268-gb14042e (current tip of iss45). You're testing a version built 2 commits behind, with a dirty copy of 46a7be3 -- maybe just a local bug? Maybe try a clean build.

from alsprolog.

Something�s odd. I did a pull of iss45 before starting to work, and distclean, etc.
Here I do it again:
KB-SSD > git branch
alsdev-savprj
cmd-s-file

• iss45
  master
  origin
  pst1
  KB-SSD > git pull origin iss45
  From https://github.com/AppliedLogicSystems/ALSProlog
  • branch iss45 -> FETCH_HEAD
    Already up-to-date.

KB-SSD > git status
On branch iss45
Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git checkout -- ..." to discard changes in working directory)

modified:   ../core/alsp_src/builtins/blt_shl.pro     [one whitespace change]
modified:   ../core/alsp_src/builtins/debugger.pro    [pbi_writes looking for the problem]
modified:   ../examples/visual/twigs.ppj          [irrelevant]

KB-SSD > pwd
/Users/ken/ALS/GitHub/ALSProlog/unix
KB-SSD > make distclean
���
KB-SSD > make
���
./build_dist.sh standard

In ALSProlog/core/unix/darwin:
KB-SSD > alsdev

ALS Prolog (Threaded) Version v3.1.24-268-gb14042e-dirty [darwin]
Copyright (c) 1987-2015 Applied Logic Systems, Inc.

?- assert(a(1)).

yes.

?- spy(a/1).
Error: Instantiation error.

• Goal: builtins:functor(_A,_B,_C)
• Throw pattern: error(instantiation_error,[builtins:functor(_A,_B,_C)])

?-

Weird.
�Ken

On May 17, 2016, at 6:31 PM, Chuck Houpt [email protected] wrote:

I can't reproduce in v3.1.24-268-gb14042e (current tip of iss45). Your testing a version built 2 commits behind, with a dirty copy of 46a7be3 -- maybe just a local bug? Maybe try a clean build.

�
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub

from alsprolog.

Unless . is on your PATH, you should run ./alsdev in core/unix/darwin. Could that be the problem?

from alsprolog.

Indeed, . is on my PATH:
PATH=.:$PATH
export PATH
However, running ./alsdev in ~ALSProlog/core/unix/darwin (where I�ve been working) produces the same problem.
I haven�t narrowed it down yet, but I suspect the issue has to do with the fact that the asserted predicate doesn�t have an associated file from which a source trace can be displayed.
�Ken

On May 18, 2016, at 4:47 AM, Chuck Houpt [email protected] wrote:

Unless . is on your PATH, you should run ./alsdev in core/unix/darwin. Could that be the problem?

�
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub

from alsprolog.

The local changes are a possible source of the problem, you might git stash them and rebuild to test the problem without local modifications.

from alsprolog.

Nope. I opted for a clean clone in a new folder:

/Users/ken/ALS/GitHub/2ndALSClone
KB-SSD > git clone https://github.com/AppliedLogicSystems/ALSProlog.git
Cloning into 'ALSProlog'...
remote: Counting objects: 18361, done.
remote: Compressing objects: 100% (96/96), done.
remote: Total 18361 (delta 57), reused 0 (delta 0), pack-reused 18265
Receiving objects: 100% (18361/18361), 17.19 MiB | 159.00 KiB/s, done.
Resolving deltas: 100% (11591/11591), done.
Checking connectivity... done.

KB-SSD > git branch -r
origin/HEAD -> origin/master
origin/alsdev-savprj
origin/gh-pages
origin/iss45
origin/master
origin/thread_branch

KB-SSD > git fetch
KB-SSD > git checkout iss45
Branch iss45 set up to track remote branch iss45 from origin.
Switched to a new branch 'iss45'

cd /Users/ken/ALS/GitHub/2ndALSClone/ALSProlog/unix
KB-SSD > make
��

KB-SSD > cd core/unix/darwin/

KB-SSD > ./alsdev

Same behavior:

ALS Prolog (Threaded) Version v3.1.24-268-gb14042e [darwin]
Copyright (c) 1987-2015 Applied Logic Systems, Inc.

?- assert(a(9)).

yes.

?- spy(a/1).
Error: Instantiation error.

• Goal: builtins:functor(_A,_B,_C)
• Throw pattern: error(instantiation_error,[builtins:functor(_A,_B,_C)])

?-

��Ken

On May 18, 2016, at 10:16 AM, Chuck Houpt [email protected] wrote:

The local changes are a possible source of the problem, you might git stash them and rebuild to test the problem without local modifications.

�
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub

from alsprolog.

Just to be sure, I created a 3rd new clone from the repo.
Without doing anything else, on master, I did a make in ALSProlog/unix.

Then I opened another window in ALSProlog/core/unix/darwin, and executed ./alsdev
and got the same behavior, so it has nothing to do with iss45 or anything local:

ALS Prolog (Threaded) Version v3.1.24-268-ge2ed93c [darwin]
Copyright (c) 1987-2015 Applied Logic Systems, Inc.

?- assert(a(9)).

yes.

?- spy(a/1).
Error: Instantiation error.

• Goal: builtins:functor(_A,_B,_C)
• Throw pattern: error(instantiation_error,[builtins:functor(_A,_B,_C)])

?-

��Ken

On May 18, 2016, at 10:16 AM, Chuck Houpt [email protected] wrote:

The local changes are a possible source of the problem, you might git stash them and rebuild to test the problem without local modifications.

�
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub

from alsprolog.

Does the error occurs with alspro? In alsdev, spy will normally open the debugger window for output. Can you open it manually? Maybe bad data in the prefs ~/.alsdev?

from alsprolog.

On May 18, 2016, at 12:43 PM, Chuck Houpt [email protected] wrote:

Does the error occurs with alspro?

No

In alsdev, spy will normally open the debugger window for output. Can you open it manually?

Yes; open/closed doesn�t matter

Maybe bad data in the prefs ~/.alsdev?

Pretty sure not.
Pretty sure the bug lies in the clause group machinery.

�
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub

from alsprolog.

You might try in Linux VM to verify. I can't reproduce on darwin or linux.

from alsprolog.

ubuntu � same as darwin.
However, win32 doesn�t throw the error. [It does write the �Spy point �� in the debugger win instead of the console].
I�ll have to sort out the path taken in win32.
I found the place where darwin/ubuntu die: it�s trying to find
builtins:file_clause_group(BaseFileName, ClauseGroup)
given ClauseGroup = 255, which is assigned to a/1 in all of the systems.
But that file_clause_group fact doesn�t exist, even on win32.
{It�s auto created by normal consult.}
Clearly win32 is not going thru that same other path.

On May 18, 2016, at 1:11 PM, Chuck Houpt [email protected] wrote:

You might try in Linux VM to verify. I can't reproduce on darwin or linux.

�
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub

from alsprolog.

When I use spy on alsdev, the only file clause group created is for arithx1:

- builtins:file_clause_group(X,Y).
no.

?- spy(a/1).
yes.

?- builtins:file_clause_group(X,Y).
X='/usr/local/Cellar/als-prolog/HEAD/als-prolog/alsdir/library/arithx1.pro' 
Y=16 

from alsprolog.

That�s an artifact. If you consult files, you get file_clause_groups.

On May 18, 2016, at 1:50 PM, Chuck Houpt [email protected] wrote:

When I use spy on alsdev, the only file clause group created is for arithx1:

• builtins:file_clause_group(X,Y).
  no.

?- spy(a/1).
yes.

?- builtins:file_clause_group(X,Y).
X='/usr/local/Cellar/als-prolog/HEAD/als-prolog/alsdir/library/arithx1.pro'
Y=16

�
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub

from alsprolog.

Letting jj.pro be a file with just:

a(4).

Then on all the systems:

?- [jj].
Attempting to consult jj...
... consulted /Users/ken/ALS/GitHub/ALSProlog/core/unix/darwin/jj.pro

yes.

?- spy(a/1).

yes.

?- builtins:file_clause_group(X,Y).

X=jj
Y=16 ;

X='/Users/ken/ALS/GitHub/ALSProlog/core/unix/darwin/alsdir/library/arithx1.pro'
Y=17 ;

no.

?- a(X).

X=4

yes.

���� On the debugger console, when ?- a(X) is executed:
(1) 1 call: user:a(_7014)
(1) 1 exit: user:a(4)

This is the same for darwin/ubuntu/win32.

Although win32 doesn�t exhibit quite the same error behavior when we assert(a(4)) instead of consulting [jj], it�s also broken: when one executes ?-a(X), that works { X=4 }, BUT there is no trace in the debugger console.

Note that /Users/ken/ALS/GitHub/ALSProlog/core/unix/darwin/alsdirlibrary/arithx1.pro also appears because it�s a library file, and somewhere underneath the spy call, some arithmetic is needed which is implemented in arith1.pro, so that file is consulted.

��Ken

from alsprolog.

However, win32 doesn't throw the error. [It does write the 'Spy point' in the debugger win instead of the console].

This is the correct behavior I see on darwin/ubuntu. All spy output is written to the debugger window.

from alsprolog.

Right, I just confused my memory. Debugger output, even announcements, should go to the debugger console.

from alsprolog.

Asserted facts and clauses are assigned to stream [user], all with clause group 255. The code for spy/[0,1,2], applied to an asserted fact or clause, was not prepared for this. Adjusting that code [on branch issue53] to handle [user],255 has nearly solved the problem, but one issue remains. The initial problem is the failure of
builtins:file_clause_group(BaseFileName, ClauseGroup)
for ClauseGroup = 255, since there is no associated file name. I can /nearly/ make it all work by associating “user” as a value for BaseFileName (but not actually asserting
builtins:file_clause_group(user, 255) )

Ordinary, no-assert:
d(X) :- a(X), e(X).
a(3).
e(3).

When consulted:
?- dblisting.

% user:e/1
e(3).

% user:a/1
a(3).

% user:d/1
d(_A) :-$dbg_aph(16,0,4), $dbg_apg(16,8,12), a(_A), $dbg_apge(16,8,12),
$dbg_apg(16,14,18), e(_A), $dbg_apge(16,14,18), $dbg_aphe(16,0,4).

?- trace d(X).

(1) 1 call: user:d(_7249)
(4) 2 call: user:a(_7249)
(4) 2 exit: user:a(3)
(8) 2 call: user:e(3)
(8) 2 exit: user:e(3)
(1) 1 exit: user:d(3)

X=3

?- spy a/1.

yes.

?- d(X).

1. 1 call: user:a(_7158)
   (1) 1 exit: user:a(3)
   (5) 1 call: user:e(3)
   (5) 1 exit: user:e(3)

X=3

=========== { a(3) not in file, only asserted }

With an assert:
d(X) :- a(X), e(X).
e(3).

When consulted:

?- assert(a(3)).

yes.

?- dblisting.

% user:e/1
e(3).

% user:a/1
a(3).

% user:d/1
d(_A) :-$dbg_aph(16,0,4), $dbg_apg(16,8,12), a(_A), $dbg_apge(16,8,12),
$dbg_apg(16,14,18), e(_A), $dbg_apge(16,14,18), $dbg_aphe(16,0,4).

?- trace d(X).

(1) 1 call: user:d(_7249) ** 2 call: user:a(_7249)
(4) 2 exit: user:a(3)
(7) 2 call: user:e(3)
(7) 2 exit: user:e(3)
(1) 1 exit: user:d(3)

X=3

HOWEVER:

?- spy a/1.

yes.

?- d(X).

(1) 1 call: user:a(_7194)
(1) 1 exit: user:a(3)
(2) 1 call: user:$dbg_apge(16,8,12)
(3) 1 call: user:$dbg_apg(16,14,18)
(4) 1 call: user:e(3)
(5) 2 call: user:$dbg_apf(16,20,24)
(4) 1 exit: user:e(3)
(6) 1 call: user:$dbg_apge(16,14,18)
(7) 1 call: user:$dbg_aphe(16,0,4)

X=3

If you now perform trace d(X), you get the same as [**] above.

Note that the dblisting expressions are identical for the a(3)-in-file and a(3)-not-in-file-but-asserted cases, and that the traces are identical in all cases above.
{Note: Branch issue53 is currently loaded with a bunch of pbi_write/nl for debugging this.}

from alsprolog.

I no longer can reproduce the issue.

from alsprolog.