Jump to content

Alleyoop: Update Alfred Workflows


Recommended Posts

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.

Link to comment

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.

Link to comment

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.

Link to comment

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
Link to comment

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.

Link to comment

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!

Link to comment

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.

Link to comment

 

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! ;-)

Link to comment
  • 1 month later...

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.

Link to comment
  • 3 weeks later...

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.

Link to comment
  • 4 months later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...