Thanks for your reply. I can work with sequential builds for a day. I will wait for your updated release.
-----Original Message-----
From: curry-bounces_at_lists.RWTH-Aachen.DE [mailto:curry-bounces_at_lists.RWTH-Aachen.DE] On Behalf Of Michael Hanus
Sent: Tuesday, January 06, 2015 3:59 AM
To: curry_at_lists.RWTH-Aachen.DE
Subject: Re: Multiple instances of PAKCS interfere with each other
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 Mi Jan 07 2015 - 09:29:06 CET