Talk:Nasal Maintenance

From FlightGear wiki
Jump to navigation Jump to search

Inspecting the runtime environment

I don't think that we can "inspect a complex runtime environment" right now but I have a couple ideas... I have an idea for overloading f_call/naCall that will allow any function calls within there to be checked for timing: one callback for a FCALL et al. (which would accept a form of the bytecode stack and current ip) and another for a RETURN. As inspecting the opcodes is illegal for the VM, I ship it off to Nasal and my decompile function to get the lvalue/function. I also have an idea for (possibly another argument to call) of being able to catch a runtime error and inspect the local hash, etc., so that debugging would not involve lots of print statements -- as all the variables would be visible on an error. Maybe also fixing up f_call to not use naCall should be on the list as well.

Neverminding those digressions, I think what I would like to see get done is the code to manage the library. That would allow me the chance to write an article on parsing and Tokens (which will be within my reach now) and also as a tool for others to get tons of information on a short snippet. There should also be a "inspect.nas" to type commands into or pass arguments to and get better-formatted results, e.g. a nicely formatted (possibly LaTeX) bytecode dump.

This unsigned comment was added by Philosopher (Talk | contribs) 20:56, 31 January 2014‎ (UTC)

Sorry missed the private stuff - was just skimming when cleaning up my inbox, and wanted to preserve useful stuff that way. --Hooray (talk) 03:53, 1 February 2014 (UTC)
S'ok, was just comments that didn't need to be front-page/weren't relevant out of context. But it is a good idea, particularly if others would like to look into it, and for when I return to it. However I'm actually really busy with RL right now... infeliciter non sum otiosus —Philosopher (talk) 04:30, 1 February 2014 (UTC)

Listener Objects (zakalawe)

tracking down problematic Nasal code

Just so that you know, we've been tossing around some ideas to provide better runtime inspection means for callbacks running via listeners or timers - basically, it should be possible to provide new extension functions that return the current state of things, including file name, line number - and optional identifiers. This would then also allow us to run the equivalent of systime() to see how much time is spent in each callback, and sort them accordingly - analogous to ThorstenB's performance monitor, just specific to Nasal-space callbacks.

Philosopher has done quite a bit of work related to this, and while most of it is much more sophisticated, we could reuse a portion of it, to pull this off