[Gambas-user] Backward Compatibility with gambas versions added to wiki faq

Tobias Boege taboege at gmail.com
Fri Oct 9 09:23:19 CEST 2020


On Fri, 09 Oct 2020, Bruce Steers wrote:
> I do not know just "how" frequently this question is asked, but I asked it,
> I've seen others ask it too.
> So the wiki F.A.Q seemed a good place to put this info...
> 
> http://gambaswiki.org/wiki/doc/faq#t13
> 
> Please edit/add anything you think i missed. :)
> BruceS

As far as I (looked up and) understood the mail by Benoît, this is a
feature of the *compiler*, not of the runtime, right? The compiler
supports emitting multiple bytecode versions. The interpreter supports
running its own version and older ones, up to major version boundaries.

I would like to know what the failure modes of this feature are.
The options I can think of are:

  - If the differences are too big, the compiler may throw an error
    "can't compile this construct with that bytecode version".
    It will never compile to code that will not work and you get
    feedback immediately in the compilation process.

  - The compiler implements backward-compatible features as it
    normally would but only tags the file as the old bytecode
    version, causing the interpreter to potentially fail at runtime
    or silently misinterpret the code.

I think the second mode is inevitable because parts of Gambas are
too late-bound for the compiler to catch mismatches, but in those
cases at least the bytecode won't be incompatible, right?

What happens when the bytecode format changes locally, because the
encoding for the parameters of an instruction changes? Does that
just never happen in a minor version update because it's Benoît's
unwritten policy?

According to my casual observations, the bytecode format is treated
like an implementation detail and that makes reasoning about the
effect of that environment variable very hard. I would tend not to
recommend using it in an FAQ (but the wiki should list it somewhere,
maybe on a page about compiler/interpreter environment variables).

The recommended solution would be to recompile the project with your
own compiler. This is an even better solution than to upgrade your
Gambas to the version that the code author used -- unless the code
requires new features of Gambas, of course! But if your compiler
version is too low, the first, better failure mode will automatically
kick in and tell you if you need to update after all.

Gambas is not the only (byte)compiled language. Distributors who ship
binary packages of Gambas applications must compile it with the Gambas
that's currently in their repositories. Everybody else, who bypass
their package manager, need their own compiler and do the same:
recompile the project for their runtime version before they run it.
And they don't need the IDE for that, gbc3 -a suffices.

Best,
Tobias

-- 
"There's an old saying: Don't change anything... ever!" -- Mr. Monk


More information about the User mailing list