bmscmoreira Posted March 28, 2013 Share Posted March 28, 2013 Great! Thanks for all the effort. Great workflow! Link to comment
mccamel Posted March 28, 2013 Share Posted March 28, 2013 (edited) Loving this so far, but is there syntax to add a start date? I use this way more than due date. Also, I would like to have a way to add a task without simultaneously doing a search-- I find that the latency of my keystrokes can get pretty high with Alfred continually running the script filter. Thanks for putting this together. Edited March 28, 2013 by mccamel Link to comment
phyllisstein Posted March 28, 2013 Author Share Posted March 28, 2013 Loving this so far, but is there syntax to add a start date? I use this way more than due date. Also, I would like to have a way to add a task without simultaneously doing a search-- I find that the latency of my keystrokes can get pretty high with Alfred continually running the script filter. Thanks for putting this together. Sorry, the parser syntax is fixed by Things and out of my control. I've updated the version at the first post's link so that it does no searching whatsoever if you start your query with a "+" sign. Link to comment
mccamel Posted March 28, 2013 Share Posted March 28, 2013 Sorry, the parser syntax is fixed by Things and out of my control. I've updated the version at the first post's link so that it does no searching whatsoever if you start your query with a "+" sign. Excellent, thank you for the prompt update Link to comment
phyllisstein Posted March 30, 2013 Author Share Posted March 30, 2013 Awesome, thx a lot for adding this repo!! Now all we need is alf for obj-c No problem! I just pushed the final commit, so everything's up to date as of now. As for an Objective-C version of alp, I'd be lying if I said it didn't cross my mind after the fifth or sixth hand-typed "<item>" string. Link to comment
credford Posted April 1, 2013 Share Posted April 1, 2013 (edited) This workflow isn't working for me at all. When I type "things" it just hangs and creates a process that blows away my CPU and slows my system (which I then have to kill using Activity Monitor). I opened your source code for act.py and noticed that you import "alp". I ran "easy_install alp" and seem to have installed it. However, the workflow is still non-functional and behaves the same. How do I install this? Edited April 1, 2013 by credford Link to comment
phyllisstein Posted April 3, 2013 Author Share Posted April 3, 2013 I'm sorry it's giving you so much trouble, and I'm sorry it took me so long to get to this. Sick as a dog for the past few days. For future reference, "alp" is a Python module a few forum users and I threw together that's bundled with the workflow. I'm not sure what easy_install installed, but it's not that. The only thing I can suggest is that you try navigating to the workflow's folder in the Terminal and running ./ThingsWorkflow directly, to see if it gives you any usable errors. I'll take a look through the code to see if there are any likely performance hangups in the meantime. Link to comment
conrey Posted April 3, 2013 Share Posted April 3, 2013 So I'm having the same issue where Alfred just hangs. I also don't know where to run the terminal command you posted (or I'm doing it wrong). Any ideas? Link to comment
phyllisstein Posted April 3, 2013 Author Share Posted April 3, 2013 Here's a screencast showing the fastest way to get to the workflow's directory in the Terminal: http://d.pr/v/DBrO Link to comment
credford Posted April 3, 2013 Share Posted April 3, 2013 Okay. I removed whatever easy_install installed. Same issues still: huge performance hit (99% CPU) from ThingsWorkflow which I have to terminate in Activity Monitor and no results. I ran ./ThingsWorkflow and it is not giving me any obvious errors, though it did not perform as well as your screencast. Should I post its output here? Link to comment
conrey Posted April 3, 2013 Share Posted April 3, 2013 Here's a screencast showing the fastest way to get to the workflow's directory in the Terminal: http://d.pr/v/DBrO So my terminal just churns and hangs after I ran the workflow file. No voiceover makes it unsure of what I should be expecting Link to comment
phyllisstein Posted April 3, 2013 Author Share Posted April 3, 2013 Okay. I removed whatever easy_install installed. Same issues still: huge performance hit (99% CPU) from ThingsWorkflow which I have to terminate in Activity Monitor and no results. I ran ./ThingsWorkflow and it is not giving me any obvious errors, though it did not perform as well as your screencast. Should I post its output here? How long did it take to spit something out? The performance issues are obviously unacceptable, but just so I have some idea. So my terminal just churns and hangs after I ran the workflow file. No voiceover makes it unsure of what I should be expecting About how long do you give it before you kill it? Just trying to get a better feel for what's going on. Could you both tell me what your system specs are—in particular, which processor and which version of OS X you're using? And maybe give me a sense for how long you've been using Things, how many tasks you've fed it, that sort of thing? The Obj-C code that drives it is really ridiculously basic, so the only real candidate for where the performance is hanging is with the ScriptingBridge stuff—which may just turn out to be slow if it's having to pass a lot of tasks and projects through. You could try running this command, again from the workflow's folder, and seeing if you still get a hang: ./ThingsWorkflow "+This is a test" If it still hangs, the problem is that I compiled it stupidly; if not, it's probably a ScriptingBridge issue. Link to comment
conrey Posted April 3, 2013 Share Posted April 3, 2013 About how long do you give it before you kill it? Just trying to get a better feel for what's going on. Could you both tell me what your system specs are—in particular, which processor and which version of OS X you're using? And maybe give me a sense for how long you've been using Things, how many tasks you've fed it, that sort of thing? The Obj-C code that drives it is really ridiculously basic, so the only real candidate for where the performance is hanging is with the ScriptingBridge stuff—which may just turn out to be slow if it's having to pass a lot of tasks and projects through. You could try running this command, again from the workflow's folder, and seeing if you still get a hang: ./ThingsWorkflow "+This is a test" If it still hangs, the problem is that I compiled it stupidly; if not, it's probably a ScriptingBridge issue. I let it run for a few minutes, the bigger issue is it starts eating up my RAM pretty fast. Just had activity monitor open while I tried to use alfred to add a test task and it ate up 2.5GB of RAM and slowed my MBA (4GB of ram total) to a crawl. I've been using Things for 4+ years so that may be an issue. (MountainLion, most recent versions of OSX, Things and Alfred) Link to comment
phyllisstein Posted April 3, 2013 Author Share Posted April 3, 2013 I let it run for a few minutes, the bigger issue is it starts eating up my RAM pretty fast. Just had activity monitor open while I tried to use alfred to add a test task and it ate up 2.5GB of RAM and slowed my MBA (4GB of ram total) to a crawl. I've been using Things for 4+ years so that may be an issue. (MountainLion, most recent versions of OSX, Things and Alfred) Oy, probably. Well, maybe try the AppleScript-only version and see if it's any faster (though I don't know that it will be, since I believe that ScriptingBridge and AppleScript both access data the same way). You can get it here. Drawbacks are that it sometimes displays projects as both projects and single tasks, and anything with a comma in it will be treated as two tasks. I abandoned it because there's pretty much no way to work around those problems. And, again, it may not be any faster in the end. In the meantime, I'll look into prying into Things' DB without AppleScript. Link to comment
credford Posted April 3, 2013 Share Posted April 3, 2013 I've been using Things for about 2 years, so I'm guessing this is the issue. You may be able to mitigate performance issues if you omit entries from the Logbook from processing until they are requested. Though this is just a guess since I can't get the workflow going. Link to comment
phyllisstein Posted April 3, 2013 Author Share Posted April 3, 2013 I've been using Things for about 2 years, so I'm guessing this is the issue. You may be able to mitigate performance issues if you omit entries from the Logbook from processing until they are requested. Though this is just a guess since I can't get the workflow going. I mean, see if the AppleScript version works any better. Omitting Logbook entries actually takes MORE time, not less, because there's no way I can see with AS and SB to get only open tasks—I have to iterate through each task and check its status. Pulling that out fixed an earlier performance hang. Link to comment
credford Posted April 3, 2013 Share Posted April 3, 2013 (edited) Okay. I tried the AppleScript version. It appears to just transfer the performance cost to Things itself, which becomes non-functional and must be killed. Omitting Logbook entries actually takes MORE time, not less, because there's no way I can see with AS and SB to get only open tasks—I have to iterate through each task and check its status. Pulling that out fixed an earlier performance hang. I strongly suspect the performance issues Conrey and I are experiencing are due to having huge Logbooks from years of daily use. From what you are saying, the Things AppleScript support does not provide a O(1) method for filtering out Logbook tasks (and instead requires the prohibitively long O(N) iterative check you reference). If this is the case, I doubt your workflow will be able to support long-time Things users, unfortunately. Edited April 3, 2013 by credford Link to comment
phyllisstein Posted April 3, 2013 Author Share Posted April 3, 2013 Okay. I tried the AppleScript version. It appears to just transfer the performance cost to Things itself, which becomes non-functional and must be killed. I strongly suspect the performance issues Conrey and I are experiencing are due to having huge Logbooks from years of daily use. From what you are saying, the Things AppleScript support does not provide a O(1) method for filtering out Logbook tasks (and instead requires the prohibitively long O(N) iterative check you reference). If this is the case, I doubt your workflow will be able to support long-time Things users, unfortunately. That appears to be the case. However, on the plus side, a little investigation turned up the SQLite database where Things stores its things, which database will almost certainly be easier to work with than either AppleScript or ScriptingBridge. So I'll just need a day or two to bone up on my SQL, but I should be able to get a working version out soon. Link to comment
credford Posted April 3, 2013 Share Posted April 3, 2013 That would be awesome. I appreciate the work, considering this is a personal project. Link to comment
phyllisstein Posted April 4, 2013 Author Share Posted April 4, 2013 That would be awesome. I appreciate the work, considering this is a personal project. My pleasure; hate to have my name on anything broke-ass. I've just uploaded a new version that queries the Things SQLite database directly, and should (should) provide some performance and reliability improvements. It's quick as all get out on my machine, anyway, but I've only been in the Things habit since about December, so your mileage &c. You can download it at http://alfred.daniel.sh/Workflows/Things.alfredworkflow Link to comment
conrey Posted April 4, 2013 Share Posted April 4, 2013 My pleasure; hate to have my name on anything broke-ass. I've just uploaded a new version that queries the Things SQLite database directly, and should (should) provide some performance and reliability improvements. It's quick as all get out on my machine, anyway, but I've only been in the Things habit since about December, so your mileage &c. You can download it at http://alfred.daniel.sh/Workflows/Things.alfredworkflow Success! Adding tasks like a boss now - no space between the + and " for maximal success. SQLite saved it. Thanks a ton! Link to comment
phyllisstein Posted April 4, 2013 Author Share Posted April 4, 2013 Success! Adding tasks like a boss now - no space between the + and " for maximal success. SQLite saved it. Thanks a ton! Splendid! I'm so glad we found a solution. Remember, too that the "+" is only to force creation of a task—you can also just enter things Foo bar baz qux and it'll search for items matching "Foo bar baz qux" while giving you the option to create a new "Foo bar baz qux" task. Though I just noticed that tagging is a bit dicey with that method, so watch Alleyoop for updates. I'm also hoping to switch the matching algorithm to jlegewie's fuzzy matcher. So count those as the next two big changes on the horizon. Link to comment
credford Posted April 4, 2013 Share Posted April 4, 2013 Thanks. Speed is not an issue anymore and I am able to add tasks. However, unfortunately, I don't see any feedback in the Alfred result list (e.g. when only typing "things" or when searching). Link to comment
phyllisstein Posted April 4, 2013 Author Share Posted April 4, 2013 (edited) Thanks. Speed is not an issue anymore and I am able to add tasks. However, unfortunately, I don't see any feedback in the Alfred result list (e.g. when only typing "things" or when searching). Hm, that's odd! But at least we're getting somewhere. Try that trick of changing the script filter command to python feedback.py {query} 2>&1 | tee feedback.log and let me know what the log comes up with. We'll get this sorted yet. Edited April 4, 2013 by phyllisstein Link to comment
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now