Execution Contexts

Moderators: Klaus, FourthWorld, heatherlaine, kevinmiller, LCMark

mickpitkin92
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 226
Joined: Tue Jun 30, 2009 11:15 pm
Location: North East England, United Kingdom

Re: Execution Contexts

Post by mickpitkin92 » Thu May 02, 2013 9:35 pm

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.
Currently working on the Nix Operating System, an operating system that runs atop of Windows and Mac with the goal of providing an alternative to those systems without having to leave them whilst providing the features of a standard OS.

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 2695
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: Execution Contexts

Post by mwieder » Thu May 02, 2013 10:09 pm

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

mickpitkin92
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 226
Joined: Tue Jun 30, 2009 11:15 pm
Location: North East England, United Kingdom

Re: Execution Contexts

Post by mickpitkin92 » Thu May 02, 2013 10:16 pm

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.
Currently working on the Nix Operating System, an operating system that runs atop of Windows and Mac with the goal of providing an alternative to those systems without having to leave them whilst providing the features of a standard OS.

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 2695
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: Execution Contexts

Post by mwieder » Thu May 02, 2013 10:33 pm

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
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 2695
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: Execution Contexts

Post by mwieder » Mon May 06, 2013 5:28 pm

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
Livecode Staff Member
Livecode Staff Member
Posts: 996
Joined: Thu Apr 11, 2013 11:27 am

Re: Execution Contexts

Post by LCMark » Tue May 07, 2013 10:24 am

@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
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 2695
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: Execution Contexts

Post by mwieder » Tue May 07, 2013 5:00 pm

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
Livecode Staff Member
Livecode Staff Member
Posts: 996
Joined: Thu Apr 11, 2013 11:27 am

Re: Execution Contexts

Post by LCMark » Thu May 09, 2013 10:44 am

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
Posts: 225
Joined: Fri Jul 28, 2006 12:23 am
Location: Albuquerque
Contact:

Re: Execution Contexts

Post by DarScott » Sat May 18, 2013 7:08 am

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

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 2695
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: Execution Contexts

Post by mwieder » Sat May 18, 2013 11:10 pm

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
Posts: 225
Joined: Fri Jul 28, 2006 12:23 am
Location: Albuquerque
Contact:

Re: Execution Contexts

Post by DarScott » Sun May 19, 2013 3:44 am

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
Posts: 225
Joined: Fri Jul 28, 2006 12:23 am
Location: Albuquerque
Contact:

Re: Execution Contexts

Post by DarScott » Sun May 19, 2013 4:01 am

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

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 996
Joined: Thu Apr 11, 2013 11:27 am

Re: Execution Contexts

Post by LCMark » Mon May 20, 2013 11:35 am

@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
Posts: 225
Joined: Fri Jul 28, 2006 12:23 am
Location: Albuquerque
Contact:

Re: Execution Contexts

Post by DarScott » Mon May 20, 2013 9:04 pm

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
Posts: 225
Joined: Fri Jul 28, 2006 12:23 am
Location: Albuquerque
Contact:

Re: Execution Contexts

Post by DarScott » Mon May 20, 2013 9:49 pm

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.

Post Reply

Return to “Engine Contributors”