Bounty on the head of ExecuteGlobal()

[rassillon]

I didn't want to put in a feature request because

1.) It has been discussed and by Valik somewhere...

2.) There appeared to be done in 25th November, 2007 - v3.2.10.0

• Changed: Limits on Execute() removed.

3.) I would like to offer some cash money if someone would make this happen.

I have written way too much code using named pipes, eval, execute and other twisting and I still have an ugly partially functional method that still doesn't do what a simple ExecuteGlobal Ah La vbscript would do.

I think other people would like the feature especially if they manage large networks, hundreds of pieces of software, and thousands upon thousands of desktops.

Anyway, If I am out of line, please chastise me accordingly.

If one of the developers wants to get paid, or if I have to pay Jon too... contact me and we can discuss terms.

-R

[Melba23]

rassillon,

I have made the Devs aware of this post.

M23

[jvanegmond]

Is this thread about interop or about better Execute?

Edit: There is already a lot about transparent interop ( example uses preprocessing ) and also a lot about parsing code and executing it: http://code.google.com/p/au3int/

My idea for future is extensible preprocessor for this kind of thing.

We don't need AutoIt developers to build this. Then there are also some issues with native solutions: http://www.autoitscript.com/trac/autoit/ticket/1931

Edited January 3, 2012 by Manadar

[Valik]

You want us to provide you a sleek sexy (and non-trivial time-consuming core-rewriting) implementation of a basic computing concept that's been around and written about for decades?

[rassillon]

You want us to provide you a sleek sexy (and non-trivial time-consuming core-rewriting) implementation of a basic computing concept that's been around and written about for decades?

Well.....yeah...

If I wanted fat & ugly I would expect someone to pay me...

.

.

.

.

.

.

After my attempt at humor wears off....

I realize it may be "non-trivial" so .... I am just offering some cash to get it done.

I have a non-trivial use for it.

My only other option at this time is to include the full source of my project modified to run the scriptlets (I guess use named pipes to get/set variables) then inject the scriptlet and then launch a new process with AutoIt3ExecuteScript

I know not everyone agrees with Execute() and I totally understand that. I respect your point of view but don't hold it myself.

If you have a need as I do to provide a larger complex product while still allowing consumers of that product, of varying skill, to customize and extend, without having to rewrite every time, leveraging what is already an AWESOME language without having to write an interpreter yourself (not gonna happen).... a fully functional Execute() function is perfect.

I seriously intend no offense and thinks the Devs are super-awesome!

And if money don't temp you....how about BEER....

[Valik]

Money holds no sway over me. Beer even less.

Just because you can't come up with an elegant solution without the need for built-in functionality doesn't mean others can't.

[jvanegmond]

I think this is almost trivial to build. My post above already contains links to most of the work that otherwise needs to be done.

I'll try to find some time tonight ... No promises.

[rassillon]

Well, thanks anyway...

Manadar, thanks for your input....

I didn't really want the extra point of potential failure but I am just going to continue down my current path that uses "named pipes"

I am just going to write stub that I will require users to include in their script which will have duplicate functions that just call back into the parent script and duplicate global variables that I load the values back and forth. Then when I launch a child script I will open a pipe and then close it when that script is done.

After reading what I plan to do again.....it sounds a lot like how DCOM works...lol

A little more to maintain than what I would have hoped but it will be functional.

Thanks guys

[jvanegmond]

If you could produce a function prototype and example usage then I will try to build it for you.

-OR-

If you could share the relevant existing code, or function prototypes and comment out big stuff, even only in private, then I will try to build it for you.

I hoped this was clear from my previous post.

[rassillon]

Hey Manadar,

I am about to go on a trip so it may be a while but let me give you an idea if I can where I (have gone/ am going) with this.

Firstly I started off with the _NamedPipes_client.au3 and _NamedPipes_Server.au3 found in %programfiles%AutoIt3ExamplesGUIAdvanced

In _NamedPipes_Server.au3 I modified the Func ExecuteCmd()

to do a Call() instead of the CreateProcess. <----this is still a bit crude but works ok for now.

What I will be doing is creating stubs in an include file like this

Main.au3

Func _say_hi($_say_hi_string)

Msgbox(0,@scriptname,_say_hi_string)

EndFunc

Then I will have dummy funcs in the include like this

Stub.au3

Func _say_hi($_say_hi_string)

Return _call_main_script("_say_hi","Param1," & $_say_hi_string)

EndFunc

Func _call_main_script($_func_name,$_func_params)

;See _NamedPipe_Client.au3 SendCmd() function for the basics of what would go here

Return $_ret_val

EndFunc

---------------------------------

For each of the functions that I have in my main project, I will mimic it with a function in my client include that will pass the name of the function and the parameters back to the main project.

I will probably have to create in addition a function to do eval() in the main script too so that I can load the global variables values

---------------------------------

There are a lot of little bits that need to be worked, nothing too difficult....

But I hope that gives you an idea what I am working at.

When I get back from my trip, I will pull together some code that is not embarrassing and slightly more concise that what currently have been hacking at...

[Valik]

You are worried about an additional point of failure but you don't realize something. Changing AutoIt to support this would introduce numerous points of failure. The feature would need to be written and tested. This takes time. Assuming you are willing to use a beta you would be responsible for testing the unstable feature. That alone is a lot of time. In addition to that instability - and this is the really nasty bit - the core of AutoIt would need to be re-written to support such a feature. So we would be taking code that is either stable or has known quirks and scrapping it in favor of something new.

In the end all you are doing is shifting the point of failure from you to us. Instead of your typo breaking the entire script our typo breaks the entire language. Even if I were to say "yes, we'll do this" you would gain nothing lose a lot of time. If the core of the language is ever re-written it's something to consider supporting but it's not something worth going out of our way to rewrite the core for.

[rassillon]

You are worried about an additional point of failure but you don't realize something. Changing AutoIt to support this would introduce numerous points of failure. The feature would need to be written and tested. This takes time. Assuming you are willing to use a beta you would be responsible for testing the unstable feature. That alone is a lot of time. In addition to that instability - and this is the really nasty bit - the core of AutoIt would need to be re-written to support such a feature. So we would be taking code that is either stable or has known quirks and scrapping it in favor of something new.

In the end all you are doing is shifting the point of failure from you to us. Instead of your typo breaking the entire script our typo breaks the entire language. Even if I were to say "yes, we'll do this" you would gain nothing lose a lot of time. If the core of the language is ever re-written it's something to consider supporting but it's not something worth going out of our way to rewrite the core for.

Valik, maybe I misunderstood the discussion that went on , I got the feeling that it was supposed to have been unrestricted at one time and your comment in that thread lead me to believe it wasn't that large of an undertaking..... Maybe I misread???

If so, no big deal, I have leveraged dynamic loading and execution of code in vbscript and jscript to create some really useful tools, and I presumed that I would be able to do that here as well..... No biggie really though, all the extra functionality I get from using AutoIt over those and other languages more than makes up for it. I will get a method worked out that will meet my needs one way or another.

Thanks for at least commenting on the subject.

[Valik]

Execute() used to have limits on which functions could be invoked. That limitation was removed. You can now use Execute() to invoke any built-in function (Even Execute() itself):

Execute('Execute("MsgBox(4096, """", ""Test"")")')

[jvanegmond]

Example of Execute used to do anything.