MuppetGate

I'm updating the Packal Workflow Search and it reckons that it's upgrading from 1.1.3 => 1.1.2 And so every time I look at the updater, it seems to need updating.

Okay, apparently I had more time than I thought. The 'ymwdHMs' should now produce the same (accurate) results as 'long' Version 1.5 is on Packal.org

Okay, that makes sense. Thanks.

This might be similar to a problem I've just reported: http://www.alfredforum.com/topic/4617-mini-player-not-finding-isaac-delusion/

Actually, it probably won't find a couple of other artists for the same reason. Even after checking the location of the library and a couple of CMD+R resets, the mini player refused to see this artist, but I can find his track by name. There are two artist fields in the track meta date: Artist Album Artist Although the Artist field is set to Isaac Delusion, the Album Artist field is set to 'Various Artists'. When I change that field to 'Isaac Delusion', the Mini-player can now see the artist. Not quite sure what's going on here, but I suspect that Alfred only looks for the artist name in Album Artist field. Anyway, I think Alfred should index on both fields.

I might look at the formatting again when I have more time. Thanks.

Right, that was a mostly a bug. Turns out that the decision to supply the current time to anniversaries was not a good one. I've tuned up the formatting stuff (ymwdhMs) but due to uneven months, it's never going to be as accurate as just going for 'long' as the format, which calculates the whole thing in one go. A new version (1.4) is now up on Packal. You should delete Iva's anniversary and create it again. P.S. I've also added start_bst and end_bst for British Summer time. For example: dcalc start_bst

Quick question: Did you mean '29 years' in your last example? In any case you shouldn't have 12 months as part of any answer. I think this probably due to a rounding error in the calculation of the formats that are not 'long' (which is more accurate because it is calculated differently). I'll look into it.

And finally, version 1.3! The big change is that the function call go at the end, so instead of this: dcalc wn today You now write this: dcalc today wn I made the change to save keystrokes mainly; you now don't have to tap your way back to the start of the command to change the function, and it's not really a function; it's a bit of formatting that should really happen at the end of the calculation dcalc alfred + 1d wd That will tell you the day of the week one day after Alfred's next anniversary.

Hi Shawn. Even after I update the Packal Updater, it still reads as version 0.4 and says it can still be updated to version 1.0 This is both from inside Alfred and the GUI. Something I'm missing?

Right, we're up to version 1.2 with clearer instructions regarding the addition of anniversaries. I've also revamped the anniversary function so it doesn't choke if someone's birthday is on the 29th of February, but bear in mind that the next occurrence of this anniversary might be further away than you think.

Woohoo!!

Okay, so that's working okay. Good. Right, I've sent you a PM with a wodge of code in it that might help me track down the problem. Is anyone else seeing the same problem?

Yup, kinda what it does though ...

Quick question: What happens if you enter dcalcshow list

Right, I'm going to have to sleep on this one, I think. Can't think why this wouldn't work on your machine. Always tricky when you can't see it running ...

Okay, I imagine you're entering in the correct date format. The dcalcset format seems to be okay at my end too. I'll try loading it from packal to make sure I haven't missed anything. Are you running with Python 2.7?

Fixed.

Thanks very much for that. I'll add in the date format (not sure how I managed to miss it to be honest). I figure that any additional outputs should be pretty easy for anyone to add; that's why I decided to keep the extra text down to a minimum, and tried to make it easy to parse. But a great suggestion, and I'm going to try out Fantastical.

Done! I'll get the hang of this one day . . .

Yup. It certainly does!

Me again. I've just dropped a new version of the date calculator onto Packal. Fixes a few bugs and simplifies the error reporting. Also added a few macros shortcuts for today, tomorrow, days of the week and Christmas

Thanks, but I think I prefer Python as nature intended, now that I'm getting used to it. But that __future__ stuff is really . . . wow.

Oh, I always indent code, but I've never come across a language that uses whitespace to decide intent. I'm used to stuff like IF ... ENDIF or braces for that kind of stuff. It just struck me as really bizarre. Still, I also like cheese and jam in the same sandwich, so what is really just a language quirk didn't strike me as a good reason not to give it a go. Having played with Python for a week or so, here's what I've noticed about this whole whitespace thing: Because I don't have to use extra statements to denote the end of a code block, I type less code. If it really bothered me that much, I figured I could always put in a comment to fake it. (#ENDIF for example). As it happened, it took about five minutes to get used it, so I didn't bother. In my opinion, Python code is the easiest to read. It is much easier to see the structure of properly-indented code if extraneous stuff, like endifs and brackets, is taken out. This is just my opinion of course. So I'm something of a convert, I think.

Have to say that I've become a big Python fan over the past week or so. Once I got over the indenting thing ...