deanishe

An inverted index or a forward index. Exactly how you structure it depends on which search semantics you want to use. You might want to parse the search keys (in filter() terms) for capital letters or the first letters of words to maintain "of"->"OmniFocus" style searching, or just store the entire key in the DB and rely on sqlite's (awesome) search capabilities. I don't know how ZotQuery users typically search. If you're doing any additional processing, you'd probably want to store the search key in the database as a way of determining if an item has been updated and needs re-indexing.

You shouldn't directly use the query as the filename, as this would break if someone enters "/" in a query, for example. You could use a slugify function or give the cache files random names and keep an index. You should load a cache if query starts with the query of the cached data. So, say you have a cache for the query "cun", that would be loaded for the new query "cunning". Whether you then save another cache for "cunning" is a tricky question (presumably, you'd also already have caches for "cunn", "cunni", "cunnin"). You might want to consider the number of results when deciding whether to cache them. If the parent set only contains, say, 300 entries, it's probably not worth creating another cache. You'd probably want to purge all caches when the underlying data is updated. I wouldn't worry too much about the cache size: instead of duplicating all the data, you can just cache the search keys and some form of ID with which you can look up the actual data in your main dataset. (Unless that's so big it significantly impacts performance.) You could occasionally sweep the cache for old cache files (by last access time, not modification time). Personally, I think creating a proper search index is a much better solution. You can use the background.py module to update the index whenever the data has changed (indexing would be a lot slower than filtering). If you put the index data in an sqlite database, actual search would be super fast.

That's what happens when an author updates a workflow on Packal but forgets to bump the version number. Which is also a bug, but it's with Packal.

That would be the right way to go about it. You'd also need to write a function (that gets run first) to delete any old caches or you'll end up with dozens of copies of the data.

Well, I'd like to take issue with that. Not in a it's-not-my-fault way, but in a Shawn-did-99.9%-of-the-work way. My contribution has been distinctly minimal. This is his (great) idea and his work and any credit belongs to him. Let's compare it to the guy who designs and builds a race car and the guy who tightens the nuts.

Deeply cool. 102 workflows Shawn? How the hell do you remember all the keywords? EDIT: Oh…

It shows me Alfred's birthday and Jesus's birthday.

It does start a new search whenever you change the query. That's how Alfred works. It calls the workflow anew every time you press a key instead of interacting with a longer-running process (that could hold onto its filtered set of results). Ideally, a workflow would create a search index for that particular set of data, but I haven't looked into that yet (I wrote one of the underlying libraries that ZotQuery uses and which provides the filtering functionality). The filter function uses a relatively complex search algorithm (to rate "of", for example, as a better match for "OmniFocus" than for "Duke of York", which is in turn better than "Smirnoff"), and as a result isn't capable of rapidly searching thousands of data (complex code, no search index, relatively slow programming language) unless you turn off some of the filter options. You could try "working with" the search algorithm, i.e. "km" will match "Kant Metaphysics", or if you're prepared to get your hands dirty, you could look at the search options and tinker with ZotQuery's source here and here to whittle down the applied rules to achieve an acceptable compromise between flexibility and performance. I can look into the feasibility of caching "partial" searches and/or creating a search index, but fundamentally, the library on which ZotQuery is based wasn't designed for searching thousands of data without disabling a lot of the "intelligence" of the search algorithm.

Yeah, double-checked the format, deleted the settings file and re-installed before posting. I'm on Mavericks, so Python 2.7. FWIW, python will always refer to the system Python in Alfred, as it doesn't use your PATH. Unless someone was dumb enough to overwrite /usr/bin/python…

And another thing: the workflow description on Packal says "A very basic date calculator". Basic? Premium more like.

It doesn't work for me I followed the instructions above, but "dcalcset list add dean xx-xx-xxxx" give me an "Invalid command" error "dcalcset format" now appears to be an unknown command You also appear to have removed the download link from the OP. It's got links to all the stuff you used to make the workflow (apart from Smirnoff), but there doesn't appear to be one to the actual workflow any more!

AppleScript is utterly insane. I'm so happy they've added JavaScript in Yosemite. I don't like JavaScript at all, but hey, it ain't AppleScript

Good thinking, dfay! Especially sending it to Fantastical. I think Apple Calendar can handle simpler dates, too, but I'm not sure. One minor gripe: yyyy-mm-dd is an international date format, not a US one. Everyone uses it.

No, there's no update. There's some weird bug happening for some users, but I can't figure out what it is because I simply can't duplicate it. I've been in contact with the users to get their log files/XML output, but if I inject their output into my Alfred, it works perfectly for me… I'm currently working on a new version, but it seems to have the same problem. I'm afraid I'm at a total loss over this one

Here's a list of the language codes supported by Google's translate API from https://www.googleapis.com/language/translate/v2/languages (I have an API key): af ar az be bg bn bs ca ceb cs cy da de el en eo es et eu fa fi fr ga gl gu ha hi hmn hr ht hu hy id ig is it iw ja jw ka km kn ko la lo lt lv mi mk mn mr ms mt ne nl no pa pl pt ro ru sk sl so sq sr sv sw ta te th tl tr uk ur vi yi yo zh zh-TW zu

Actually, that is rather surprising.

I don't trust Google Translate in the slightest. Translating is my day job, and I have developed a very healthy, professional distrust of Google Translate. In some situations, it does an exceptionally good job, but in others it's so wide of the mark, it's ridiculous. This particular bug has now been fixed, but it used to translate Wien (Vienna) with Dublin…

It's worth bearing in mind that Google Translate often produces what can be best described as complete bollocks. It's no substitute for a proper dictionary. You might put a bird feeder in your garden to encourage visits from the great tits currently nesting in the area. Google Translate will, like as not, produce some sentence about large breasts…

It doesn't do Klingon??? Jeez, Shawn. Sort it out! Also, I demand Elmer Fudd support.

Pfft! It doesn't know my birthday. USELESS! Nice update I had a look in the workflow directory. There appears to be another copy of the workflow within the workflow. I suspect that wants removing…

It's an easter egg. >>> from __future__ import braces File "<stdin>", line 1 SyntaxError: not a chance >>>

Python's a bit of a special case in this regard. The default version on OS X, 2.7.5, is a little over a year old, but 2.7.x is basically frozen and only subject to bugfixes. There won't be a 2.8, and there won't be any new features for 2.7. 3 was released at the end of 2008, and that's where all new features have been added. The current 3.4 has heaps of cool, new features (a few of which have been backported to 2.7). Thing is, Python 3 has a fundamentally different concept of strings/Unicode (or bytes/Unicode as Py3 sees it) to Py2, and all but the most trivial Py2 code will not run on Py3 unaltered. Many Linux distros now include Python 3 by default, but they also include Python 2 and that's usually the default Python (i.e. what you get when you run /usr/bin/python). I expect that Apple will do the same, and include Python 3 in addition to Python 2. When that does happen, an app like Alfred is faced with the choice of sticking with the existing model of Python 2, enforcing Python 3 (as Sublime Text 3 does), or offering both. And it'd be silly not to offer Python 3, as it's the only version of the language that's gaining new features, and not just bugfixes. The major gotcha of Python 2 is that it allows you to mix encoded text and Unicode without complaint, but it will die in flames if the encoded text contains non-ASCII characters. It's up to the programmer to ensure that encoded text is correctly decoded before mixing it with Unicode. I put a lot of effort into Alfred-Workflow to ensure that it only returns Unicode and correctly encodes/decodes encoded text when required (stdin/stdout, argv, URLs). In most cases, users of Alfred-Workflow won't even need to know about the difference. And it provides helpers to handle the situations where it does become important. Python 3, however, decrees that all text is Unicode, so it will (try to) decode all input from stdin/argv to Unicode and encode stdout/stderr back to whatever the default encoding is. Consequently, it has to get an encoding from somewhere, and that's the environment. Most shell environments specify UTF-8, but for right or wrong, on UNIX (Linux, OS X, etc.) the "default" is ASCII, so if you run a script via launchd/cron/init.d or Alfred, a Python 3 program that runs flawlessly in a shell will die in flames if it is passed or tries to output non-ASCII text in one of those environments. You can kinda sorta get around this with some fairly arcane hacking, but that's way beyond your average workflow coder's knowledge/comfort zone. Basically, few workflows witten in Python 2 would work unaltered in Python 3, and if Alfred wants to support Python 3, it has to set PYTHONIOENCODING=UTF-8, otherwise there'll be loads of people complaining that they can't solve a problem that Python's smartest users haven't been able to reasonably solve…

Perl? I'll put money on it not being version 6

Regarding LANG/LC_*. After a bit of testing (using date and strftime), PHP works fine with en_DE (i.e. produces a German date), Python throws an exception, and the shell date program ignores it and outputs an English date (de_DE gets you a German date). Ruby doesn't natively support locales. For both Python and PHP, it's necessary to explicitly set the locale in code in any case. It's probably not worth the bother, tbh. Workflows that are locale aware seem to be few and far between, and it's hard to second-guess how bilingual users want their software to behave. I wouldn't worry about the Python 3 thing yet. I don't see Apple updating to version 3 any time soon, but seeing as Python 2 has been essentially discontinued, I think it's inevitable that it will happen at some point. (Hopefully, in addition to, not instead of, Python 2). I just figured it's best to be forewarned that non-ASCII input/output in an ASCII environment will cause all manner of breakages and confusion with Python 3 (in most cases, the same code will run flawlessly in a shell where the encoding is UTF-8, but fail when run in Alfred/from launchd/cron where it's ASCII), so it's worth noting down somewhere for when the day comes. It's not specific to NSTask or OS X (the same problem occurs on Linux). It's just the (imo broken) way Python 3 behaves.

I can only speak for Python, but what would work in that case is setting LANG to the preferred language, not the locale. A locale of en_GB means English language, British locale, not British English. So for users who have their language set to English but Region set to Germany/Italy/etc., their locale would be en_DE or en_IT etc., which Python (maybe other languages, too?) chokes totally on. I usually set the locale based on defaults read -g AppleLanguages, not defaults read -g AppleLocale for this reason. With regard to Python 3: when Apple does replace Python 2 with 3, pretty much all workflows will break and need serious editing anyway, as there are significant differences between 2 and 3, but it is extremely difficult to get Python 3 code to run in the ASCII environment that launchd/Alfred use by default. Setting LANG to anything that includes UTF-8 should run Python 3 impeccably. Setting PYTHONIOENCODING=UTF-8 will fix the problem, too.