wouldn't the eval() of your code cause the same overhead as when you initially load the channel ?
I know I have a large package and this would be too much.
Eval() does spend time on compiling the code first of course - moreover eval() "leaks" memory on repeat invocations (allocating new space for bytecode - so don't call it 1e38 times). But if you execute most of the code with a Run() from a "lightweight" main, the channel would start faster and you can show new splash screen before invoking Run() and the lion share of loading has started. The total load time will be the same but channel can be made seem faster to start. Note, the rest of the program will have to be stored in files with extension != .BRS
I would like to see some sort of display, maybe the function module and line number with error that the user could send.
We as developers have no idea if our channels are even functioning unless someone emails us a problem.
It is unfortunate that currently GetLastRunRuntimeError
() only returns a numeric code but no file/line info. That can easily be fixed if it is extended akin to GetLastRunCompileError
(), so that when optional param is passed it will return key/value AA instead:
' extended signatures
function GetLastRunRuntimeError(verbose=false as Boolean) as Object
function Eval(code as String, verbose=false as Boolean) as Object
' fictitious/desired behavior - note Eval() by definition returns GetLastRunRuntimeError()
> e = eval("? 1/0", true)
> ? type(e)
> ? e
ERRSTR: Divide by Zero.
This way we'll get the file/line info (and why not stack dump - fancy future) - while it is easy to implement and consistent with language design so far.
Any consideration of this, RokuMarkN?