Execution Contexts

[SirWobbyTheFirst]

Ah yeah, good point. That might be why I used -2 then. I must have thought about that when initially writing the code back then.

[mwieder]

It's still possible to get into trouble with a badly-named behavior object, but I think the risk is much lower.

[SirWobbyTheFirst]

Well the function is great for the current scenario, plus I think I would probably have to modify it extensively for other components as some of the components I have in mind have to do with things like session management which is different security wise from what the kernel does. But nonetheless I will keep your code in mind if I do something and behaviours may get involved.

[mwieder]

Well, I like the idea and I think it may have a wider application in terms of replacing the missing password protection in the community edition.

[mwieder]

Don't you have this information already? You get a 'trace' message before a line of script is executed, so that would be the context before the next line, and after the previous. (I might be misunderstanding what you mean, of course...)

Just realized I never responded to this... I'd like to get a notification before a line of code gets executed without the overhead of dealing with a trace message (this has repercussions with breakpoints, the traceuntil, tracereturn, etc messages) so that I can implement code profiling with minimum impact on processing speed. Right now in order to do profiling I have to do the equivalent of setting a breakpoint at each line of code and go through all the normal breakpoint processing except for displaying the debugger.

This has two problems: a *very* noticeable impact on execution speed and the complexity of setting up and tearing down profiling mode.
With a notification separate from a trace message I could mitigate both problems.
I'm thinking something like the way messagemessages allows messages to be thrown would do the trick.

[LCMark]

@mwieder: Ah, of course! I see what you mean now. This would actually be really easy to do - MCB_trace() is invoked at all the places commands are executed... Looking at the code though (MCB_trace), if MCtrace is true and MCtraceuntil is MAXUINT2 then all that happens is a 'trace' message is sent, breakpoints and such don't get a look-in. (I dimly recall many years ago Richard posting about a profiling tool based on 'trace' that used to be in the MetaCard IDE - I don't think the underlying debugging feature-set has changed much since then).

[mwieder]

I'm doing rudimentary code profiling and code coverage now, but it's all built into the debugger and triggered off the trace message. It's slow and ugly.
[Edit]: what I mean is that by setting the proper combinations of traceuntil, tracereturn, and traceabort I can get "trace" messages to occur on every executing line. But it's far from an ideal solution.

I think I'll bring this as my pet project to the engine dev session at the conference. Maybe we can find some nifty way of pulling this information out without affecting execution speed too much.

[LCMark]

I think I'll bring this as my pet project to the engine dev session at the conference. Maybe we can find some nifty way of pulling this information out without affecting execution speed too much.

Sounds like a good pet project. It would be relatively straightforward to add something to the engine that could collect timing/call count data for each line of script - more than happy to discuss with you at the conference

[DarScott]

A caller() function should be usable in libURL and in handlers specified in open language definitions.

[mwieder]

Dar- can't you just extract the caller information from the execution contexts as is? Or do you have something more serious in mind?

[DarScott]

Hi, Mark! I do currently extract caller information from the execution contexts. However, this does not work in a substitute libURL; a new context is created and that info is not there. And if it does not work there, there is a chance it might not work in upcoming things related to open language; those might be implemented in a similar manner. So, if something such such as caller() is defined, then it doesn't have to carry the cloud of being subject to change. And when new things or special cases come up, then the function can be changed to still work.

So, if there is a function caller(), whether some script handler based on execution contexts or some engine function, it would be good if it worked for libURL and open language handlers.

[DarScott]

By libURL, I mean the handlers for implementing GET URL and so on whether in that library or not.

[LCMark]

@DarScott: There's no issue adding a 'the caller' piece of syntax. We added 'do ... in caller' a while ago and there's a nice synergy there. In terms of the call-stack not being visible from within libUrl then that's something which could be resolved now. I'll have to check why exactly, but it is probably that the exec-point chain isn't being maintained.

Moving forward to 'Open Language', what information will be available to a native code extension and a LiveCode script extension when a syntax-wrapped method is called will be the same (although accessed through syntax in the latter; rather than a method call on the ExecContext object in the former).

[DarScott]

If the executionContexts behaves as expected with liburl and open language handlers, then an engine version of caller() is not as important. However, as Mark mentioned, the concept of "caller" has been established in the language; the conceptual cost is low in adding the function (or property). It can be added. It would be nice if the cloud over executionContexts could be removed, though--if caller() is not created--and documentation be sufficient for folks to see how to make caller() or it uses caller() as an example. I don't think that the script for caller() should be something known mostly among the priesthood. Also, it is awkward for me to disclose to customers, "this library uses unsupported features of LiveCode".

[DarScott]

I made a mistake. The documentation does not say the executionContext is unsupported. It has this caveat:

Important: The value of the executionContexts may be changed in future versions of LiveCode, it is not recommended to write code that depends on its contents.

The special case of parent scripts that some have mentioned should also be in the documentation.