script manager fails to start

[vredesbyyrd]

Running on arch linux and building darktable from master.

I'm not sure when it began but script_manager.lua will no longer start, I see the following error:

LUA ERROR : /home/clu/.config/darktable/lua/tools/script_manager.lua:360: attempt to call a nil value (field 'show')

line 360 is:

script.data.show()

I made sure I am running the latest script_manager.lua from this repo. I'm stumped on the issue.

EDIT:

More specifically, script_manager appears to be loading scripts, but the script_manager module is not visible in the ui.

[vredesbyyrd]

Alright, I assumed it could not be something with my darktablerc file so I had not tried until now, but deleting darktablerc "fixes" the issue. Now i'll try and track down the offending option.

[wpferguson]

One of the goals for script_manager was to be able to turn a script off and remove it from the UI. In order to do that a script can return a data block, when it loads, such as

local function destroy()
  dt.destroy_event("clear_GPS", "shortcut")
  dt.gui.libs.image.destroy_action("clear_GPS")
end

script_data.destroy = destroy

return script_data

This gets stored on a .data table for each script. When you turn the script off, the destroy function gets called and takes care of removing it.

The problem is libs (i.e. scripts that create modules in the UI). I haven't figured out (yet) how to cleanly destroy them, so I do the next best thing and simply hide them. That way when they are "off" they don't clutter up the UI and when they are "on" they show up. So, you can turn them off and on and script manager just hides and unhides them. That code block looks like this

-- script_manager integration
local script_data = {}

script_data.destroy = nil -- function to destory the script
script_data.destroy_method = nil -- set to hide for libs since we can't destroy them commpletely yet, otherwise leave as nil
script_data.restart = nil -- how to restart the (lib) script after it's been hidden - i.e. make it visible again

local function destroy()
  dt.gui.libs[MODULE_NAME].visible = false
end

local function restart()
  dt.gui.libs[MODULE_NAME].visible = true
end  

script_data.destroy = destroy
script_data.restart = restart
script_data.destroy_method = "hide"
script_data.show = restart

return script_data

It appears that one of the scripts you were running forgot to return a .show() method, therefore script_manager crashed (because I didn't check to see if it existed before I called it).

It would be good to know which scripts you were running, so we can fix the source of the problem. In the meantime, I'll take care of script_manager so that it doesn't crash because a script returned a less than complete script_data table.

[wpferguson]

Looks like I also need to go through the scripts and add a

script_data.show = nil -- comment explaining....

to the scripts so that there is no misunderstanding

[vredesbyyrd]

Okay, that all makes sense, and thank you for the detailed explanation. I'm pretty confident the offending script is metadata_manager.lua. Disabling it via darktablerc prevents the error. I'll look at the script closer.

metadata_manager

[wpferguson]

I'll play with it. I looked and it includes and .show is set to restart() but it may be a bug in the restart() function.

[wpferguson]

My local copy had the .show line, but you're copy did not. I added a comment to gist on how to fix it.

[vredesbyyrd]

Hmm, I added script_data.show = restart after line 494, I dont get any errors, but now metadata_manager module will not show in the ui. darktable -d lua prints 1.7883 LUA DEBUG: metadata_manager.lua: load_preferences: 289: got pref string

I again started with a fresh darktablrc, but no dice. Working on figuring it out.

[wpferguson]

Here's my copy... metadata_manager.zip

[vredesbyyrd]

That did the trick. I seriously appreciate your help. You have some very useful lua scripts!

[vredesbyyrd]

One quick note - I do have to change one line to get it to work on my system.

On line 82 I have to use string.format with the %q format specifier opposed to concatenating with ..

local cmd = string.format('%s%s %q', mm.exiv2, mm.query_string, image.path .. "/" .. image.filename)

Otherwise it complains:

sh: -c: line 1: `'/usr/bin/exiv2' -PEkt -K Exif.Fujifilm.ShadowTone /mnt/PHOTO/2022_11 - cloquet visit (people)/2022_11 - lake superior (portra 160 & 400)/DSCF3339.RAF'

[vredesbyyrd]

welp, two more things. I'm not sure I should post this here as its mostly unrelated to the main issue, but thought I should at least make note it.

Even when using a fresh darktablerc, metadata_manager settings are not retained when restarting darktable.

Error message: ...e/clu/.config/darktable/lua/contrib/metadata_manager.lua:271: attempt to call a nil value (global 'dump_md_pair')

Oddly, darktablerc shows the key pairs but the corresponding metadata are not visible in the metadata_manager module.

lua/metadata_manager/mdpairs={shadow tone,Exif.Fujifilm.ShadowTone,true,false}

No worries if you close this. I'm not sure this script is "officially" supported but I can open a separate issue if appropriate.

[wpferguson]

It's fine about reopening this, I was going to anyway to remind me to add the check for .show() to script_manager.

metadata_manager was written as a test script when the image information module got rewritten and lua support was added. I got it working, but it never got tested very much nor made "production ready".

In the last couple of years real life has been consuming a lot of my time, so the lua-scripts have languished somewhat. Thankfully real life has slowed down some, so now I can start cleaning things up.

[vredesbyyrd]

In the last couple of years real life has been consuming a lot of my time, so the lua-scripts have languished somewhat. Thankfully real life has slowed down some, so now I can start cleaning things up.

Can relate. Glad real life has slowed down though...that's always nice!

I originally stumbled on a version of the metadata script in this thread. I'm out of town at the moment, but when time abides I am going to see if I can narrow down the strange behavior, i'll report back. And Ill be sure to add the check for .show(), maybe that's all it will take. Thanks for the heads up.