Re: Error message under Wine when installing Pac Converters
Posted: Thu Jun 21, 2018 2:21 pm
I do not use anti-virus software for macOS (never had any need for it); to my knowledge macOS (newest version) doesn't have hidden anti-virus processes running in the background. If an anti-virus program caused the problem it would not have been linked to writing to one type of file system (ExFAT).
Adding a dummy procedure (exported / not exported) to PacAPI or putting some text after "... END PacAPI." has no effect.
I tried to isolate the causative CP-code in PacAPI by commenting out procedures of that module. In that way I found the maximum version of PacAPI that compiled and did not leave Pac/Code/API.ocf empty.
It appears that only when all of the following modules are left out the problem does not occur:
PROCEDURE (e: EnumComp) Next- (OUT pathi, pathf: ARRAY OF CHAR; OUT ok: BOOLEAN): BOOLEAN, NEW, ABSTRACT;
PROCEDURE (fl: FileList) Next* (OUT name: String; OUT privF: PrivFileDesc): BOOLEAN, NEW;
PROCEDURE (uc: DeComp) Depack* (f: Files.File; OUT c: PacContent), NEW, ABSTRACT;
PROCEDURE (uc: StdDeComp) Depack (f: Files.File; OUT c: PacContent);
PROCEDURE (uc: DeComp) TestCrc* (pubF: PubFileDesc; privF: PrivFileDesc): BOOLEAN, NEW, ABSTRACT;
PROCEDURE (uc: StdDeComp) TestCrc (pubF: PubFileDesc; privF: PrivFileDesc): BOOLEAN;
PROCEDURE (uc: DeComp) Unpack* (IN path: ARRAY OF CHAR; pubF: PubFileDesc; privF: PrivFileDesc; overwrite: BOOLEAN): INTEGER, NEW, ABSTRACT;
PROCEDURE (uc: StdDeComp) Unpack (IN path: ARRAY OF CHAR; pubF: PubFileDesc; privF: PrivFileDesc; overwrite: BOOLEAN): INTEGER;
PROCEDURE (c: Comp) PackDoc* (s: Stores.Store; f: Files.File), NEW, ABSTRACT;
PROCEDURE (c: StdComp) PackDoc (s: Stores.Store; f: Files.File);
PROCEDURE (c: Comp) PackFile* (lIn, lOut: Files.Locator; IN nameIn, nameOut: Files.Name): BOOLEAN, NEW, ABSTRACT;
PROCEDURE (c: StdComp) PackFile (lIn, lOut: Files.Locator; IN nameIn, nameOut: Files.Name): BOOLEAN;
PROCEDURE (c: StdComp) EncodeText (t1: TextModels.Model; OUT t2: TextModels.Model);
PROCEDURE (c: Comp) EncodeText* (t1: TextModels.Model; OUT t2: TextModels.Model), NEW, ABSTRACT;
PROCEDURE (c: Comp) EncodeFile* (l: Files.Locator; IN name: Files.Name; OUT t: TextModels.Model): BOOLEAN, NEW, ABSTRACT;
PROCEDURE (c: StdComp) EncodeFile (l: Files.Locator; IN name: Files.Name; OUT t: TextModels.Model): BOOLEAN;
PROCEDURE (c: Comp) ChooseComp* (IN comp: ARRAY OF CHAR): BOOLEAN, NEW, ABSTRACT;
PROCEDURE (c: StdComp) ChooseComp (IN comp: ARRAY OF CHAR): BOOLEAN;
Even when leaving in a single abstract procedure signature like the next line the problem will happen:
PROCEDURE (e: EnumComp) Next- (OUT pathi, pathf: ARRAY OF CHAR; OUT ok: BOOLEAN): BOOLEAN, NEW, ABSTRACT;
Of interest is that a few procedures that are very similar to some of the above procedures can be left in without the problem occurring.
E.g. leaving in NewComp* and NewComp (very similar to ChooseComp* and ChooseComp) is no problem.
Also of interest is that the popping-up of the File Error dialog "...Pac/Code/API.ocf could not be replaced because it is in use" always is tightly linked to the staying empty of API.ocf, but only occurs when trying to compile the same module version a second time. After changing the PacAPI source file the module can only be successfully recompiled after deleting the empty API.ocf file.
I will now install Wine on my Linux partition and make tests of BlackBox compiling PacAPI and writing to the same ExFAT partition. As far as I understand it the problem most probably is a bug in the ExFAT code. But my knowledge of file systems is scanty so it is just a (calculated) guess...
--
Hans
Adding a dummy procedure (exported / not exported) to PacAPI or putting some text after "... END PacAPI." has no effect.
I tried to isolate the causative CP-code in PacAPI by commenting out procedures of that module. In that way I found the maximum version of PacAPI that compiled and did not leave Pac/Code/API.ocf empty.
It appears that only when all of the following modules are left out the problem does not occur:
PROCEDURE (e: EnumComp) Next- (OUT pathi, pathf: ARRAY OF CHAR; OUT ok: BOOLEAN): BOOLEAN, NEW, ABSTRACT;
PROCEDURE (fl: FileList) Next* (OUT name: String; OUT privF: PrivFileDesc): BOOLEAN, NEW;
PROCEDURE (uc: DeComp) Depack* (f: Files.File; OUT c: PacContent), NEW, ABSTRACT;
PROCEDURE (uc: StdDeComp) Depack (f: Files.File; OUT c: PacContent);
PROCEDURE (uc: DeComp) TestCrc* (pubF: PubFileDesc; privF: PrivFileDesc): BOOLEAN, NEW, ABSTRACT;
PROCEDURE (uc: StdDeComp) TestCrc (pubF: PubFileDesc; privF: PrivFileDesc): BOOLEAN;
PROCEDURE (uc: DeComp) Unpack* (IN path: ARRAY OF CHAR; pubF: PubFileDesc; privF: PrivFileDesc; overwrite: BOOLEAN): INTEGER, NEW, ABSTRACT;
PROCEDURE (uc: StdDeComp) Unpack (IN path: ARRAY OF CHAR; pubF: PubFileDesc; privF: PrivFileDesc; overwrite: BOOLEAN): INTEGER;
PROCEDURE (c: Comp) PackDoc* (s: Stores.Store; f: Files.File), NEW, ABSTRACT;
PROCEDURE (c: StdComp) PackDoc (s: Stores.Store; f: Files.File);
PROCEDURE (c: Comp) PackFile* (lIn, lOut: Files.Locator; IN nameIn, nameOut: Files.Name): BOOLEAN, NEW, ABSTRACT;
PROCEDURE (c: StdComp) PackFile (lIn, lOut: Files.Locator; IN nameIn, nameOut: Files.Name): BOOLEAN;
PROCEDURE (c: StdComp) EncodeText (t1: TextModels.Model; OUT t2: TextModels.Model);
PROCEDURE (c: Comp) EncodeText* (t1: TextModels.Model; OUT t2: TextModels.Model), NEW, ABSTRACT;
PROCEDURE (c: Comp) EncodeFile* (l: Files.Locator; IN name: Files.Name; OUT t: TextModels.Model): BOOLEAN, NEW, ABSTRACT;
PROCEDURE (c: StdComp) EncodeFile (l: Files.Locator; IN name: Files.Name; OUT t: TextModels.Model): BOOLEAN;
PROCEDURE (c: Comp) ChooseComp* (IN comp: ARRAY OF CHAR): BOOLEAN, NEW, ABSTRACT;
PROCEDURE (c: StdComp) ChooseComp (IN comp: ARRAY OF CHAR): BOOLEAN;
Even when leaving in a single abstract procedure signature like the next line the problem will happen:
PROCEDURE (e: EnumComp) Next- (OUT pathi, pathf: ARRAY OF CHAR; OUT ok: BOOLEAN): BOOLEAN, NEW, ABSTRACT;
Of interest is that a few procedures that are very similar to some of the above procedures can be left in without the problem occurring.
E.g. leaving in NewComp* and NewComp (very similar to ChooseComp* and ChooseComp) is no problem.
Also of interest is that the popping-up of the File Error dialog "...Pac/Code/API.ocf could not be replaced because it is in use" always is tightly linked to the staying empty of API.ocf, but only occurs when trying to compile the same module version a second time. After changing the PacAPI source file the module can only be successfully recompiled after deleting the empty API.ocf file.
I will now install Wine on my Linux partition and make tests of BlackBox compiling PacAPI and writing to the same ExFAT partition. As far as I understand it the problem most probably is a bug in the ExFAT code. But my knowledge of file systems is scanty so it is just a (calculated) guess...
--
Hans