Not able to call pl_next_solution (Delphi, 64 Bit)

General
1

Hi,

i am trying to get a delphi port of the swi header files and some supporting units in delphi done, the basic idee is to use prolog (and CHR) for business rules.

Up to now, everything runs fine, i can import the dll, i can define and call predicates, either build-in predicates like ‘consult’ or self defined ones.

But i got a problem with the use of pl_open_query / pl_next_solution on predicates with more then one solution.

Opening the query with pl_open_query runs fine, calls to pl_next_solution or pl_close_query will always fail. If i call the same predicate under the same circumstances with pl_call_predicate it works.

The following is just a example for testing, the predicate “weiblich” is defined in the consulted file.

It makes no difference if i call pl_open_foreign_frame() before, it makes no difference if i construct the predicate using pl_pred/pl_new_functor, it makes no difference if i change the definition of qid_t, it makes no difference if i change the definition of pl_open_query or pl_next_solution. I guess i have tested every possible combination, so i have no further idees.

I always got an runtime error during a call to PL_next_solution(query) and/or PL_close_query(query).

/// p is just a wrapper component.

 p.Initialize();
 if p.ConsultFile(edConsultFile.Text) then
  begin
   //frame := PL_open_foreign_frame();
   pred := PL_predicate('weiblich', 1, nil);
   //pred := PL_pred(PL_new_functor(PL_new_atom('weiblich'), 0), nil);
   t := PL_new_term_refs(1);
   pl_put_variable(t);
   query := pl_open_query(NIL, PL_Q_NORMAL, pred,t);
   while CHCK(PL_next_solution(query)) do
    begin

    end;
    pl_close_query(query);
   end;
2

Looks sensible. Ok, there is no need to pass a term_t to PL_open_query() for a predicate without arguments (just pass 0). What runtime error? From Prolog? From Delphi?

3

I got it. Sorry for asking to early, your reply, asking if prolog or delphi makes a run time error, pointed me to the right direction.

I have used a false declaration of qid_t in combination with a failure mixing debug und release code / units.

So thanks

Hans Joerg Vasold

4

Possibly also relevant is this old discussion https://swi-prolog.discourse.group/t/delphi-library-for-swi-prolog/

5

I used parts of the header file translation from the thread you suggested.

Also the false one, where qid_t is translated as longword. a Delphi longword is 4 Byte long on Win32 and Win64, whilst a pointer is 8 byte long on Win64.

It seems that this was the error. It works with the following type declaration, even if i not sure that this is correct from the prolog point of view:

type
//PL_engine_t = ^PL_local_data; ???
PL_engine_t = Pointer;

queryRef = record
engine : PL_engine_t; // engine for the query
offset : LongWord; // queryFrame offset in local stack */
end;

QID_T = ^queryRef; // so qid_t is just a pointer

Within the next days or maybe a week, i will make my sources available to the public on github.

cu Ha Joe

1 Like
6

Except status codes, etc, all data oriented types are either pointers or pointer-sided integers (intptr_t in C jargon).