Page 2 of 3

Re: Error message under Wine when installing Pac Converters

Posted: Thu Jun 21, 2018 2:21 pm
by HansKlaver
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

Re: Error message under Wine when installing Pac Converters

Posted: Thu Jun 21, 2018 7:55 pm
by Josef Templ
I don't know if it helps but you could also try the run-time debugger of the latest development version
in http://blackboxframework.org/lastdev/zip.
It has been tested also under wine but not as extensively as under Windows.

I would look specifically for calls to the garbage collector while compiling PacAPI.
The garbage collector, when called, also finalizes objects that are no longer needed and
files are objects that do have a finalizer. If, for any reason, a file is finalized too early,
it could explain the observed effect.

- Josef

Re: Error message under Wine when installing Pac Converters

Posted: Sat Jun 30, 2018 7:01 am
by HansKlaver
Josef Templ wrote:I don't know if it helps but you could also try the run-time debugger of the latest development version
in http://blackboxframework.org/lastdev/zip.
It has been tested also under wine but not as extensively as under Windows.

I would look specifically for calls to the garbage collector while compiling PacAPI.
I played a bit with the run-time debugger, and I somewhat figured out how to use it (the last time I used a debugger was when programming with TopSpeed Modula-2 some 30 years ago...).

However I got stuck when I tried to debug the command that causes the problem:
DevCompiler.CompileThis PacAPI

This command only works with a commander and a modulelist. When trying to use it without a commander and with Dev->Execute I get a message "no text view found". But (as far as I understand) the debugger only can be started with a selected command name or module name, without a commander. I could not find a command that starts the compiler with a module name, without the module name being selected.

--
Hans

Re: Error message under Wine when installing Pac Converters

Posted: Sun Jul 01, 2018 6:33 am
by Josef Templ
In this case start the debugger with 'Debug Module'.
In the debugger set a breakpoint at the beginning of the command that you want to debug.
Go back to the debuggee and execute the commander.
Execution will stop at the brealpoint. Go to the debugger and step through...

- Josef

Re: Error message under Wine when installing Pac Converters

Posted: Sun Jul 01, 2018 2:32 pm
by HansKlaver
Josef Templ wrote:In this case start the debugger with 'Debug Module'.
In the debugger set a breakpoint at the beginning of the command that you want to debug.
Go back to the debuggee and execute the commander.
Execution will stop at the brealpoint. Go to the debugger and step through...
I did as you suggested, but I'm afraid when debugging a command with a commander and an argument (e.g. selection or modulelist) setting a breakpoint does not work, because the module is unloaded (by the debugger I guess) when the commander is clicked, and when you try to go to the breakpoint in the debugger the start of the remote source is shown, and not the set breakpoint...

You can see the same behaviour when trying to debug ObxCaps that way (make a selection before clicking the commander).

I will now do it in yet another way: by using DevCompiler.Compile (in stead of CompileThis) and the module source in the focus text.

--
Hans

Re: Error message under Wine when installing Pac Converters

Posted: Sun Jul 01, 2018 8:13 pm
by Josef Templ
I just tried ObxCaps.Do with a commander and it works without any problems,
both under Windows and Debian/wine.

Note: the module is only unloaded if you press the modifier key (Ctrl) when activating the command.

- Josef

Re: Error message under Wine when installing Pac Converters

Posted: Sun Jul 01, 2018 9:35 pm
by HansKlaver
Josef Templ wrote:I just tried ObxCaps.Do with a commander and it works without any problems,
both under Windows and Debian/wine.

Note: the module is only unloaded if you press the modifier key (Ctrl) when activating the command.
Well, in my installation (macOS/wine 2.0) the module is unloaded just by clicking on the commander (without pressing any key) in the situation I described (following your advice).

Anyway, that might be another problem. I already found a way to start the debugger on the compilation of the module PacAPI (by using menu Dev->Compile on the focus source text) and then stepping through the source.

That way so far I found out where in the source the empty PacAPI.ocf file is written:
The empty file is written at the end of
- DevCPE.OutCode in
- DevCPM.RegisterObj which calls
- objFile.Register(name, Kernel.objType, Files.ask, res) which calls
- HostFiles.File.Register which writes the empty file
(after having called HostFiles.CheckDelete, HostFiles.CloseFile and WinApi.SetFileAttributesW).

Probably not unexpected for those who know the compiler code, but for me it was quite adventurous to trace the spot!

Still, to find out why the file remains empty I will have to delve/step deeper into the sources of the compiler modules and compare with situations where the problem doesn't occur...

--
Hans

Re: Error message under Wine when installing Pac Converters

Posted: Mon Jul 02, 2018 3:51 pm
by Josef Templ
When you look at the file object, is it really empty?
Please check the .len field of the HostFiles.File object.

Regarding the automatic unloading of modules when executing a commander:
If this is always the case when executing a commander, there seems to be a problem with
detecting the modifier (Ctrl) key under MacOS/wine.

- Josef

Re: Error message under Wine when installing Pac Converters

Posted: Tue Jul 03, 2018 7:43 am
by HansKlaver
You're right: at the time the empty file is registered (and becomes visible in the Finder of macOS) the .len field of HostFiles.File object f^ is 24688 !
I checked the size of (Pac)API.ocf, and this normally is 24688 bytes. So the problem is not caused at the time of registering the file, but earlier in the code.
Regarding the automatic unloading of modules when executing a commander:
If this is always the case when executing a commander, there seems to be a problem with
detecting the modifier (Ctrl) key under MacOS/wine.
Interestingly now I can't reproduce the automatic unloading anymore, but it did happen under certain circumstances some days ago, and then I also noticed that using Ctrl-K to start the compiler did not work. So maybe the Debugger does something with the keyboard buffer?

--
Hans

Re: Error message under Wine when installing Pac Converters

Posted: Tue Jul 03, 2018 9:47 am
by Josef Templ
HansKlaver wrote:You're right: at the time the empty file is registered (and becomes visible in the Finder of macOS) the .len field of HostFiles.File object f^ is 24688 !
I checked the size of (Pac)API.ocf, and this normally is 24688 bytes. So the problem is not caused at the time of registering the file, but earlier in the code.
Hans
Is the garbage collector called while compiling this file?
Set a breakpoint to Kernel.CallFinalizers after starting the compile command.
If it is hit while compiling the file, it would be interesting if the code file object is finalized,
which of course would be an error.
Alternatively, you could also set a breakpoint at HostFiles.FINALIZE, which is the finalization
procedure called when a file object is deallocated from the heap.

Note: if you add debugging code to HostFiles, you must relink the exe file.
You could use module Console for low-level output.

- Josef