fw6.1: "FUNCTION defined twice... v30/bslDefender.brs"

Archived
1

Yesterday somebody messaged me about channel of mine, “it wouldn’t load (exited to the home screen) - is this a firmware bug or is it no longer available?”
I tried and it worked for me, remove/re-add also worked. Huh. Short story short, turned out problem happens on fw6 beta.

Luckily, i had the opportunity to side-load the channel on fw6.1 box and check the console:

*** ERROR compiling /pkg:/source/main.brs:
SUB or FUNCTION defined twice. (compile error &had) in /common/LibCore/v30/bslDefender.brs(44)
SUB or FUNCTION defined twice. (compile error &had) in pkg:/source/main.brs(1)

main.brs(1) is Library “v30/bslDefender.brs”

So apparently a new version of bslDefender has defined a function with the same name that i have - plus i had been gullible enough to think i can safely import v30/bslDefender.brs.

Things like that happen, sure. But RokuCo adding new names to a library should not break already working channels.
Is there something that can be done to avoid that? Yes, i think i have the solution: make the diagnostic of SUB/FUNCTION re-definition spit one of them new-fangled warnings:


Warning - SUB or FUNCTION defined twice: "RGBA"

AND keep the latter function definition, then continue compilation. This will ensure that even if new names pop up in common:/LibCore files, channels will keep running undisturbed - spare a warning on the console if someone is watching (bonus: warnings will coax developer into moving to a new name… eventually - and w/o disturbing execution).

2

FWIW, 6.1 is a beta firmware, in beta testing. This is exactly the kind of thing that’s supposed to be identified and fixed during the beta period.

3

Hi, this has been addressed and shouldn’t be an issue in 6.1 when released to the general public. All the functions will be properly prefixed with “df”.

  • Joel
4

“RokuJoel” wrote:
Hi, this has been addressed and shouldn’t be an issue in 6.1 when released to the general public. All the functions will be properly prefixed with “df”.
That will do it for this case, thank you.

Please consider the long-term solution proposed though: it will make sure library imports could not kill channels via name collision.

As things stand, paradoxically it is safer RokuCo adding an undocumented function to ifGlobal than to a library. User code defining a function (say “tr()”) may trump a system-global function with no error. Using “Library” however leaves one open to collisions and demands library maintainer diligence. I am contemplating whether to use Library at all in the future - probably should just include the code i need locally.