No "action" from a Script Filter

[troycurtisjr]

I'm having trouble getting the output of my "Script Filter" to execute. I've successfully used this before, but I am out of ideas about what is going on with this one.

 

My "Script Filter" runs successfully, and in this case it gets the results of a search performed by GPMDP. I go down to the desired selection, hit enter and nothing happens. Alfred and my search list stay displayed, and nothing indicates I have done anything, except that occasionally when I choose something down the list a bit, Alfred will move that selection to the top. I've run the command with the debug on, and there doesn't appear to be any output from the "Script Filter". Everything seems right with my json output, and I've stripped it way down trying to figure out the issue. This is the current output:

 

Quote

[2019-05-12 18:16:27][input.scriptfilter] {"items": [{"title": "Meshuggah", "valid": true}]}

 

I've tried a few simple outputs (besides my desired "Run Script" output), but nothing changes. Using the keyword trigger in the same workflow operates correctly.

 

I'm hoping you guys have ran into similar scenarios, my searches didn't turn up anything.

 

I've pushed up my in-progress code https://gitlab.com/troycurtisjr/alfred-control-gpmdp.

[deanishe]

Sorry, can't run the workflow. I don't have Google Music. If you can replicate the issue without needing GPMDP, I'll have another look.

 

Out of interest, why all the async stuff? Does websockets require it?

[troycurtisjr]

So I kinda figured it out, though it doesn't really make a lot of sense to me. Perhaps you can understand what is going on better.

 

While recreating the issue in a simpler workflow to share with you I stumbled on what finally made it work: supplying a value for "arg". This seems odd since the documentation says it is an optional parameter, and in my DND workflow it doesn't have an "arg" and works OK.

 

Here is a minimal workflow that duplicates the issue for me: https://drive.google.com/open?id=1HFlPoMTTU4X83I2T0fVuq2TUUvqc8H2G

It behaves the same way in that it does not respond to selecting the only filter option. If the second echo in the script filter is uncommented and the first is commented out, then it works as expected. By adding an "arg" value, I was able to successfully get my GPMDP to work which is great! But I'd like to better understand why.

 

As for the async usage the reason is two fold:

1. The websockets library I ran across first for Python (https://websockets.readthedocs.io/en/stable/) uses the coroutine support as it is built on top of the standard asyncio library.

2. I wanted to learn something a bit new 😉

 

I've spent most of my development career writing event driven code, which I like, but I've never had an opportunity to do it with real language support for coroutines. You get something similar with javascript, but it seems a bit different. I have found I quite like it as opposed to decomposing my processing into discreet processing blocks with a means to save state in between. This also works really well for the GPMDP API in particular, as there is a LOT coming across the wire that my script doesn't care about, but I need to pick out the pieces I do need (from the right "namespace"). So using the async queues really cleaned up the code, and each function can effectively be written as a standard linear function, which makes it quite easy to follow IMO.

 

Thanks for the nudge to simplify down to the basics, I should have used the basic troubleshooting technique from the beginning! 😛

[deanishe]

7 hours ago, troycurtisjr said:

This seems odd since the documentation says it is an optional parameter, and in my DND workflow it doesn't have an "arg" and works OK.

 

Yes. It should work without an arg.

 

7 hours ago, troycurtisjr said:

You get something similar with javascript, but it seems a bit different

 

They've added async and await to the new version of JS/ECMAScript/whatever it's called, haven't they?

 

The more mainstream method seems to be Promises, which kinda suck, imo. 

 

8 hours ago, troycurtisjr said:

So using the async queues really cleaned up the code, and each function can effectively be written as a standard linear function, which makes it quite easy to follow IMO.

 

I don't really follow you here. There isn't any concurrency in the script, is there? So what's the difference to regular synchronous code?

[troycurtisjr]

On 5/14/2019 at 6:11 AM, deanishe said:

On 5/13/2019 at 10:10 PM, troycurtisjr said:

So using the async queues really cleaned up the code, and each function can effectively be written as a standard linear function, which makes it quite easy to follow IMO.

 

I don't really follow you here. There isn't any concurrency in the script, is there? So what's the difference to regular synchronous code?

 

You are right there there is not much concurrency here. None of the I/O I'm doing (or currently expect to do) with the websocket would be expected to take very long. However, there is potentially some overlapping I/O going on here. The way the GPMDP websocket API works is that there is a near constant stream of data (presuming a track is actively playing, basically it is the "current time" message), and arbitrarily interleaved in that stream is the response or responses to calls that you might make. The overlapping I/O happening *could* be during the async send and the ongoing async receives going on. Again, I'm not claiming in this simple use case there is a huge gain. After all if I was writing this in sync code, I would just have a common read function that would read messages and discard the ones I wasn't currently interested in, waiting for the desired response before returning it. I am also planning on making use a few of the automatic messages sent over, namely the playlists. So those can be read and queued off until I care about them, and interacting with them would be the same whether they were already present when I go to look for them, or whether I needed to "await" a bit for them to come in.

 

Lastly, I'm planning on pulling down the various bits of album art into a local cache to use as the icon, and that would be nice to run "concurrently". Now I'm all set to just add those pieces in! But first, I'm getting the basics all working so I can control more of my computer using Alfred!

[deanishe]

Thanks for the explanation. Makes sense.