*** Warning v3.0 May Break your Channel ***

Archived
1

I want to send out another plea to regression test your channels on v3.0. BrightScript v3.0 is much stricter about syntax than it was in v2.9 and many channels now crash where before they didn’t. There are other incompatibilities as well…

There’s one change I’ve had to make in about a dozen channels so far and want to warn you to check your code for it. Anywhere that you may be checking the type and comparing it to the value “roString”, you should also compare to “String” as this is a new v3.0 type.

Old code:


if type(b) = "roString"

New code:


if type(b) = "roString" or type (b) = "String"

–Kevin

2

This is the kind of info that would be perfect on the new dev blog. :slightly_smiling_face:

3

I believe there’s also a new “Integer” type (in addition to “roInt”).

4

I think even on 2.9 there are cases where you will see type =“roInt” and other cases where type is “Integer” and a few other weird things like that, which I have already had to handle. Don’t remember if there is an “roInvalid” but I think I have seen that at least once…

  • Joel
5

Yes, had to update one line of one channel to check “roInt” as well as “roInteger”, also, the USB channel code for 2.9 doesn’t work on 3.0 firmware - so the 3.0 SDK has working/fixed code for it.

6

If you ‘downgrade’ the firmware to 2.9, then you can’t get 3.0 firmware again?

7

Hi I have got a problem with the box breaking for v3.0 build 2202

To do this all I have to do is to download an app via the debug to the box, when it crashes (probable because there is a bug in the code)

The box then restarts it self

next I then try to loading one of the channels (say Vimeo or some another one) the app loads ok, but then when it gets to the point where the video starts to load, the box then crashes.

Post note;
The only way I have found to fix this problem is to unplug everything from the box (HDMI + Ethernet + power) and then plug every thing back in again. Just unplugging the power doesn’t work!

8

Kevin, can you verify that it’s not just strings that are affected? If so, can you document the types that are affected and what the changes are?

I have found many instances of the type operator being used to affect control flow, e.g. if( type(childStatus) = “Integer” ) … We need a precise list of what’s changing so that we can touch each instance of the type operator.

9

It’s not just strings that are affected by this issue. It’s any intrinsic type that can be autoboxed… Including
Integer, roInteger
Float, roFloat,
String, roString
Boolean, roBoolean
Double, roDouble

–Kevin

10

Others may find this useful:

function typeNormalize(incomingType)
   if( incomingType = "Integer" ) return("roInt")
   if( incomingType = "Float" ) return("roFloat")
   if( incomingType = "String" ) return("roString")
   if( incomingType = "Boolean" ) return("roBoolean")
   if( incomingType = "Double" ) return("roDouble")
   return(incomingType)
end function

Call it like:

if( typeNormalize(type(foo)) = "roInt" ) return
11

Might make more sense to simplify that to a single function call, instead of a nested one… like:

function typeNormalize(incoming as Dynamic)
   incomingType = type(incoming)
   if( incomingType = "Integer" ) return("roInt")
   if( incomingType = "Float" ) return("roFloat")
   if( incomingType = "String" ) return("roString")
   if( incomingType = "Boolean" ) return("roBoolean")
   if( incomingType = "Double" ) return("roDouble")
   return(incomingType)
end function

Then just:

if( typeNormalize(foo) = "roInt" ) return
12

Wouldn’t it make more sense to do the renaming internally to retain compatibility with more channels, rather than requiring every channel to be tested? Mine work now, so it wouldn’t affect me, just thinking of anyone who doesn’t frequent the forums who wrote a channel before.

13

“destruk” wrote:
Wouldn’t it make more sense to do the renaming internally to retain compatibility with more channels, rather than requiring every channel to be tested? Mine work now, so it wouldn’t affect me, just thinking of anyone who doesn’t frequent the forums who wrote a channel before.

I agree with destruk. Software should always maintain backwards compatibility unless it is impossible to do so and the thing that makes it impossible is absolutely compelling. In a symbiotic relationship that Roku has with it’s developers, I would have thought that maintaining channel functionality would been more important.

14

When v.3.0 are going to be rolled out to all Roku boxes?

When I check firmware version on my box I see v.3.0 but I have not asked for update. Does it mean that now other people also have v.3.0 and I can use 3.0 features in my code?

15

I believe 3.0 has been rolled out to everyone with a Roku 1. Roku 2 boxes are on 4.0, so 3.0 features should work for everyone.

-JT

16

At the https://owner.roku.com/Developer/DevHome it still returns 2.9 documentation.
And also on this forum, there is not clear indication, that 3.0 is in production now.
Somebody from Roku, please comment. Thanks in advance!

17

I’m not from Roku, but Roku officially began rolling 3.0 to all users on October 12th, 2011 (and by now Roku1 should have it). See here for the announcement:
viewtopic.php?f=28&t=44421

The public sdk for 3.0 and above is still considered beta, but the documentation and examples should be used instead of 2.9 (as this thread indicates, 3.0 has stricter syntax, and there are new features available). Roku has sometimes been a few months behind getting the sdk out, after a firmware release. They’ve also been adding new staff(to help improve user, tester and developer support) that all have to be brought up to speed first.

18

Thank you for the information!

19

“RokuKevin” wrote:
It’s not just strings that are affected by this issue. It’s any intrinsic type that can be autoboxed… Including
Integer, roInteger
There is no “roInteger”, is there? Other than one place in the docs:
“BrightScript 3 Compatibility” wrote:

  • Container components now store intrinsic typed values, not an auto boxed values. In other words, a=[5] will store an integer 5 in an array, not an roInteger component. This change causes less memory to be used, and execution to be faster.
    For better or worse, boxed Integer seems to be “roInt”
BrightScript Debugger> ? createObject("roInteger")
invalid
BrightScript Debugger> ? createObject("roInt")
 0

PS. Wait… whaaaaat? What magic is this

BrightScript Debugger> i = 42
BrightScript Debugger> arr = [i]
BrightScript Debugger> j = arr[0]
BrightScript Debugger> ? type(i), type(j)
Integer          roInteger

What’s the difference between roInteger and roInt?
And documentation above just said “a=[5] will store an integer 5 in an array, not an roInteger”?