New handling of script instances

This forum is for questions / discussions regarding development of addons / tweaks for MediaMonkey.

Moderator: Gurus

jiri
Posts: 5392
Joined: Tue Aug 14, 2001 7:00 pm
Location: Czech Republic
Contact:

New handling of script instances

Post by jiri » Mon Dec 29, 2008 7:38 am

Although it probably won't affect many scripts and their authors, I rather announce a small change introduced in MM 3.1.0.1205: Each script will only have one instance in memory, unlike in previous versions, where it was possible to have several instanced loaded under some conditions. I added some info about it to wiki at http://www.mediamonkey.com/wiki/index.p ... pt_loading , its copy follows below.

Let me know in case of any troubles.

Jiri

Internal mechanism of script loading
Normally, you don't need to know much about internal handling of scripts by MediaMonkey, but sometimes it might be useful to know, when exactly scripts are loaded.

When some function of a script is about to be executed (e.g. OnStartup function of auto-scripts), the script is loaded to memory and executed as necessary. When the execution finishes, the script is again unloaded from memory. However, there is on exception - if you register some event (by calling RegisterEvent function), the script remains still loaded in memory, until all registered events are unregistered, then it's unloaded.

This is good to know when you plan some sharing of variables. While the script is loaded in memory, you can use its global variables, but if you need to persist some values or objects between script sessions, you have to use some other mechanism (ini files, Objects collection, ...).

Note that starting from MediaMonkey 3.1.0.1205, there is always at most one instance of script loaded in memory. In older versions, if a script registered some events and then e.g. Option sheet functions were called back by MediaMonkey, they were processed in another instance of the script. Now they are processed in the already loaded instance, which helps avoid some memory leaks, is easier to handle and is also faster to process.

MoDementia
Posts: 1321
Joined: Thu Jun 15, 2006 3:26 pm
Location: Geelong, Victoria, Australia

Re: New handling of script instances

Post by MoDementia » Mon Dec 29, 2008 3:36 pm

This is great news, I know I have had to write code to get around this issue previously. Hopefully the workarounds still function correctly :)
Even if they do it will be worth while fixing them to take advantage of this change.

ZvezdanD
Posts: 3090
Joined: Thu Jun 08, 2006 7:40 pm

Re: New handling of script instances

Post by ZvezdanD » Thu Jan 01, 2009 4:41 am

Well, I suppose this is a great news, but there are some troubles with it, most notably when we developing some script. With old MM versions if I change something in the script when I enter some dialog box it would be executed a new, modified version of the script. Now, I need to restart MediaMonkey whenever I change something in the script to see how changes are reflecting. Jiri, this was one more reason why I used oMenu.OnClickFunc instead of Script.RegisterEvent oMenu, "OnClick", "...".

Maybe you should make an option to disable such new behavior, or at least to enable old way with multiple instances in a Debug version of MM.
Magic Nodes 4.3.3 / 5.2 RegExp Find & Replace 4.4.9 / 5.2  Invert Selection/Select None 1.5.1  Export/Create Playlists for Child Nodes 4.1 / 5.4  Expand Child Nodes/Expand All 1.1.2  Event Logger 2.7  Filtered Statistics Report 1.6  Track Redirection & Synchronization 3.4.2  Restore/Synchronize Database 3.1.7 / 4.0  Find Currently Playing Track 1.3.2  Queue List 1.2.1  Add to Library on Play 1.0.1  Tree Report for Child Nodes 1.1.1  Update Location of Files in Database 1.4.3 / 2.2.2  Inherit Child Playlists 1.0.2  Add Currently Playing/Selected Track(s) to Playlist 1.1.2

jiri
Posts: 5392
Joined: Tue Aug 14, 2001 7:00 pm
Location: Czech Republic
Contact:

Re: New handling of script instances

Post by jiri » Thu Jan 01, 2009 10:47 am

I can see that it makes testing harder, but making the behaviour option would probably cause more bad than good. Maybe there could be added some way how to easily force MM to reload all loaded scripts, so that it isn't necessary to restart it for this purpose. I'm not sure, how to do this though - maybe to add a COM method for this and a script author could install a script, that would add toolbar button calling this method - i.e. script refresh in memory would need just one mouse click.

Jiri

Teknojnky
Posts: 5533
Joined: Tue Sep 06, 2005 11:01 pm
Contact:

Re: New handling of script instances

Post by Teknojnky » Thu Jan 01, 2009 2:02 pm

I like that idea.

From Jiri's original post, it seems that you can have a method un-register all events to unload the script from memory, then you could manually run the init/startup method to re-register after making changes.

ZvezdanD
Posts: 3090
Joined: Thu Jun 08, 2006 7:40 pm

Re: New handling of script instances

Post by ZvezdanD » Thu Jan 01, 2009 2:27 pm

Actually, I don't want to execute OnStartup again, nor to unregister and register event handlers again. For example, with old MM versions when I change something in the script within dialog procedure, it is enough to enter into this dialog and to see changes made on it. Also, when I change something in the node code (Magic Nodes), it is enough to collapse/expand main branch to see changes on its sub-nodes. But, if I unregister all event handlers, all nodes are disappearing even if I want just to change something into dialog procedure, not into node procedure.

Well, never mind. I will stay with 3.0 for script development.
Magic Nodes 4.3.3 / 5.2 RegExp Find & Replace 4.4.9 / 5.2  Invert Selection/Select None 1.5.1  Export/Create Playlists for Child Nodes 4.1 / 5.4  Expand Child Nodes/Expand All 1.1.2  Event Logger 2.7  Filtered Statistics Report 1.6  Track Redirection & Synchronization 3.4.2  Restore/Synchronize Database 3.1.7 / 4.0  Find Currently Playing Track 1.3.2  Queue List 1.2.1  Add to Library on Play 1.0.1  Tree Report for Child Nodes 1.1.1  Update Location of Files in Database 1.4.3 / 2.2.2  Inherit Child Playlists 1.0.2  Add Currently Playing/Selected Track(s) to Playlist 1.1.2

jiri
Posts: 5392
Joined: Tue Aug 14, 2001 7:00 pm
Location: Czech Republic
Contact:

Re: New handling of script instances

Post by jiri » Thu Jan 01, 2009 4:02 pm

I will stay with 3.0 for script development.
That would be a pity, I think. What I proposed in my previous post would perfectly solve your problem, wouldn't it?

Jiri

ZvezdanD
Posts: 3090
Joined: Thu Jun 08, 2006 7:40 pm

Re: New handling of script instances

Post by ZvezdanD » Thu Jan 01, 2009 5:50 pm

jiri wrote:What I proposed in my previous post would perfectly solve your problem, wouldn't it?
I am not sure. I don't know what you mean by "reload all loaded scripts" and "script refresh in memory", but if this means that OnStartup is executed and all event handlers are unregistered/registered again, than I cannot use it. Here is just one example from Magic Nodes - I have dialog box where I can create/delete custom nodes; if I want to make some small change on this dialog, e.g. to move some control to another place and to see how it will look with that modification, if I choose unregister all events all my previously created nodes will disappear which I don't want. I know this happens since I tried it when have been finding my way to resolve memory leaks. Well, maybe I could solve this with some complicated code, but it is easier for me to continue development with an older MM version.

However, if your newly introduced method could reload just some parts of the script, without execution of OnStartup and unregistering all event handlers, then I'd be glad to use it.
Magic Nodes 4.3.3 / 5.2 RegExp Find & Replace 4.4.9 / 5.2  Invert Selection/Select None 1.5.1  Export/Create Playlists for Child Nodes 4.1 / 5.4  Expand Child Nodes/Expand All 1.1.2  Event Logger 2.7  Filtered Statistics Report 1.6  Track Redirection & Synchronization 3.4.2  Restore/Synchronize Database 3.1.7 / 4.0  Find Currently Playing Track 1.3.2  Queue List 1.2.1  Add to Library on Play 1.0.1  Tree Report for Child Nodes 1.1.1  Update Location of Files in Database 1.4.3 / 2.2.2  Inherit Child Playlists 1.0.2  Add Currently Playing/Selected Track(s) to Playlist 1.1.2

jiri
Posts: 5392
Joined: Tue Aug 14, 2001 7:00 pm
Location: Czech Republic
Contact:

Re: New handling of script instances

Post by jiri » Thu Jan 01, 2009 6:24 pm

It would only cause that all global variable of the script would be lost (i.e. re-initialized). However, as I think about it, it probably isn't the best idea, it wouldn't help that much and possibly rather cause problems. So, let's rather leave it as is, unless we find some better solution...

Jiri

Big_Berny
Posts: 1784
Joined: Mon Nov 28, 2005 11:55 am
Location: Switzerland
Contact:

Re: New handling of script instances

Post by Big_Berny » Sun Jan 04, 2009 4:58 pm

Yes, would be very nice if this could be changed in the next build again. I just installed 1207 and wanted to work on optionsheets which is a real pain like this... Downgraded to 1204 for now.
Last edited by Big_Berny on Sun Jan 04, 2009 5:52 pm, edited 1 time in total.
Image
Scripts in use: Genre Finder / Last.fm DJ / Magic Nodes / AutoRateAccurate / Last.FM Node
Skins in use: ZuneSkin SP / Eclipse SP
AutoRateAccurate 3.0.0 (New) - Rates all your songs in less than 5 seconds!
About me: icoaching - internet | marketing | design

Bex
Posts: 6316
Joined: Fri May 21, 2004 5:44 am
Location: Sweden

Re: New handling of script instances

Post by Bex » Sun Jan 04, 2009 5:05 pm

Yes, to implement something which solves this would be very nice since developing scripts is now really time consuming.
Advanced Duplicate Find & Fix Find More From Same - Custom Search. | Transfer PlayStat & Copy-Paste Tags/AlbumArt between any tracks.
Tagging Inconsistencies Do you think you have your tags in order? Think again...
Play History & Stats Node Like having your Last-FM account stored locally, but more advanced.
Case & Leading Zero Fixer Works on filenames too!

All My Scripts

Teknojnky
Posts: 5533
Joined: Tue Sep 06, 2005 11:01 pm
Contact:

Re: New handling of script instances

Post by Teknojnky » Fri Jan 09, 2009 2:02 pm

I was doing some testing and yea, this new behavior is very difficult for script development and testing changes.

Bex
Posts: 6316
Joined: Fri May 21, 2004 5:44 am
Location: Sweden

Re: New handling of script instances

Post by Bex » Mon Jan 12, 2009 8:47 pm

What about to implement a new "property" SDB.DevelopingMode(True/False) which sets the script to a Developing Mode. In that mode all Subs/Functions should be reread from the script file when executed thus making a restart unnecessary.
If SDB.DevelopingMode=True then some sorts of warning should pop up on starting the script which would prevent users from using it if a developer forgets to set SDB.DevelopingMode=False.

Is that possible to implement?
Advanced Duplicate Find & Fix Find More From Same - Custom Search. | Transfer PlayStat & Copy-Paste Tags/AlbumArt between any tracks.
Tagging Inconsistencies Do you think you have your tags in order? Think again...
Play History & Stats Node Like having your Last-FM account stored locally, but more advanced.
Case & Leading Zero Fixer Works on filenames too!

All My Scripts

Teknojnky
Posts: 5533
Joined: Tue Sep 06, 2005 11:01 pm
Contact:

Re: New handling of script instances

Post by Teknojnky » Mon Jan 12, 2009 9:00 pm

A DevMode that would disable all script caching would be great.

I have to veto the warning pop up tho, pop up dialogs are just extremely annoying and that would almost as bad as having to constantly re-start MM in the first place.

Ideally the devmode property should be on a per script basis, but a global devmode would be sufficient as well.

Bex
Posts: 6316
Joined: Fri May 21, 2004 5:44 am
Location: Sweden

Re: New handling of script instances

Post by Bex » Mon Jan 12, 2009 9:12 pm

1. It would only pop-up once per restart. Something like:

Code: Select all

Script "Vbs filename goes here" is in Developing Mode. If that is unexpected, Do Not use the script and please notify the script author!
But is there another way to alert the normal user that he is using a script that is in developing mode, if the developer misses to change the property?

2. Yes that was what I meant. E.g the developer just adds SDB.DevelopingMode=True in the top of the script to make it behave differently.
Advanced Duplicate Find & Fix Find More From Same - Custom Search. | Transfer PlayStat & Copy-Paste Tags/AlbumArt between any tracks.
Tagging Inconsistencies Do you think you have your tags in order? Think again...
Play History & Stats Node Like having your Last-FM account stored locally, but more advanced.
Case & Leading Zero Fixer Works on filenames too!

All My Scripts

Post Reply