Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Failure to build standalone executable in v7.6.4 #87

Open
jal-frezie opened this issue Mar 3, 2019 · 7 comments
Open

Failure to build standalone executable in v7.6.4 #87

jal-frezie opened this issue Mar 3, 2019 · 7 comments

Comments

@jal-frezie
Copy link

Testing in an aarch64 machine running Ubuntu Bionic. My testmain.pl is:

main :-
format_to_chars("A ~w can be anything", [1234], Foostr),
write(Foostr), nl.

This file can be consulted from the prompt, and outputs a list of character codes when main() is called. I attempt to build a standalone executable for it by going

swipl --traditional --goal=main --stand_alone=true -o xssimile -c testmain.pl

...and the following messages appear:
ERROR: /usr/lib/swi-prolog/library/qsave.pl:460:7: Syntax error: Operator expected
% autoloading prolog_codewalk:must_be/2 from /usr/lib/swi-prolog/library/error
% autoloading oset:reverse/2 from /usr/lib/swi-prolog/library/lists
% autoloading prolog_debug:backtrace/1 from /usr/lib/swi-prolog/library/prolog_stack
% autoloading qsave:current_foreign_library/2 from /usr/lib/swi-prolog/library/shlib
% autoloading record:member/2 from /usr/lib/swi-prolog/library/lists
% autoloading prolog_codewalk:portray_clause/1 from /usr/lib/swi-prolog/library/listing
% autoloading prolog_codewalk:clause_info/4 from /usr/lib/swi-prolog/library/prolog_clause
% autoloading prolog_codewalk:initialization_layout/4 from /usr/lib/swi-prolog/library/prolog_clause
% autoloading error:assertion/1 from /usr/lib/swi-prolog/library/debug
% autoloading user:format_to_chars/3 from /usr/lib/swi-prolog/library/charsio
% autoloading prolog_codewalk:clause_name/2 from /usr/lib/swi-prolog/library/prolog_clause
% Autoloader: iteration 1 resolved 11 predicates and loaded 11 files in 0.445 seconds. Restarting ...
% Autoloader: loaded 11 files in 2 iterations in 0.614 seconds
ERROR: atomics_to_string/2: Type error: text' expected, found [126,119,61]' (a list)

No executable is produced. Consulting the file /usr/lib/swi-prolog/library/qsave.pl at the prompt does not produce errors. To produce the atomics_to_string/2 error at the prompt, the 1st arg has to be a list containing the sublist `[126,119,61]' .
The same example works OK producing a good executable in Swipl 6.6.6 on armv7l machine running Debian Jessie, and in Swipl 7.2.3 on an x86-64 machine running Debian Stretch.

@JanWielemaker
Copy link
Member

7.6.4 is very old and --traditional causes a lot of things to malfunction. That is only intended for people who expect a very basic and as much as possible compatible version. Try drop that first. Else upgrade.

@jal-frezie
Copy link
Author

Just tried on Swipl 8.0.1, and it appears the --traditional option is gone. This is a pain, because I have a large volume of legacy code that would take a lot of work to translate to modern, especially as I want to keep compatibility with GNU-Prolog. Looks like I am going to have to support the armv7l and aarch64 platforms by using older versions of Swipl.

@JanWielemaker
Copy link
Member

? A little test shows that basic -traditional is still there. Just, more and more parts of the system rely SWI 7 features and thus stop to work with -traditional.

But, SWI 7 is designed to run 99.9% of ISO code. Only a few things to not work, but for those there are alternative constructs that both work in ISO and SWI 7. You might need

:- set_prolog_flag(double_quotes, codes).

If you think otherwise, please show the code that causes problems without -traditional.

@jal-frezie
Copy link
Author

OK, I was getting confused by the error message from Swi 8.0.1, which was:

jaspert$ swipl --traditional --goal=main --stand_alone=true -o xssimile -c testmain.pl
ERROR: /Applications/SWI-Prolog.app/Contents/swipl/library/qsave.pl:677:7: Syntax error: Operator expected
ERROR: save_option `traditional' does not exist

Looks like the error I reported is still there, plus others.
Regarding doing without --traditional, it looks like I have to put the directive
:- set_prolog_flag(double_quotes, codes).
into every module, and also call it as a predicate before doing term I/O with quoted strings -- or is there an easier way?

@JanWielemaker
Copy link
Member

I think it should be enough to put an :- set_prolog_flag(double_quotes, codes). at the start of testmain.pl to get it all compiled correctly and an :- initialization set_prolog_flag(double_quotes, codes). to get the runtime behaviour to work. Note that the chapter on SWI 7 extensions provides a quite in depth discussion on how to handle strings and how to debug string issues.

@jal-frezie
Copy link
Author

OK, I was able to put the directive in every module since the module declarations themselves were inserted by term expansion, so I just tweaked that to include the directive as well. Now I have the problem that infix operators in single quotes do not work outside traditional mode (except if the quotes are needed to stop the operator being a variable!). For instance...
$ swipl --traditional
...
?- op(550, xfy, and).
true.

?- P = a 'and' b.
P = a and b.

?-
% halt
$ swipl
...
?- op(550, xfy, and).
true.

?- P = a 'and' b.
ERROR: Syntax error: Operator expected
ERROR: P = a
ERROR: ** here **
ERROR: 'and' b .
?-

Is there another declaration to fix this? Happy to take discussion elsewhere if appropriate.

@JanWielemaker
Copy link
Member

The rule is, following ECLiPSe, if the operator does not need quotes, quoting it prevents it from being an operator. Otherwise, e.g., :- op(100, yf, 'Gb')., quoting is ok: 100'Gb'.

So, all you need to do is get rid of the quotes around e.g. 'and'. That should still work on any ISO compliant system.

The mailinglist/forum is a more appropriate place. I guess we are (almost) done though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants