Interpreter awareness of current FunctionDef?

Development
1

Quick question, probably for @VIRTUALDOG (or anyone familiar with interpreter internals) –

Does the interpreter know which Function or FunctionDef object is the source of the byte codes being executed at that moment? We have thisFunction which might be enough, unless it has glitches in places.

There was just a thread on the user list about nowExecutingPath and scheduled functions. Currently, nowExecutingPath is available only synchronously – it’s cleared after the code block returns, and there’s no way to recover it automatically within scheduled functions. (We can save the path in a variable in the synchronous part of the code, and use it in a scheduled function.)

(
thisProcess.nowExecutingPath.debug("sync");
{ thisProcess.nowExecutingPath.debug("async") }.defer(0.01);
)

sync: /home/dlm/share/SC/scd/tests/execpath.scd
-> a Function
async: nil

If the interpreter can track back to the active FunctionDef object, then it would be possible to improve on this:

  • For every FunctionDef created within a synchronous block of code, save nowExecutingPath in a new member variable.

  • Then, thisProcess.nowExecutingPath could be replaced by a special byte code to access this variable. thisFunction seems to be always a Function, and its def is either a FunctionDef or a Method object. Method has filenameSymbol but FunctionDef doesn’t – but if it did, then I think we could always get the executing path from it.

Just wondering how hard that would be.

hjh

2

There is a thisFunctionDef, is that your question?

I don’t think the filename in which a function/functiondef is compiled is always stored… not sure.

Is the goal to make nowExecutingPath valid everywhere?

3

I think what you could do is move the filenameSym member from PyrMethod to PyrBlock, then record gCompilingFileSym every time you instantiate a PyrBlock (like we currently do for PyrMethod). then the way to find nowExecutingPath is with thisFunctionDef.filenameSym… I think? I don’t remember if anything else was brought up in past discussions but I do remember it seeming more complicated than that.

4

It definitely isn’t, at present.

Yes, the idea is to make the current path available as much as possible.

It seems a reasonable plan. I think the thisFunctionDef access could not be in a nowExecutingPath method though, because then the current function def is that method rather than the caller. Solvable problem.

Past discussions were about printing file paths and line numbers for errors. Line numbers would be very hard, but my thought now is not about that.

hjh

5

yep! we can query the caller’s function def using Object:getBackTrace.

ahh okay.

do you want to file a ticket for this?