Script auto exection is really a trouble design

zhenzh
Posts: 68
Joined: Fri Apr 17, 2020 2:23 am

Script auto exection is really a trouble design

Post by zhenzh »

The design that each time click on a script, all related scripts will be auto execute do trouble me a lot.
In most cases, what I want is just editing the script for trouble shooting rather than execution as that may brake the previous problem env.

Besides, auto execution may also impacts on resetProfile() as it may be multiple executed.
It may also impact on module/package installation as I find the installed script is auto executed twice though I don't find the exact reason.

Why not add a "run" button in script editor as most coding tools do so that we can control the script execution by ourselves?

User avatar
Vadi
Posts: 5035
Joined: Sat Mar 14, 2009 3:13 pm

Re: Script auto exection is really a trouble design

Post by Vadi »

It's more overhead and this setup is pretty convenient, people quite like this design actually!

It's not intended to use resetProfile() as part of your scripts - this function reloads the entire state of the Mudlet profile. It's only meant as a debugging aid for when you've messed things up.

zhenzh
Posts: 68
Joined: Fri Apr 17, 2020 2:23 am

Re: Script auto exection is really a trouble design

Post by zhenzh »

No. I have not run resetProfile() in script, just call the function from command line through the provided run-lua-code.

And I have some investigation against the multiple run issue. It should be caused by the logic of auto execution. See the attached 2 examples:
Add 2 scripts with one code

Code: Select all

print(debug.getinfo(1).source.." Loaded")
6689B6C8-CE5E-4022-9023-55271493FADB.jpg
FC2EAF3F-56E5-4323-9FEE-C404F824833A.jpg
See the difference?
The first one is fine. Two scripts were executed once at the time the profile is reloaded which is reasonable.
While the second one get the script "Test" loaded twice. The only difference is that I put the "Test" as a sub-script of "Test Group".
It's clear that the parent/children script may be impacted when its children/parent script is called(Though I'm not sure the exact logic, will discuss later). Based on such parent/children mechanism, we can understand the process at the point of time the profile is reloaded:
1. Profile is reloaded, all module loaded
2. Script "Test Group" is executed, its children script "Test" is also called as a part of auto execution of "Test Group"
3. Script "Test" is executed again, as an individual script called by automation execution.

Then, we can image, in a larger robot, scripts may be placed under different groups to get the whole robot structured and readable. More parent/children relationship may be exist which means more and more multiple execution will occur at the package/module load.

zhenzh
Posts: 68
Joined: Fri Apr 17, 2020 2:23 am

Re: Script auto exection is really a trouble design

Post by zhenzh »

As for the parent/children topic, I have also had some findings. See:
000DFA57-C752-46FF-AFE6-EB2FE1D8874D.jpg
When keep on clicking the script "Test", only "Test" is executed. (blue area)
When switch clicking between "Test" and "Test Group", the script course at will be executed first and then execute the click target.
When keep on clicking the script "Test Group", only "Test Group" is executed.

Seems execution of scripts will be impacted on the parent/children relationship but not the fixed logic parent -> children or children -> parent

zhenzh
Posts: 68
Joined: Fri Apr 17, 2020 2:23 am

Re: Script auto exection is really a trouble design

Post by zhenzh »

Will you have plan to fix this issue that parent script being auto executed by its children?

I think there should be some rules to avoide parent/children scripts impact each other. Such as:
  • All children scripts will be auto executed once thier parent script is executed.
  • Children script execution will NOT impact on the execution of its parent script.
  • Any script should NOT be exected again if it has been executed in its parent script execution chain.

User avatar
Vadi
Posts: 5035
Joined: Sat Mar 14, 2009 3:13 pm

Re: Script auto exection is really a trouble design

Post by Vadi »

Parent scripts aren't run by their children. Can you show an example?

zhenzh
Posts: 68
Joined: Fri Apr 17, 2020 2:23 am

Re: Script auto exection is really a trouble design

Post by zhenzh »

Look at the above attachment(grean area output)
Switch clicking parent and children script:
1. clicking parent -> children run, parent run (yellow font)
2. clicking children -> parent run, children run (gray font)
3. clicking parent -> children run, parent run (yellow font)
4. clicking children -> parent run, children run (gray font)
5. clicking parent -> children run, parent run (yellow font)
捕获.PNG
捕获.PNG (212.53 KiB) Viewed 10179 times

User avatar
Vadi
Posts: 5035
Joined: Sat Mar 14, 2009 3:13 pm

Re: Script auto exection is really a trouble design

Post by Vadi »

Ah ok - you've confused things, it runs the last script, not the parent script. Add more scripts and you'll see it.

That said: use scripts to define your functions. Then use other entry points - like a trigger or an event to run them.

This is how everyone does it in Mudlet and that's how it's not a practical issue, and why it's so convenient without separate "run" button.

zhenzh
Posts: 68
Joined: Fri Apr 17, 2020 2:23 am

Re: Script auto exection is really a trouble design

Post by zhenzh »

Well, then I may understand why I'm troubling with such system while you said others not.

I guess most people use this script feature as function container so that multiple execution will be be a problem as only functions being defined again and again.

While I use it as a true script in which defining global values, pass values between different scripts. In such case, some global values may be overwritten with unexpected value again and again by auto execution.

User avatar
Vadi
Posts: 5035
Joined: Sat Mar 14, 2009 3:13 pm

Re: Script auto exection is really a trouble design

Post by Vadi »

Indeed!

But they won't be overwritten if you do:

value = value or <default value>

Use that pattern and it'll be safe :)

Post Reply