Roku Developer Program

[EnTerr]

Say B/S code breaks into console with error like

Member function not found in BrightScript Component or interface. (runtime error &hf4)
   or
Function Call Operator ( ) attempted on non-function. (runtime error &he0)

How do i continue/recover from that? Continue/Step/Over won't do presently, they complain "Can't continue".

Seems to me a very reasonable expectation to be able to continue. Maybe the statement where error occurred gets skipped, or maybe re-tried (after presumably massaging the issue to disappear). Perhaps add new command or "fix" the previous so they don't object with "can't continue"?

[adamkaz]

I know that "exit" seems to back out of the current function and keep working. I recently discovered this in scenegraph, not sure if it applies everywhere.

YMMV.

[EnTerr]

"adamkaz" wrote:
I know that "exit" seems to back out of the current function and keep working. I recently discovered this in scenegraph, not sure if it applies everywhere.
YMMV.

"Exit" (or Q) is said to exit the shell - and in my practical experience exits the app too. I just tested and indeed, when issued in main thread console (8085), app is terminated. I am befuddled as to why in SG thread quitting console would continue instead.

I did find a 1/4-ass option, issuing a "return" statement from console. That exits the topmost frame/fn and continues exec. It has issues, however - in that exiting the app later (e.g. with Home) crashes the player. So it's a bit like using laxative - it may help but can't promise enjoyable experience

[RokuKC]

"EnTerr" wrote:

"adamkaz" wrote:
I know that "exit" seems to back out of the current function and keep working. I recently discovered this in scenegraph, not sure if it applies everywhere.
YMMV.

"Exit" (or Q) is said to exit the shell - and in my practical experience exits the app too. I just tested and indeed, when issued in main thread console (8085), app is terminated. I am befuddled as to why in SG thread quitting console would continue instead.

I did find a 1/4-ass option, issuing a "return" statement from console. That exits the topmost frame/fn and continues exec. It has issues, however - in that exiting the app later (e.g. with Home) crashes the player. So it's a bit like using laxative - it may help but can't promise enjoyable experience

Exiting from any of the SG consoles semantically should exit the app, but the SG render + task consoles are not unified currently.
That will be addressed in a future firmware release.

If entering 'return' in the debugger is continuing execution after a fatal error ("Can't continue"), that's a bug. I'll file a ticket for it.

Also, feature request noted for wanting to continue manually after a "fatal" error for debugging purposes.

[EnTerr]

"RokuKC" wrote:
If entering 'return' in the debugger is continuing execution after a fatal error ("Can't continue"), that's a bug. I'll file a ticket for it.

No, nooooes!
Do not deprave us from the only way (1/4-ass but still) to continue execution. Return continuing is not a bug from OUR point of view - it's a feature. The crashing at the end is a bug but can live with the laxative effect if not easily fixable. Don't be like the "deaf genie granting wishes", guys 😛

Also, feature request noted for wanting to continue manually after a "fatal" error for debugging purposes.

If easy enough do. Regardless if it will try to execute the failing statement again - or continue from the next... "whatever's clever". Since single B/S statement compiles to multiple bytecodes, i can imagine it hard to figure where to jump forward or rollback to, so you know - if can't, can't.

[RokuMarkn]

We would not only have to determine what statement to resume at, we'd need to undo any partial action take by the aborted statement so the program state is as it should be at the start of the statement. Without having given it a lot of thought, this seems fairly difficult to me.

I'm curious about the use case for this feature. I would not expect most of my programs to do anything useful if an arbitrary statement were skipped. I also don't understand the idea of "fixing" something so that the statement can re-execute. What sort of thing would you fix to allow the statement to behave differently the second time?

--Mark

[EnTerr]

"RokuMarkn" wrote:
I'm curious about the use case for this feature. I would not expect most of my programs to do anything useful if an arbitrary statement were skipped. I also don't understand the idea of "fixing" something so that the statement can re-execute. What sort of thing would you fix to allow the statement to behave differently the second time?

RokuMarkn - debugging.

Totally not for production purposes, i.e. not asking for BASIC's "on error resume next" statement. Does not have to be transactional. Since it is not for production, quirks like "not guaranteed if variable was set or not" can be tolerated because "i, the human" am behind the console and can adapt/do manual steps. For the same reason "side effects" like player-reboots-on-app-exit may be tolerated - it's the "lesser evil".

My specific case was because somebody has yanked silently a pre-existing, pre-documented component method call from 7.2 (earlier this week i sent a fiery email to dev.support on breaking my published app, so details be known), leaving me at

Member function not found in BrightScript Component or interface. (runtime error &hf4)

Say it was "comp.call(x)" what failed - if debugger's (C)ontinue were to replay that command, i could patch in console as simple as "comp = {call: function(x): end function}", press C and plow ahead (reminder: i am the developer, i can judge what can be circumvented in my code)

I consider what i asked a "nice to have" feature, for developer's convenience. Not a "must have".

PS. lest someone say "you dolt! just edit out the offending code, re-zip and re-deploy", there are... complications. It's not a zip. It's a hybrid app. I have changed my tooling/SDK from say 8.2.1 to 8.4. Way too many moving parts, while i was trying to figure the reason for my app to break - for which i take the cramfs for my "GM" build that got published and side-load it to a player, it breaks in console and then i want to make it continue to see if there are other things that 7.2 broke. Of course i would do proper end-to-end build later but at first i want to aim at a static and not moved target.