Running some code when the hammerspoon console is active crashes HS

[Madd0g]

I'm working on some button searcher, trying to run this code when the hammerspoon console is active crashes HS entirely.

function clickElemInApp(app, query)
    ax.applicationElement(app):getAllChildElements(function(t)
        local elements = t:elementSearch({
            role="AXButton",
            title=query
        }, true)

        if #elements > 0 then
            elements[1]:doPress()
        end
    end)
end

function click()
      local app = window.focusedWindow():application()
      clickElemInApp(app, "Delete")
end

FWIW, I'm also seeing weirdness with this code when Finder is active.

[asmagill]

Did you ever resolve this? I'm not seeing a crash when I use clickElemInApp(hs.application("Finder"), "Name") -- it toggles the search order in a window I have open as expected.

[Madd0g]

The more serious problem is with the hammerspoon console (hammerspoon crashes), I just tested it and it still happens.

With finder, the issue was significant delay, it took seconds (5-7 at least?). Now I'm on Catalina (10.15.2) and a much newer CPU, while it's still slower than other apps, it feels much faster (2-3 seconds).

[Madd0g]

I think the issue with finder is that everything is a button/clickable, so it takes ages to loop over everything. This is my element clicker.

[asmagill]

Ok, I did get an occasional crash this time around... not every time, but enough to see that the crash was happening on an alternate thread, so... there actually is a reason hs.application:getMenuItems doesn't use an alternate thread for it's queries...

Ok, I just uploaded a new version (0.7.3) that does everything on the main thread... see if that works for you.

Long term, the best solution is to make this use the coroutines we're aiming to support so its more responsive... it will still take a longish time when there are a lot of elements, but it will be more responsive than this one, but that's for another day. (And for the record, we should be able to write C code that can work as a coroutine as well, but I'm not ready to try that yet! One step at a time...)

As to the delay in the FInder, yeah, the number of elements in the entire application is the factor... one of the reasons I've balked at migrating this to core is because I'm still not totally happy that there isn't an obvious way to narrow the search space up front more yet (one of the reasons I think I've been delaying, I think), but let me see if I have any new thoughts when I do my formal review this weekend.

[latenitefilms]

Awesome! I'm going to push 0.7.3 into CommandPost's master branch as well, so that we can test that there.

FWIW - we've never used getAllChildElements in favour of different methods that seem faster. These utility functions to support hs._asm.axuielement might be of interest?

[asmagill]

I'm closing this, but reopen if you're still having the issue or if you think I've missed something.