1.1.0 - Thirty-two bits, packages that ask nothing of the IDE, and a defect the accelerator hid from its own tests

Thirty-two bits, a package that asks for nothing from the IDE, and a defect the
accelerator had been hiding from its own tests.

The occasion was not ours. The maintainer of the Online Package Manager built
the catalogue version, could not, and wrote down five reasons. All five are
closed. Looking into them turned up as many of our own, all in the same place:
targets we never built, so nothing there was ever checked.

The packages no longer ask for the LCL

crosspascal_parser and crosspascal_parserjit are built with NOFORMS and
NOGRAPHICS, and neither declares the LCL any more. A console program links
against them with nothing else in its uses clause: no Interfaces, no
widgetset. That was the maintainer's fourth and fifth findings, and before this
release not one of the eight documentation samples linked.

Two features step aside for it. Thread used to route an exception raised in a
worker through Application.HandleException, and BlobManager stores images as
TGraphic. Both stand behind those defines. If you want them under Lazarus,
drop the defines from packages/lazarus/crosspascal_parser.lpk and add the LCL
to its required packages; nothing else about the package changes.

Delphi is untouched by any of this. It builds from the sources, where neither
define is set and TGraphic is the VCL one.

Thirty-two bits

Windows i386 joins win64 and linux64, on both compilers. The whole battery runs
there: sixteen test programs on Free Pascal 3.2.2, the documentation samples,
and the packages themselves.

It is a separate installation of the compiler rather than a switch. Free Pascal
refuses to target i386 from a host whose Extended is a Double, and on Win64
it is.

Getting there took two fixes in the library. Five loop counters in
BlobManager were Int64, which i386 does not accept in that position; they
are NativeInt now, while the fields whose value goes into the stream stayed
Int64 so the blob format does not shift. And the value record came out at
twenty bytes instead of twenty-four, with the payload four bytes in rather than
eight - see below.

The accelerator got the order wrong after a function call

Reading the right operand of an operator consumed the rest of the term instead
of a single step whenever that operand was a function call. So 6 / cos(x) / 16
was evaluated as 6 / (cos(x) / 16), and x / sqr(y) * y as
x / (sqr(y) * y). Only a call on the right was affected: with a variable or a
constant there the fold stayed left to right, which is why it went unnoticed.

On x86-64 the machine code generator takes such formulas and the generator is
right, so the wrong answers appeared only where there is no generator at all -
which, until this release, was a target we did not build.

Checked by comparing three thousand random formulas against the interpreter on
Delphi win32 and win64, Free Pascal 3.2.2 on win64, i386-win32 and linux64, and
Free Pascal 3.3.1: zero disagreements.

The check that should have caught it was comparing nothing

The differential fuzz skipped every formula the accelerator declined. Off
x86-64 it declines every formula there is, so the check reported three thousand
compared and zero disagreements while comparing none of them. It now reads the
level off the interpreter counter, and the floor it guards means something
again.

The value record is the same size everywhere

TValue is twenty-four bytes on every target now, with the payload at offset
eight. The compiled script format carries that record verbatim, so a script
built on 64 bits would not have loaded on 32. The directive meant to keep the
layout identical sets a limit on alignment rather than a size, and on i386
nothing in the record asked for eight; it is padded out explicitly instead.

The package no longer hands you a unit under a name the system uses

Outside Windows the parser needs a stand-in for Messages, which otherwise
comes from the LCL. That stand-in was reaching consumers on Windows too, where
the runtime has a unit of that name - and standing in front of it. A project
that used both this package and the LCL stopped with a message naming a unit it
could see. The stand-in is now added only where the system has no such unit.

Installing the accelerator no longer rebuilds the parser

The accelerator package listed the parser's source directory and rebuilt
forty-one of its units into a second output directory of its own. The two sets
then disagreed, and a sample that used both stopped on a unit that was lying
right there. It uses what the parser package built, as it was meant to: six
units instead of forty-seven.

Projects for the samples

The eight programs under samples/docs now come with .lpi files. Open one in
Lazarus and build it - that is the whole recipe. They were written earlier but
never reached a release: the slicer did not carry the extension, so they existed
and travelled nowhere.

There are deliberately no .lpr copies. A copy of the program text is a second
source, and it drifts.

Compatibility

Delphi	37.0 (Delphi 13), win32 and win64
Free Pascal	3.2.2 and 3.3.1, win32 and win64 and linux64

Every line of that table is a matrix that runs before a release.