[Gambas-user] Arch Version 3.18.4 issue with bytecode version

[Brian G]

On 1/2/24 11:15, Brian G wrote:
>
> On 1/2/24 06:13, Benoît Minisini wrote:
>> Le 02/01/2024 à 01:59, Brian G a écrit :
>>>
>>> On 1/1/24 16:10, Brian G wrote:
>>>>
>>>> On 1/1/24 15:41, Benoît Minisini wrote:
>>>>> Le 01/01/2024 à 23:40, Brian G a écrit :
>>>>>>>
>>>>>>> Can you send me the package that includes the program that 
>>>>>>> raises the "bytecode too recent" error?
>>>>>>>
>>>>>> Yes I can Send the package, In the mean time I cloned the 
>>>>>> repository to a Archlinux system and built new packages on the 
>>>>>> 3.18.4
>>>>>> system and then installed it everything runs fine with that.
>>>>>>
>>>>>> As expected.
>>>>>>
>>>>>
>>>>> I understood. The requested bytecode version is not taken into 
>>>>> account when the packager commands are run, as this feature is 
>>>>> based on an environment variable.
>>>>>
>>>>> As a temporary workaround, you can define "GB_PCODE_VERSION=3.18" 
>>>>> -before- running the IDE and then make the packages from that IDE.
>>>>>
>>>>> Regards,
>>>>>
>>>> OK, will give it a go.
>>>>
>>>> Thanks Benoît
>>>>
>>>>
>>>> ----[ http://gambaswiki.org/wiki/doc/netiquette ]----
>>>
>>> Ok, that works just fine, the correct byte code is generated.
>>> But takes me down a bit of a rabbit hole!
>>> The app image works correctly, but loads plugins that were cached, 
>>> built with the new pcode.
>>>
>>> Maybe the scripter should be also checking the pcode version of 
>>> cached scripts/plugins
>>>
>>> Oh well the world is not perfect ;)
>>>
>>> arch and appimage work correctly now on fresh installs.
>>>
>>> Is there a way to check the pcode version of an lib/comp/plugin 
>>> before they are loaded?
>>>
>>
>> Can you try the last commit? Now the bytecode version is a compiler 
>> option ("-b"), so the packager will take it into account without the 
>> previous workaround.
>>
>> You will be able to use that new option in the scripter too if you like.
>>
>> Regards,
>>
> Ok Will give it a go this afternoon
>
>
> ----[ http://gambaswiki.org/wiki/doc/netiquette ]----

Thinking of Working on the update to scripter to support this, looks like an interesting idea if one wants to verify a script/project
can be run by different versions of Gambas byte code. Perhaps a #Script Bytecode=nn.nn to limit to higher level versions if
certain types of instructions are used. example calculated goto and gosub or @a = 100 etc within a script. In most cases I am not
sure scripts care if they use certain byte codes unless they use newer constructs than the current level and may be used in older environments.
That's A nice thing about scripts they are pretty portable across release versions. And when a script is converted to a project it can clearly set the correct
bytecode version for the script being executed.

Also in converting a project to a script the byte code version of the project would convert to #Script ByteCode=

Not sure of the use cases for forcing a script to a lower version, Are there possible uses when a project is converted to a script that there are old style gambas statements
that are no longer supported by the latest version of compiler?

unless it somehow ties into depreciated components.... umm.

Is it useful?

The #Script ByteCode= will cause a clear error in older scripter versions, clear indication of conflict, going forward allows a check.

-b option is already used in scripter buildonly same meaning as compile only to check for errors and make .gambas executable

Could add a -B --bytecode option to scripter  or move the -b option to -B

Is there a way of asking the compiler for a list of supported BYTECODES, so it is not hard coded in gbs3/gbw3?

Question is there a way for scripter to check the byte code version of cached scripts before execution, or perhaps it should add an extension to the
cached script like myscript.3.8.gambas(going forward) or some similar thing to identify bytecode version.
This is useful if one upgrades or downgrades gambas and scripter can then discard the cache and recompile again.

Comments?

-- 
~~~~ Brian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x78BFB26402F48419.asc
Type: application/pgp-keys
Size: 2428 bytes
Desc: OpenPGP public key
URL: <http://lists.gambas-basic.org/pipermail/user/attachments/20240102/a1ba3fa4/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://lists.gambas-basic.org/pipermail/user/attachments/20240102/a1ba3fa4/attachment.sig>