SWI-Prolog with C Interface: Debug error

[Elf_XP]

Hello!
I have a great problem with SWI Prolog. So I need some help  
At first, I opened Visual Studio 2008 Command Prompt and entered:
plld -o program.exe source.c source.pl
Then two files have appeared: program.exe and program.exe.manifest
Then I started program.exe.  
So, I have error "Unhandled exception at 0x1000c8f0 in program.exe: 0xC0000005"
Debugging information:
crt0dat.c
"pfbegin: 0x00000001 CXX0030 Error expression cannot be evaluated"

Where did I make bad a break?

Below I add the code of both files:
source.c
source.pl

[Jan Wielemaker-3]

On Sun, 2009-11-01 at 05:19 -0800, Elf_XP wrote:

> Hello!
> I have a great problem with SWI Prolog. So I need some help  :working:
> At first, I opened Visual Studio 2008 Command Prompt and entered:
> plld -o program.exe source.c source.pl
> Then two files have appeared: program.exe and program.exe.manifest
> Then I started program.exe.  
> So, I have error "Unhandled exception at 0x1000c8f0 in program.exe:
> 0xC0000005"
> Debugging information:
> crt0dat.c
> "pfbegin: 0x00000001 CXX0030 Error expression cannot be evaluated"

This seems some Windows error.  No idea.  Maybe something with
manifests?

In addition though, term_t must be declared locally and must
be initialised using PL_new_term_ref() before it can be used.
PL_new_term_ref() can only be called after initializing Prolog.

In 99% of the cases I see it, embedding Prolog in C/C++/... is
not a good idea anyway ...  If your really must, you can create
an executable from Prolog.  If you need something Prolog cannot
do, create a DLL/shared object that provides the missing bits.

        --- Jan

> Where did I make bad a break? :confused:
>
> Below I add the code of both files:
> http://old.nabble.com/file/p26148892/source.c source.c
> http://old.nabble.com/file/p26148892/source.pl source.pl

_______________________________________________
SWI-Prolog mailing list
SWI-Prolog@...
https://mailbox.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog

[j.gressier]

2009/11/1 Jan Wielemaker <J.Wielemaker@...>

On Sun, 2009-11-01 at 05:19 -0800, Elf_XP wrote:
> Hello!
> I have a great problem with SWI Prolog. So I need some help  :working:
> At first, I opened Visual Studio 2008 Command Prompt and entered:
> plld -o program.exe source.c source.pl
> Then two files have appeared: program.exe and program.exe.manifest
> Then I started program.exe.
> So, I have error "Unhandled exception at 0x1000c8f0 in program.exe:
> 0xC0000005"
> Debugging information:
> crt0dat.c
> "pfbegin: 0x00000001 CXX0030 Error expression cannot be evaluated"

This seems some Windows error.  No idea.  Maybe something with
manifests?

In addition though, term_t must be declared locally and must
be initialised using PL_new_term_ref() before it can be used.
PL_new_term_ref() can only be called after initializing Prolog.

In 99% of the cases I see it, embedding Prolog in C/C++/... is
not a good idea anyway ... 

This is a rather alarming piece of news. I'd hate to have 1% chance of being right. I'm using Freepascal and an embedded Prolog in a very comfortable continuum. Absolutely no problem at all after 2 years of enthusiastic and successful development of a large program with a rather sophisticated graphic interface. I'm using swi-prolog, which you probably know. Maybe you were referring to other Prolog implementations... don't tell me I do not understand 99% percent of what I have been doing.

I used Visual Prolog before. I rewrote all the Visual Prolog code in Swi-Prolog (with much ease) . My main concern was about speed and I was wrong.

Best regards
Jacques Gressier
http://geometrix.free.fr/geom3exos/telechg.htm










 

Gratuite, garantie à vie et déjà utilisée par des millions d'internautes... vous aussi, pour votre adresse e-mail, choisissez laposte.net. Laposte.net, bien + qu'une messagerie

[Jan Wielemaker-3]

On Sun, 2009-11-01 at 21:53 +0100, j.gressier wrote:

>
>
> 2009/11/1 Jan Wielemaker <J.Wielemaker@...>
>
>        
>        
>        
>         On Sun, 2009-11-01 at 05:19 -0800, Elf_XP wrote:
>         > Hello!
>         > I have a great problem with SWI Prolog. So I need some help
>          :working:
>         > At first, I opened Visual Studio 2008 Command Prompt and
>         entered:
>         > plld -o program.exe source.c source.pl
>         > Then two files have appeared: program.exe and
>         program.exe.manifest
>         > Then I started program.exe.
>         > So, I have error "Unhandled exception at 0x1000c8f0 in
>         program.exe:
>         > 0xC0000005"
>         > Debugging information:
>         > crt0dat.c
>         > "pfbegin: 0x00000001 CXX0030 Error expression cannot be
>         evaluated"
>        
>         This seems some Windows error.  No idea.  Maybe something with
>         manifests?
>        
>         In addition though, term_t must be declared locally and must
>         be initialised using PL_new_term_ref() before it can be used.
>         PL_new_term_ref() can only be called after initializing
>         Prolog.
>        
>         In 99% of the cases I see it, embedding Prolog in C/C++/... is
>         not a good idea anyway ...  
>
>
> This is a rather alarming piece of news. I'd hate to have 1% chance of
> being right. I'm using Freepascal and an embedded Prolog in a very
> comfortable continuum. Absolutely no problem at all after 2 years of
> enthusiastic and successful development of a large program with a
> rather sophisticated graphic interface. I'm using swi-prolog, which
> you probably know. Maybe you were referring to other Prolog
> implementations... don't tell me I do not understand 99% percent of
> what I have been doing.

I'm not saying it cannot be done.  It works fine, but as you've
probably noticed, debugging Prolog that is embedded is a lot harder
because you lack access to the toplevel and most of the interactive
debugging environment.

If you are a bit dedicated, you can recreate some (most) of the
development environment, but the details depend on the platform,
the way the embedding is arranged and the `toplevel' of the embedding
system.   E.g., sometimes you can run the development environment in a
thread.

If you just want a program that behaves as an executable, you can
create it without embedding.  If functionality is missing, write the
stable stuff in C/whatever and link it from Prolog.  That still
maintains the interactive compilation and debugging environment.

Of course, this changes if the Prolog part is good and stable and
99% of the development work is in the environment that embeds Prolog
anyway.

> I used Visual Prolog before. I rewrote all the Visual Prolog code in
> Swi-Prolog (with much ease) . My main concern was about speed and I
> was wrong.

Good to hear :-)  If you can provide details, you could certainly
fulfill the curiosity of some people on this list.

        Cheers --- Jan

_______________________________________________
SWI-Prolog mailing list
SWI-Prolog@...
https://mailbox.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog

[j.gressier]

 > >

> > In 99% of the cases I see it, embedding Prolog in C/C++/... is
> > not a good idea anyway ...
> >
> >
> > This is a rather alarming piece of news. I'd hate to have 1% chance of
> > being right. I'm using Freepascal and an embedded Prolog in a very
> > comfortable continuum. Absolutely no problem at all after 2 years of
> > enthusiastic and successful development of a large program with a
> > rather sophisticated graphic interface. I'm using swi-prolog, which
> > you probably know. Maybe you were referring to other Prolog
> > implementations... don't tell me I do not understand 99% percent of
> > what I have been doing.
>
> I'm not saying it cannot be done. It works fine, but as you've
> probably noticed, debugging Prolog that is embedded is a lot harder
> because you lack access to the toplevel and most of the interactive
> debugging environment.

Although bugs in my programming style are utter exceptions I indulged myself in making some tools that leave some traces in files and... well , yes, it is rather wearing.

>
> If you are a bit dedicated, you can recreate some (most) of the
> development environment, but the details depend on the platform,
> the way the embedding is arranged and the `toplevel' of the embedding
> system. E.g., sometimes you can run the development environment in a
> thread.
>
> If you just want a program that behaves as an executable, you can
> create it without embedding. If functionality is missing, write the
> stable stuff in C/whatever and link it from Prolog. That still
> maintains the interactive compilation and debugging environment.
>
> Of course, this changes if the Prolog part is good and stable and
> 99% of the development work is in the environment that embeds Prolog
> anyway.
>
> > I used Visual Prolog before. I rewrote all the Visual Prolog code in
> > Swi-Prolog (with much ease) . My main concern was about speed and I
> > was wrong.
>
> Good to hear :-) If you can provide details, you could certainly
> fulfill the curiosity of some people on this list.
>
>

Before translating the visual prolog code I had made a few distressing tests. I knew they were not so significant in the context of the whole program but I nevertheless felt rather upset. I had mainly used strings in V. Prolog and decided not to change that  on swi-prolog side. For example, one of the most often called predicates of the main inference engine would take a string naming a geometric object such as a line, a segment etc...and give a list of the points defining it. ( the segment "[A1B]" -> [A1,B],  the angle "A1BC2" -> [A1,B,C2]  )

Calling the predicate from FreePascal 1000000 times would take 3 seconds with V. Prolog and 21 seconds with Swi-Prolog ! After so many years with  V Prolog I  had obviously lost some ability in pure prolog programming. I recollected pieces of myself deep in my memory and could gather up a knowledge not so far from the one I had in the early 80's. It led to 11 seconds. Still rather ominous !

However, I adapted the whole code in a straightforward way. I didn't change any algorithm at first and got a slower program but not as slow as I feared. 30% or 50% slower perhaps. I have no clear idea why.

I systematically use functors everywhere in the code to speed up unification (for readibility purposes also and as a consequence of the nature of the program).
The use of the trail stack (at least under V. prolog) was very limited.
I probably was very influenced by the input/output declarations in V. Prolog and I might have kept some habit there and a very close attention to unification of clause head litterals. Like every prolog programmer, naturally.
Systematic terminal recursion.... (when it is not too difficult to obtain, being a rather lazy programmer).
Few atoms, plenty of strings.
I do use assert and retract however.
Thera are about 40000 lines of Prolog code.
About 450 Prolog predicates are called (on the fly) from FreePascal. Some of them are the entry points of two inference engines and are time consuming_______________________________________________
SWI-Prolog mailing list
SWI-Prolog@...
https://mailbox.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog

[j.gressier]

....Wrong copy/paste, here is the end :


There are only two object types that pass between Swi-Prolog and FreePascal, numbers and strings.
FreePascal (under Lazarus) is exclusively dedicated to the GUI ,  the main stuff is handled by Swi-Prolog, ie, dynamic geometry, automatic reasoning, diagram checking.

Now, this was for the first pass. The second pass led to a much better optimization of the main inference engine (forward chaining and no recursion) which is now about 12 times faster. I multiplied the number of predicates, used meta programming and systematically indexed predicates.

I used to call the B+ trees of V. Prolog to store and access some data. I had to imagine a completely different algorithm to cope with the lack of B+ trees in Swi and finally managed to get equivalent performances.

Best regards
Jacques Gressier
http://geometrix.free.fr/geom3exos/telechg.htm

Gratuite, garantie à vie et déjà utilisée par des millions d'internautes... vous aussi, pour votre adresse e-mail, choisissez laposte.net. Laposte.net, bien + qu'une messagerie