[m-rev.] for review: read and write bitmaps in bitmap.m

[Julien Fischer]

On Sun, 6 Mar 2022, Zoltan Somogyi wrote:

> 2022-03-05 21:14 GMT+11:00 "Julien Fischer" <jfischer at opturion.com>:
>>> The code it complains about has a reference to MR_MercuryFileStruct
>>> a few lines above. It finds that ok, but not MR_Binary{In,Out}putFile,
>>> which are defined soon after MR_MercuryFileStruct in io.m. All are public classes.
>>
>> References to them in the bitmap module will need to be qualified, e.g.
>> jmercury.io.MR_BinaryInputFile etc.
>
> I saw that some nearby references were qualified only with "io.", not
> "jmercury.io.", so I tried that first, and it worked. A bootcheck in the Java
> grade has finished with 259 unexpected failures,

Quite a lot fo them seems to be due to the fact that in the invalid
directory,

      For more information, recompile with `-E'.

is not being printed at the end of the output in the Java grade for some
reason.

> and an "mmake install"
> that includes both the C# and Java grades also succeeded, albeit with
> some warnings. I am attaching the output of "mmake install". Please have
> a look, and decide whether any of the warnings are concerning enough
> for me to not commit this diff.

I can't see all of the C# ones as the complete list of warnings is written
to mer_std.errr.  From what I can see, the warnings are harmless.

The only warnings I can see for the Java grade are:

    ssdb.m:525: warning: Signal is internal proprietary API and may be
    removed in a future release sun.misc.Signal.handle(new sun.misc.Signal("INT"), new SigIntHandler());

which are normal.  (sun.misc.Signal is deprecated, but it's currently
the only way of handling signals in Java and until there is a
replacment, I don't think it's going anywhere.)

Julien.