Hi Andy,
thanks for the bug report (and Karn for the comments).
Fortunately, there is no problem if one uses the
SICStus-Prolog back end of PAKCS, since this back end uses
a different file for writing the temporary Prolog file
containing the definitions of the "main" predicates like
(head) normal form computation and similar things.
Since SWI-Prolog always complains when definitions of
predicates are reloaded from different files, I decided
to use always the same file for each instance of a PAKCS/SWI
installation. This example shows that this was not a good
decision...
An easy fix is to use the implementation of the SICStus-Prolog
back end also for the SWI-Prolog back end. However, in order to
avoid the nasty warnings of SWI-Prolog, one has to add also
some code to suppress these warnings (and I am not sure that this
code is compatible with the different versions of SWI-Prolog).
I'll put these changes in the next development release of PAKCS
(which will be available tomorrow). For a quick fix, you can
replace in curry2prolog/swibasics.pl the definitions of the
predicates getNewFileName/2 and mainPrologFileName/2 by the
following code:
-----
% get name of temporary file with a given (possibly empty) suffix:
getNewFileName(Suffix,NewFile) :-
currentPID(PID),
number_codes(PID,PIDS),
append("/tmp/pakcs_file_",PIDS,P1),
(Suffix=[] -> ProgS=P1 ; append(P1,[46|Suffix],ProgS)),
atom_codes(NewFile,ProgS),
append("rm -rf ",ProgS,RmCmdS),
atom_codes(RmCmd,RmCmdS),
shellCmd(RmCmd).
% determine for a given Prolog file (the main module) a file name
% where the clauses for the main predicates (hnf, constrEq,...)
% should be stored:
mainPrologFileName(_PrologFile,MainPrologFile) :-
getNewFileName("pl",NewPrologFile),
appendAtom(NewPrologFile,'.main',MainPrologFile).
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% define hook predicate to suppress warnings for redefined procedures
% when loading Prolog programs:
:- multifile user:message_hook/3.
:- dynamic user:message_hook/3.
user:message_hook(redefined_procedure(_,_),warning,_) :- !.
-----
I hope this helps. Nevertheless, keep in mind that this might
not solve all problems when compiling the same program
concurrently, since there might be race conditions when writing
and loading the compiled target programs.
Best regards,
Michael
On 01/06/2015 09:04 AM, Karn Kallio wrote:
>
>> It seems I've found a bug in PAKCS. I have a small example:
>>
>> -- example.curry
>> main = 26+27
>>
>>
>> # go.bash
>> pakcs -q :l example.curry :eval main :q &
>> pakcs -q :l example.curry :eval main :q &
>> pakcs -q :l example.curry :eval main :q &
>> pakcs -q :l example.curry :eval main :q &
>> wait
>>
>>
>> Running go.bash gives the following errors on my system:
>>
>> ERROR: /tmp/pl_pakcs_main_11765_0:36:0: Syntax error: Unexpected end of file
>> ERROR: /tmp/pl_pakcs_main_11765_0:67:0: Syntax error: Unexpected end of
>> file ERROR:
>> ERROR: delete_file/1: file `/tmp/pl_pakcs_main_11765_0' does not exist (No
>> such file or directory) ERROR: source_sink `/tmp/pl_pakcs_main_11765_0'
>> does not exist
>> ERROR:
>> ERROR: delete_file/1: file `/tmp/pl_pakcs_main_11765_0' does not exist (No
>> such file or directory)
>>
>> PAKCS_Main_Exp.curry, line 1.17:
>> `main' is undefined
>> ERROR occurred during parsing!
>>
>> PAKCS_Main_Exp.curry, line 1.17:
>> `main' is undefined
>> ERROR occurred during parsing!
>> ERROR:
>> ERROR: blocked_normalizeAndCheck/4: Undefined procedure: nf/4
>> 53
>>
>>
>> Everything works if I remove the ampersands. I kept the example small by
>> running the same Curry script in each invocation, but that is not necessary
>> to see the problem.
>>
>> It looks like the different instances of the program are all using the same
>> temp file name.
>>
>> I am running this version of PAKCS:
>> ______ __ _ _ ______ _______
>>
>> | __ | / \ | | / / | ____| | _____| Portland Aachen Kiel
>> |
>> | | | | / /\ \ | |_/ / | | | |_____ Curry System
>> | |
>> | |__| | / /__\ \ | _ | | | |_____ |
>> | |
>> | ____| / ______ \ | | \ \ | |____ _____| | Version 1.11.4 (4)
>> |
>> |_| /_/ \_\ |_| \_\ |______| |_______|
>>
>> Curry2Prolog(swi 5.10) Compiler Environment (Version of 2014-10-16)
>> (RWTH Aachen, CAU Kiel, Portland State University)
>>
>>
>> This appears to be a bug. Can I file a bug report somewhere (or is this
>> mailing list the place)? This is a problem for me because I want to use
>> pakcs as part of a software build step. This bug prevents me from building
>> in parallel.
>>
>> -Andy
>
> At least in the case of SWI Prolog, this is because the pid of the swi
> interpreter process running during the install of PAKCS is taken and saved by
> the qsave_program/2, so that explains why the temporary file is always the
> same. A "brute force" way to fix this would be to declare mainPrologFileName/1
> in swibasics.pl as volatile, by for example adding a line
> :- volatile mainPrologFileName/1.
> to the file curry2prolog/swibasics.pl. That should be enough to get a different
> temporary file name with each swi interpreter process. Note that in
> curry2prolog/compiler.pl the writeGenericClauses/1 is most probably going to
> redefine several predicates now that the filename has changed. I think you
> could fix that by studying the implementation to see what predicates they are
> and then declaring all of them as multifile.
>
> Maybe this is not enough to get several interpreters running concurrently
> though ... there may be other obstacles.
>
> Saludos,
> Karn
>
> _______________________________________________
> curry mailing list
> curry_at_lists.RWTH-Aachen.DE
> http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
>
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Di Jan 06 2015 - 13:00:08 CET