incomprehensible error message

Help requests on developing Logtalk applications

Moderator: Paulo Moura

joerg
Posts: 40
Joined: Fri Dec 21, 2007 9:38 am

incomprehensible error message

Post by joerg » Wed Jul 01, 2009 2:53 pm

Hello,

when I installed the latest Logtalk version, some code that had been working stopped working and produced the following error message instead:

ERROR: '<meta-call>'/1: Undefined procedure: $lgt_call_built_in/2

The relevant piece of code is probably the following:

Code: Select all

:- object(code_compiler).

    :- public(generate_cis_js_dict/0).

    % ...
    generate_cis_js_dict :-
        setof([Cis, Js],
               JsTmp^(
                guesser::js_cis(JsTmp, Cis),
                atom_concat('german_noun_inflection_class_', Js, JsTmp)
               ),
              CisJs),
        write_cis_js(CisJs).
    % ...

:- end_object.

I think it has to do with the ^ operator.

Is this right? Or would you rather say that it must be due to some programming error of mine?

Jörg

Paulo Moura
Logtalk developer
Posts: 474
Joined: Sat May 05, 2007 8:35 am
Location: Portugal
Contact:

Re: incomprehensible error message

Post by Paulo Moura » Wed Jul 01, 2009 3:18 pm

I don't spot anything wrong in your code. Which Logtalk version are you using?
Paulo Moura
Logtalk developer

Paulo Moura
Logtalk developer
Posts: 474
Joined: Sat May 05, 2007 8:35 am
Location: Portugal
Contact:

Re: incomprehensible error message

Post by Paulo Moura » Wed Jul 01, 2009 3:39 pm

Using your code I found an optimization bug in the Logtalk compiler but that doesn't explain the error message that you're getting. The bug is already fixed in the current Logtalk development version. Can you try this version and check if the problem still occurs? Thanks for the report.
Paulo Moura
Logtalk developer

joerg
Posts: 40
Joined: Fri Dec 21, 2007 9:38 am

Re: incomprehensible error message

Post by joerg » Thu Jul 02, 2009 10:37 am

Hello Paulo,

I installed the new Logtalk version, ran the predicate again and it didn't work. Then I tried to add to my code two very simple objects that have the same problem. It didn't work. Then I tried the predicate generate_cis_js_dict againg and -- it worked. But it worked with the older Logtalk, too. I remembered that I still had yesterday's version of my program on another system. I made a backup of this version. I ran the predicate generate_cis_js_dict in the version of yesteday and I got the error message cited above. Then I added one single space to the version of yesterday, recompiled it, and the predicate worked.

So it must have someting to do with Logtalk's way of compiling files. Logtalk seems to have used a not-up-to-date .pl-file.

I don't know how to create a minimal example. But I can make more experiments or send you more information about my code, if you want.

Jörg

Paulo Moura
Logtalk developer
Posts: 474
Joined: Sat May 05, 2007 8:35 am
Location: Portugal
Contact:

Re: incomprehensible error message

Post by Paulo Moura » Thu Jul 02, 2009 11:50 am

joerg wrote: I installed the new Logtalk version, ran the predicate again and it didn't work.
Just to clarify, you installed the latest Logtalk stable release (2.37.2) or the latest Logtalk development release (which fixes the optimization bug described above)?
joerg wrote: Then I tried to add to my code two very simple objects that have the same problem. It didn't work. Then I tried the predicate generate_cis_js_dict againg and -- it worked. But it worked with the older Logtalk, too. I remembered that I still had yesterday's version of my program on another system. I made a backup of this version. I ran the predicate generate_cis_js_dict in the version of yesteday and I got the error message cited above. Then I added one single space to the version of yesterday, recompiled it, and the predicate worked.

So it must have someting to do with Logtalk's way of compiling files. Logtalk seems to have used a not-up-to-date .pl-file.
Your description suggests a problem with "smart compilation" of source files. Always a good idea to turn off the corresponding flag when updating Logtalk versions.
joerg wrote: I don't know how to create a minimal example. But I can make more experiments or send you more information about my code, if you want.
Please test with the "smart_compilation" turned off and using the latest Logtalk development version. Let me know if the problem persists.
Paulo Moura
Logtalk developer

joerg
Posts: 40
Joined: Fri Dec 21, 2007 9:38 am

Re: incomprehensible error message

Post by joerg » Thu Jul 02, 2009 12:25 pm

Just to clarify, you installed the latest Logtalk stable release (2.37.2) or the latest Logtalk development release (which fixes the optimization bug described above)?
I installed the latest Logtalk development release.
Please test with the "smart_compilation" turned off and using the latest Logtalk development version. Let me know if the problem persists.
Smart compilation was turned off in all my experiments. The problem persists. Here is an experiment with two versions of my program that differ in one single space:

Code: Select all

schuster@uschebti:~> cd tmp1
schuster@uschebti:~/tmp1> pl
?- consult(test).

Logtalk 2.37.3
Copyright (c) 1998-2009 Paulo Moura

Default lint compilation flags:
  unknown: warning, misspelt: warning, lgtredef: warning, plredef: silent
  portability: silent, singletons: warning, underscore_variables: singletons
Default documenting compilation flags:
  xmldocs: on, xmlspec: dtd, xmlsref: local, xslfile: lgtxml.xsl
Default directories compiler flags:
  altdirs: off, tmpdir: .lgt_tmp/, xmldir: xml_docs/
Default optional features compiler flags:
  complements: deny, dynamic_declarations: deny
  context_switching_calls: allow, events: deny
Other default compilation flags:
  startup_message: flags(compact), report: on
  code_prefix: $, hook: (none defined)
  debug: off, smart_compilation: off, reload: always
Read-only compilation flags (back-end Prolog compiler features):
  prolog_dialect: swi, break_predicate: supported, multifile_directive: supported
  threads: supported, encoding_directive: full, tabling: unsupported

No settings file found or unable to load settings files due to limitations
of the back-end Prolog compiler.

% (0 warnings)
% (0 warnings)
% (0 warnings)
% (0 warnings)
% (0 warnings)
% (0 warnings)
true.

?- code_compiler::generate_cis_js_dict.
ERROR: '<meta-call>'/1: Undefined procedure: $lgt_call_built_in/2
?- 

schuster@uschebti:~/tmp1> cd
schuster@uschebti:~> cd tmp2
schuster@uschebti:~/tmp2> pl
?- consult(test).

Logtalk 2.37.3
Copyright (c) 1998-2009 Paulo Moura

Default lint compilation flags:
  unknown: warning, misspelt: warning, lgtredef: warning, plredef: silent
  portability: silent, singletons: warning, underscore_variables: singletons
Default documenting compilation flags:
  xmldocs: on, xmlspec: dtd, xmlsref: local, xslfile: lgtxml.xsl
Default directories compiler flags:
  altdirs: off, tmpdir: .lgt_tmp/, xmldir: xml_docs/
Default optional features compiler flags:
  complements: deny, dynamic_declarations: deny
  context_switching_calls: allow, events: deny
Other default compilation flags:
  startup_message: flags(compact), report: on
  code_prefix: $, hook: (none defined)
  debug: off, smart_compilation: off, reload: always
Read-only compilation flags (back-end Prolog compiler features):
  prolog_dialect: swi, break_predicate: supported, multifile_directive: supported
  threads: supported, encoding_directive: full, tabling: unsupported

No settings file found or unable to load settings files due to limitations
of the back-end Prolog compiler.

% (0 warnings)
% (0 warnings)
% (0 warnings)
% (0 warnings)
% (0 warnings)
% (0 warnings)
true.

?- code_compiler::generate_cis_js_dict.
'LN0' : 'Fabella',
'LN20' : 'Aortitis',
'LN38' : 'Circulus',
'LN9' : 'Abruptio',
'NS0,NP0' : 'Abakus',
'NS0,NP1' : 'Debreziner',
'NS0,NP11' : 'Tochter',

% more output comes here


Paulo Moura
Logtalk developer
Posts: 474
Joined: Sat May 05, 2007 8:35 am
Location: Portugal
Contact:

Re: incomprehensible error message

Post by Paulo Moura » Thu Jul 02, 2009 4:01 pm

What's puzzling is that there is no '$lgt_call_built_in'/2 predicate in Logtalk 2.37.2 or in the current development version. You can check that yourself by doing a search on the "compiler/logtalk.pl" file that defines the Logtalk compiler and the Logtalk runtime. There was a '$lgt_call_built_in'/2 predicate in older Logtalk versions that, together with the optimization bug (corrected in 2.37.3) and with the "smart_compilation" flag turned on, could possibly explain the problem. Can you mail me a full example that allows the problem to be reproduced? Where do you insert the space that makes the problem vanish? That suggest some issue with operators.
Paulo Moura
Logtalk developer

joerg
Posts: 40
Joined: Fri Dec 21, 2007 9:38 am

Re: incomprehensible error message

Post by joerg » Fri Jul 03, 2009 7:22 am

There was a '$lgt_call_built_in'/2 predicate in older Logtalk versions that, together with the optimization bug (corrected in 2.37.3) and with the "smart_compilation" flag turned on, could possibly explain the problem.
I checked the program again and saw that, although smart compilation is turned off at logtalk-loading time (as the compiler itself reports), I turned it on at a later time. Sorry for not noticing this earlier. This is due to several facts: (1) My program is quite large, it consists of many parts and I do not work with all of them every day. (2) I use to configure new Logtalk versions by editing quite a lot files (which is probably a bad idea, but I never had the patience to figure out how to do it more elegantly). (3) I use to switch between different Prolog compilers (which is probably an even worse idea, but Swi produces good error messages and Yap is really fast).

Thanks for your help.

Jörg

Paulo Moura
Logtalk developer
Posts: 474
Joined: Sat May 05, 2007 8:35 am
Location: Portugal
Contact:

Re: incomprehensible error message

Post by Paulo Moura » Fri Jul 03, 2009 12:37 pm

joerg wrote: I checked the program again and saw that, although smart compilation is turned off at logtalk-loading time (as the compiler itself reports), I turned it on at a later time. Sorry for not noticing this earlier.
No worries. It helped me catch an optimization bug :-)
joerg wrote: This is due to several facts: (1) ... (2) I use to configure new Logtalk versions by editing quite a lot files (which is probably a bad idea, but I never had the patience to figure out how to do it more elegantly). (3) I use to switch between different Prolog compilers (which is probably an even worse idea, but Swi produces good error messages and Yap is really fast).
What limitations do you find in the provided Prolog integration scripts ("swilgt", "yaplgt", ...) and on the support for settings files that leads you to "configure new Logtalk versions by editing quite a lot of files"? Note that you can use Logtalk conditional compilation directives in a settings file when using more than one back-end Prolog compiler.
Paulo Moura
Logtalk developer

joerg
Posts: 40
Joined: Fri Dec 21, 2007 9:38 am

Re: incomprehensible error message

Post by joerg » Fri Jul 03, 2009 2:52 pm

Note that you can use Logtalk conditional compilation directives in a settings file when using more than one back-end Prolog compiler.
Yes, this is what I should do with all of my programs. But I never find the right moment to do it, because most of the time I need to do some quick and dirty hack in some program or other and usually these hacks presuppose a certain Prolog compiler or a certain configuration or a certain legacy code ...

I use Yap only for tasks that are both simple and (run-) time-consuming, because it lacks many of the useful modules of Swi. Writing compiler-independent, clean *and* fast code in Logtalk is an overkill for a lot of tasks.

But I am really looking forward to the day I start rewriting my most important programs from scratch ...

Jörg

Paulo Moura
Logtalk developer
Posts: 474
Joined: Sat May 05, 2007 8:35 am
Location: Portugal
Contact:

Re: incomprehensible error message

Post by Paulo Moura » Fri Jul 03, 2009 8:26 pm

joerg wrote: I use Yap only for tasks that are both simple and (run-) time-consuming, because it lacks many of the useful modules of Swi.
Which SWI-Prolog modules would you like to see ported to Logtalk (in order to be able to use them with any back-end Prolog compiler)? Note that Logtalk is already able to compile most Prolog modules as objects without any source changes.
Paulo Moura
Logtalk developer

joerg
Posts: 40
Joined: Fri Dec 21, 2007 9:38 am

Re: incomprehensible error message

Post by joerg » Mon Jul 06, 2009 3:12 pm

Which SWI-Prolog modules would you like to see ported to Logtalk (in order to be able to use them with any back-end Prolog compiler)?
I didn't express myself very precisely. It is not only for its modules that I usually write Swi-dependent code. The two main reason why I prefer Swi to Yap (and to other compilers) is that it produces good error messages (Yap e.g. fails silently when you try to use a non-existent predicate) and that most of its features are very well documented.

I would not be so bold as to post the following list in the wish-list part of this forum, but since you asked, here are my personal top 6 reasons for writing non-portable code in Logtalk or for using plain Prolog or Python instead of Logtalk.

(1) There are some things which one does not want to do in Prolog, but in C. As each Prolog compiler has a different foreign language interface, I do not use Logtalk for programs that use predicates written in C. I know that one can hardly expect the Logtalk compiler to take care of such low level things, but for me this is the most important reason not to use Logtalk for all my programs at the moment.

(2) There are some system libraries of Swi which have no equivalent in Logtalk. Sorted by importance: readutil.pl, sort.pl, ordsets.pl. (Because of the presence of readutil.pl, I have been using non-portable Logtalk instead of Python, lately.)

(3) Logtalk lacks some practical built-in predicates that are present in Swi. Sorted by importance: shell, time_file, exists_file (and the like), ground, format, atomic_list_concat, downcase_atom, atom_number, term_to_atom.

(4) Logtalk has no interface to databases. (I use sqlite3 and very ugly shell tricks.)

(5) Logtalk does not have sockets nor a web server (as Swi).

(6) Logtalk has no regular expressions. (If it had them, I would stop using Python).

Paulo Moura
Logtalk developer
Posts: 474
Joined: Sat May 05, 2007 8:35 am
Location: Portugal
Contact:

Re: incomprehensible error message

Post by Paulo Moura » Mon Jul 06, 2009 5:21 pm

joerg wrote: I didn't express myself very precisely. It is not only for its modules that I usually write Swi-dependent code. The two main reason why I prefer Swi to Yap (and to other compilers) is that it produces good error messages (Yap e.g. fails silently when you try to use a non-existent predicate) and that most of its features are very well documented.
The Logtalk config file for YAP sets the "unknown" flag to "error" (the default value for this flag in YAP is "fail", which leads to the behavior you describe above).
joerg wrote: I would not be so bold as to post the following list in the wish-list part of this forum, but since you asked, here are my personal top 6 reasons for writing non-portable code in Logtalk or for using plain Prolog or Python instead of Logtalk.
Please be bold :-)
joerg wrote: (1) There are some things which one does not want to do in Prolog, but in C. As each Prolog compiler has a different foreign language interface, I do not use Logtalk for programs that use predicates written in C. I know that one can hardly expect the Logtalk compiler to take care of such low level things, but for me this is the most important reason not to use Logtalk for all my programs at the moment.

(2) There are some system libraries of Swi which have no equivalent in Logtalk. Sorted by importance: readutil.pl, sort.pl, ordsets.pl. (Because of the presence of readutil.pl, I have been using non-portable Logtalk instead of Python, lately.)
The Logtalk equivalent of "ordsets.pl" is the object library "set". You can load it by using the query "logtalk_load(library(types_loader))". If you load this library before the code that makes use of it, Logtalk will use static binding for the library predicates, which will give you similar performance to plain Prolog. I will consider adding the functionality of "sort.pl" to the Logtalk library for the next stable version. The "readutil.pl" is more difficult to port as it uses the SWI-Prolog foreign-language interface for performance. However, this library also includes a more portable (and, I assume, slower) Prolog alternative. I will talk to Jan about it.
joerg wrote: (3) Logtalk lacks some practical built-in predicates that are present in Swi. Sorted by importance: shell, time_file, exists_file (and the like), ground, format, atomic_list_concat, downcase_atom, atom_number, term_to_atom.
The predicate ground/1 is defined in the Logtalk library object "term". The remaining predicates are not standard (although atomic_list_concat/2-3 and atom_number/2 are easy to code; downcase_atom/2 and upcase_atom/2 are easy to code if you assume ASCII for portability). For a portable file-system interface see the Logtalk example "cc".
joerg wrote: (4) Logtalk has no interface to databases. (I use sqlite3 and very ugly shell tricks.)

(5) Logtalk does not have sockets nor a web server (as Swi).

(6) Logtalk has no regular expressions. (If it had them, I would stop using Python).
All these features requires support from the back-end Prolog compiler that is not portable and depends on the foreign-language interface. A Logtalk user contributed a first sketch of a sockets library that could run SWI-Prolog, YAP, and maybe a few other Prolog compilers. However, this library needs some work before it can be added to the Logtalk distribution.

Thanks for your wish list. It helps guide Logtalk development.
Paulo Moura
Logtalk developer

joerg
Posts: 40
Joined: Fri Dec 21, 2007 9:38 am

Re: incomprehensible error message

Post by joerg » Tue Jul 07, 2009 8:13 am

I forgot the most important reason for not writing portable Logtalk code:

(0) There is no compiler-independent way to create standalone executables from Logalk porgrams.

I need to share my programs with other people. Mostly, these people are not programmers, let alone Prolog programmers. They are linguists or linguistics students. I don't want to have to tell them how to use Logtalk objects. I even don't want to have to tell them how to install a Prolog compiler. Therefore, I use Swi's way of generating standalone executables that one can use without having Swi installed.

By the way: I want to have standalone executables for myself, too: They have a minimal start-up time and one can use them in pipes and the like.

That is why I usually create an interface of the following type for the more important programs:

Code: Select all


#!/usr/bin/pl -q -t main -f

:- consult('~/bin/lib/load_logtalk.pl').

:- logtalk_load(automatic).
:- logtalk_load(main).
:- logtalk_load(english).
:- logtalk_load(german).
:- logtalk_load(greek).


main :-
	current_prolog_flag(argv, Args),
	Args = [lc, compile],
	!,
	write('Usage:\n\n'),
	write('lc compile <lc directory> <algorithm>?\n\n'),
	write('For more information use \'lc manual compile\'.\n'),
	halt.

main :-
	current_prolog_flag(argv, Args),
	Args = [lc, compile, LcDirectory],
	!,
	compiler::compile(LcDirectory),
	halt.

main :-
	current_prolog_flag(argv, Args),
	Args = [lc, compile, LcDirectory, Algorithm],
	!,
	compiler::compile(LcDirectory, Algorithm),
	halt.

% more main-clauses come here

Of course, something similar can be done in Yap. But it is only similar code, not the same code.

Jörg

Parker
Posts: 33
Joined: Wed Feb 27, 2008 2:51 pm

Re: incomprehensible error message

Post by Parker » Tue Jul 07, 2009 9:16 am

joerg wrote: (0) There is no compiler-independent way to create standalone executables from Logalk porgrams.
This is interesting. A way of creating an executable that works for all compilers that support it would be a very good development.

Parker

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest