Alleyoop: Update Alfred Workflows

[KrOstir]

Opp is also behaving strange here.

 

Oop (and oop!) reports all workflows are up to date, however the debug.log says "[com.danielsh.alfred.alleyoop: Top Processes failed with error: 'download_url' (2013-05-31-09:23:16)]". all.log is empty.

 

Oop? wants to do a google search.

[phyllisstein]

The debug line means that the developer never updated his or her JSON to reflect the changes in Alleyoop 2; unfortunately, that's out of my hands. The fallback search was a consequence of a silly Python indentation error—the version I just uploaded should fix it.

[KrOstir]

The debug line means that the developer never updated his or her JSON to reflect the changes in Alleyoop 2; unfortunately, that's out of my hands. The fallback search was a consequence of a silly Python indentation error—the version I just uploaded should fix it.

 

You are a legend. It works.

 

Thanks.

[raguay.customct]

Hi, I just found an error. If AlleyOOP is downloading workflows and you open Alfred, it gives a long error message in the notifications. Also, I am getting the same three workflows need updated everyday: CyberDuck, Date Calculator, and Pocket. Is it the workflows fault or is AlleyOOP stuck on them? This is the output:

 

Traceback (most recent call last):

  File "act.py", line 67, in <module>

    act()

  File "act.py", line 47, in act

    ret_path = do_download(remote, name)

  File "act.py", line 21, in do_download

    r.download()

  File "/Users/richardguay/Dropbox/Richard/rag/Alfred/Alfred.alfredpreferences/workflows/user.workflow.E879F36C-AF56-4485-9465-C0BA954AB54D/alp/request/request.py", line 28, in download

    self.request = requests.get(self.url)

  File "/Users/richardguay/Dropbox/Richard/rag/Alfred/Alfred.alfredpreferences/workflows/user.workflow.E879F36C-AF56-4485-9465-C0BA954AB54D/alp/request/requests/api.py", line 55, in get

    return request('get', url, **kwargs)

  File "/Users/richardguay/Dropbox/Richard/rag/Alfred/Alfred.alfredpreferences/workflows/user.workflow.E879F36C-AF56-4485-9465-C0BA954AB54D/alp/request/requests/api.py", line 44, in request

    return session.request(method=method, url=url, **kwargs)

  File "/Users/richardguay/Dropbox/Richard/rag/Alfred/Alfred.alfredpreferences/workflows/user.workflow.E879F36C-AF56-4485-9465-C0BA954AB54D/alp/request/requests_cache/core.py", line 111, in request

    hooks, stream, verify, cert)

  File "/Users/richardguay/Dropbox/Richard/rag/Alfred/Alfred.alfredpreferences/workflows/user.workflow.E879F36C-AF56-4485-9465-C0BA954AB54D/alp/request/requests/sessions.py", line 345, in request

    resp = self.send(prep, **send_kwargs)

  File "/Users/richardguay/Dropbox/Richard/rag/Alfred/Alfred.alfredpreferences/workflows/user.workflow.E879F36C-AF56-4485-9465-C0BA954AB54D/alp/request/requests_cache/core.py", line 91, in send

    return send_request_and_cache_response()

  File "/Users/richardguay/Dropbox/Richard/rag/Alfred/Alfred.alfredpreferences/workflows/user.workflow.E879F36C-AF56-4485-9465-C0BA954AB54D/alp/request/requests_cache/core.py", line 85, in send_request_and_cache_response

    self.cache.save_response(cache_key, response)

  File "/Users/richardguay/Dropbox/Richard/rag/Alfred/Alfred.alfredpreferences/workflows/user.workflow.E879F36C-AF56-4485-9465-C0BA954AB54D/alp/request/requests_cache/backends/base.py", line 40, in save_response

    self.responses[key] = self.reduce_response(response), datetime.utcnow()

  File "/Users/richardguay/Dropbox/Richard/rag/Alfred/Alfred.alfredpreferences/workflows/user.workflow.E879F36C-AF56-4485-9465-C0BA954AB54D/alp/request/requests_cache/backends/storage/dbdict.py", line 168, in __setitem__

    sqlite.Binary(pickle.dumps(item)))

  File "/Users/richardguay/Dropbox/Richard/rag/Alfred/Alfred.alfredpreferences/workflows/user.workflow.E879F36C-AF56-4485-9465-C0BA954AB54D/alp/request/requests_cache/backends/storage/dbdict.py", line 126, in __setitem__

    self.table_name, (key,)).fetchone():

sqlite3.OperationalError: no such table: responses

[raguay.customct]

Also, it is importing Pocket as Things. Since they are different authors, I was wondering if AlleyOOP might be downloading the wrong one, but naming it differently. Not sure and not sure how to check (I am not that good at python).

[phyllisstein]

Hm, in all honesty, I'm not sure what do to about the issue with reopening Alfred; it's unclear to me what effect starting a new Alfred instance has on processes that Alfred's spawned in the background, aside from "a not-very-nice one." I'll investigate it a bit, but that traceback info doesn't immediately suggest any leads. The error with Pocket is on the Pocket developer's end: if you look at his update.json file, it's actually just an unmodified copy of my Things update.json file that I assume he forgot to edit. As for the update-revenants, try running oop!—if it clears them up, then Alleyoop's cache was being overzealous; if not, then I suspect there's an error with the developers' update files.

[raguay.customct]

Hm, in all honesty, I'm not sure what do to about the issue with reopening Alfred; it's unclear to me what effect starting a new Alfred instance has on processes that Alfred's spawned in the background, aside from "a not-very-nice one." I'll investigate it a bit, but that traceback info doesn't immediately suggest any leads. The error with Pocket is on the Pocket developer's end: if you look at his update.json file, it's actually just an unmodified copy of my Things update.json file that I assume he forgot to edit. As for the update-revenants, try running oop!—if it clears them up, then Alleyoop's cache was being overzealous; if not, then I suspect there's an error with the developers' update files.

 

I think it is a problem with trying to open a database file more than once. The checker is checking it, but the downloader is writing to it that it has been checked. Because, when I open Alfred, Alfred is set to show the last thing I did. That will run the checker again. I like that behavior for most workflows, but that one workflow does not. When you query your database, are you checking for already open errors?

 

I was running "oop!", but, as you said, the developer is not changing the file properly. You might put a check for the file name being different than the name in the json file and just flag it as an error or something. It is awful confusing to think you are getting one thing, and something else is popping up. Makes you feel like you have a virus!

[phyllisstein]

It's definitely something to do with a database collision, but the strange thing is that it's happening in the "action" script rather than the "feedback" script—the action shouldn't be affected by the repetition of your search. In any case, I've just pushed a new version that disables caching in the action script. I'm not sure that it'll solve the bigger problem of what happens to a script in process when it's derailed by a new Alfred instance, but it should fix the database troubles.

 

I'll try to think of a creative way to check the names, but it'll be tough. A lot of developers are doing things like adding version numbers to their exported filenames, which could potentially throw it off a bit. But I'll see if I can think of something.

[raguay.customct]

 

I'll try to think of a creative way to check the names, but it'll be tough. A lot of developers are doing things like adding version numbers to their exported filenames, which could potentially throw it off a bit. But I'll see if I can think of something.

 

Well, you could create a regular expression to turn all non-alpha characters into spaces, then separate by spaces, and use the first word in a search on the string of the new file name. If one full word is the same, assume it is the right one. That at least would catch the one that I am having problems with. There is only a few with really similar names.

 

Then, if the developer still tries to mess it up, set the "arm out of the screen" procedure to go for his throat! ;-)

[Tyler Eich]

Is there any chance Alleyoop could support Semantic Versioning (the same system Alfred uses, e.g. '2.0.6')? It's a really small thing, but it would be a nice feature 

 

Cheers

[raguay.customct]

It's back to bombing all the time. Need a way to figure out what the rogue workflow is.

[phyllisstein]

debug.log should give you some clues; if not, then feedback.log might. As for additional features, rumor has it that replacement options are coming down the pipe, and so I think I'll probably freeze this workflow but for bug fixes.

[raguay.customct]

It could not parse the cache file. I deleted it and it is working. Must of gotten corrupted.

[avk_tp]

I believe the download links are all down. My alleyoop keeps crashing silently, so I was hoping to reinstall it... but I can't find it for the life of me. 

[phyllisstein]

I've been having some server-side issues that are probably causing my own download links to fail, along with any Alleyoop-configured workflows by me personally---however, that wouldn't affect other developers' workflows at all. I'll be doing one last server migration soon that will hopefully correct the problem on my end; in the meantime, I suggest you check the log files in the workflow's folder to see which ones are bombing. If you don't want to delete a whole workflow just because Alleyoop isn't updating it---and why should you?---just open the workflow's folder and delete update.json. Alleyoop only tracks the workflows for which it can find that file. Note that you may have to force a cache reset with oop! in order to see any changes.

[TiTerm]

Hi

Still not back ?

Can't download last version of workflow and oop seem not answer anymore...

[phyllisstein]

Hi there,

As I've said in a few other places, the reservoir of time that allowed me to maintain, troubleshoot, and update these workflows has long run dry. I've uploaded big chunks of the code, though overlooking the Info.plist files, along with all the .alfredworkflow packages, to Github, if you'd like to take a crack at improving them. All I can suggest is that you remove any update.json files in my own workflows and keep an eye on your logs.

[gh0strid3r]

Hi,

 

the link is dead. Is there still use for this workflow or hast it been implemented otherwise by Alfred app itself or workflow developers?

 

Thanks

[rice.shawn]

As noted above, it's been abandoned. I'm working on a "fuller" solution that will integrate with www.packal.org for updating workflows. More to come later.