dynamic include - rt embedding - Bug found?

[benjamin-thomas.schreiber@…]

How about the try to do dynamic includes like:
#include $myFile[0]
Sure I know include is a compile-time problem.
This leads to the idea to embed/inject sub-code within a running script that runs in the current script's context/state.
I have a problem like this, where a user wants to tell me to use a customized code part to a running script. A kind of "controll script" - that is known during runtime. ( I want to do some script generator with a running script that can be stopped, changed and continue with the user change ) - it's something like a gui-test-sequence-designer...
If i have to include this controllscript in a function stub, then i have to start an execute-script but will loose the framework's context. All globals are gone, all states are gone, etc...

I think of some rt-env, like in ruby, where an interpreter can build up classes and messages during runtime.
Or think of php, there it's also possible over an eval a complete php scripting during rt. The AutoIt's eval is for vars and the execute is only for expressions - no chance to evaluate complete scripting parts within the running context.

First I thought I do something like:
---snip--
func myUsersRtFunc

; do something the user got...
; this also could be no function but a static code block

endfunc
---
After that a "dynamic include" would be fine, but - duh, sure it's a compile time directive...
Then I thought something like execute("userScript.au3") would work, but it's only for single expressions...

Current solution is to save my framework context and load it again, then re-generate the running script with loading back the context variables.

Alternatively it would be possible to save the context and let an interpreter run a second task with "Run", load the context into that executed script and let it work. The result of this script has to be interpreted within a "protocol" over the StdOutRead of the caller.

The user's sub-code may change framework globals, and have to save this context back, so the caller(the frame) can load it after call again... what a struggling =)

You see it's really tricky to do such stuff without basic autoIt support to that.

You know the AutoItDebugger ? It handles it by generating "controlpoint-wrap-calls" and "WM_COMMAND" as feedback. Ever thought to support debugging with a "trap" mode within the interpreter ? ( that would be a feature for a interpreter with runtime environment )

I want not open another ticket, but I dont know if this is a (small)bug - or a known or rejected issue (found no ticket related to it):

I started a timer that handles user requests (tcp) and handles the tray menu execution, blocked the script with a main-loop.
Now if I implement e.g. a tcp function that will use a call("funcx"), with funcx containing a sleep, then the timer stops to tick while the called function sleeps.
If I do it by a direct function call to funcx(), the timer continues ticking while the funcx sleeps. (thats what i wanted)
The problem is due my inlcude hierarchy the tcp-commands are implemented in "base includes", but the function that is to be executed is "above" the code where no include is possible because I would get a circular dependancy.
Maybe I did something wrong, but can you investigate this ? Or is it know that a call to a sleeping function stops timers ?

( My solution is to "listen" to a global variable and then let the script part with the main-loop and the funcx implementation execute funcx as soon as the variable is set to true. So there are workarounds )

[TicketCleanup]

Automatic ticket cleanup.

[Valik]

Too long, didn't read. The title says it all. AutoIt is a compiled language, there is no place for "dynamic #include" in AutoIt. Also I suggest you learn the language a little bit better and you should be able to design your own extension interface using existing functionality.

[anonymous]

You should read - and try to understand the issue, instead of just rejecting it.
The idea is really innovative and would solve many many problems people struggle around with. Just have a look into your forum...

Change the runtime over COM objects ? Execute sub-code within this context over this object ? Comeon ! How should this work without AutoIt providing an appropriate COM interface ? E.g use COM scripting with js ? yeah, more and more components, more and more struggling. What about debugging that com objects ?
All that is not practical without navive AutoIt running code !

Nevermind - you'll decide what happens to your product by yourself.
There are workarounds for this, but these are "not for the masses" =)

What about the "bug" with the timers ? Can you track this issue anyway of the rejection?

[Valik]

Replying to anonymous:

You should read - and try to understand the issue, instead of just rejecting it.

Alright, I read it. And it's still rejected.

The idea is really innovative and would solve many many problems people struggle around with. Just have a look into your forum...

It's not innovative. It's a convenience to solve a very narrow band of problems.

Change the runtime over COM objects ? Execute sub-code within this context over this object ? Comeon ! How should this work without AutoIt providing an appropriate COM interface ? E.g use COM scripting with js ? yeah, more and more components, more and more struggling. What about debugging that com objects ?

In most cases it's not necessary to execute a second script in the same address space as the parent script. Also, I'm not sure why you are mentioning COM as that seems totally unrelated.

All that is not practical without navive AutoIt running code !

Your definition of "practical" and mine are apparently drastically different. You apparently think it's okay to implement very niche features to solve a narrow band of problems and a lack of such a feature makes something "impractical" to do otherwise. I, on the other hand, would just do it using the tools available and move on.

Nevermind - you'll decide what happens to your product by yourself.
There are workarounds for this, but these are "not for the masses" =)

I don't really call creating a proper design that is capable of serializing and marshaling state information across process boundaries a "workaround". I call it the way this stuff is done in situations like this. You clearly have something along these lines already. If it's designed properly then it will be completely transparent or at least no less transparent than some magical silver bullet solution you expect us to introduce.

What about the "bug" with the timers ? Can you track this issue anyway of the rejection?

Read the last two points of the General Notes section of WikiStart. In addition if you find yourself asking "is this a bug" then you shouldn't be on here on the issue tracker with your problem at all.

[anonymous]

In most cases it's not necessary to execute a second script in the same address
space as the parent script. Also, I'm not sure why you are mentioning COM as that
seems totally unrelated.

you told something about "extension interface" - what is an extension interface ? The onliest extensions I know in AutoIt are COM-Objects. (​http://www.autoitscript.com/autoit3/docs/intro/ComRef.htm). I guess then you really meant a more basic coding way. Do you have any link or information about this technique you meant? It seems very interesting and sounds very flexible!

I don't really call creating a proper design that is capable of serializing and
marshaling state information across process boundaries a "workaround". I call it
the way this stuff is done in situations like this...

Yes, you're totally right, in 99% of all cases it seems the need of a workaround due to an improper design. I found a case within the 1% where it really makes sense.

You don't have to struggle around with this. I have a solution, but just wanted you to understand why I just tried to provide you my idea for helping autoit keeping better and better. And you're also right that this is a narrow band of problems if I think about all the other solutions you can achieve with the help of AutoIt. I just wanted to "campain" a bit for my idea =) Please don't take it amiss.

Thanks for the informative answer. We just have different points of view, and maybe there was a small missunderstanding.
You sounds a bit like, but I didn't want to annoy you, did I ? Sorry for that.

I read the WikiStart section about the bug reporting.
It seems it was a problem within the structure in the framework. I got another solution keeping the timer tick on.

Tried to reproduce in a proof of concept, but there it works. As soon as it appears in any constellation, I will inform you with reproducing code in a new issue.

Sincerelly.