00:28 <isd> Stuff tends to show up whenever someone stumbles across it and says "hey this is neat!"

00:29 <isd> I had a blog post of mine from January show up at the top a few weeks ago.

00:38 <isd> Does sandstorm provide any way for a grain to be notified and respond when it is about to be upgraded to a new version of the app? I imagine no, but it would be useful; upgrading my irc-idler grains causes a dicsonnect, and because they don't do a clean shutdown, when the start back up again, freenode hasn't figured out that the client disappeared, so they end up with a different nick for a while.

00:39 <isd> So it would be nice to be able to respond by sending a QUIT to the server and actually closing the connections, instead of just dying.

00:39 <isd> Could do this manually beforehand, but...

00:40 <isd> Or, I guess, more generally is there a way for an app to tell that it's going to be killed, despite holding a wake lock?

06:33 <mrdon> is there an automatic encrypted grain backup to glacier app that I'm missing?

14:33 <digitalcircuit> isd: That also sounds useful for, say, Davros, too - while error recovery from partial uploads is possible, it'd be cleaner to just remove the temporary files on shutdown. Sandstorm probably would need to enforce a time limit of some sort for shutdown to avoid misbehaving grains getting stuck.

15:20 <phoenix1796> Hi guys o/

15:22 <phoenix1796> We are hositing a hackathon at our college and wanted to connect with sandstorm.io , for the same , any ideas on what would be the best way to approach them ?

15:23 <phoenix1796> *hosting

15:23 <phoenix1796> The venue is ABES Engg. College , Ghaziabad , U.P.

15:23 <phoenix1796> India

15:27 <dwrensha> phoenix1796: asheesh would probably love to talk to you

15:27 <dwrensha> he might not be around today, as it's the weekend

15:28 <dwrensha> but you could try emailing asheesh@sandstorm.io

15:28 <phoenix1796> @dwrensha will do , thanks for the quick reply :)

17:46 <isd> digitalcircuit: you probably need the recovery code anyway; can't control when the machine dies on you.

17:48 <isd> But being notified that your wake lock is being revoked, and given a grace period to clean up would be very useful.

17:48 <digitalcircuit> ...exactly :)

17:48 <digitalcircuit> isd: Right, as I'm guessing is the same with irc-idler. But there might be some situations where there's less recovery work if you get notified to shutdown.

17:49 <isd> In my case, if I don't seed the QUIT and formally close the connection, and then I start it up again quickly, I get to be "isd1" until freenode figures out that the other connection is dead.

17:49 <isd> You can't really fix that via startup recovery code

17:50 <liam> you do have /msg nickserv ghost

17:50 <isd> I guess my thought with davros is that if you do that cleanup on startup anyway, you don't really gain anything by doing it on shutdown too. But maybe I'm missing something.

17:51 <isd> liam: didn't know about that, thanks!

17:51 <liam> :)

17:51 <isd> Still, would be nice if irc-idler did proper shutdowns to avoid that situation.

17:51 <liam> some channels don't let you change nick while in them, so i would recommend doing that before all of your JOINs

17:52 <isd> yeah, unfortuntely I have auto-join on for some of those

17:52 <isd> the other annoying thing that happens is a few of those tell me to identify before they'll let me in; it's a weird scenario

17:52 <isd> speaking of which, I think I've spotted another bug. Does anyone else see an isd1 in this room right now?

17:53 <liam> no

17:53 <isd> okay, that's what I thought. guess I have some debugging to do

18:11 <isd> Dogfooding a new version; back in a few

18:12 <digitalcircuit> isd: Cleanup on startup in Davros might impact latency for the sync API.. maybe? I'm not sure how it's implemented.

18:12 <digitalcircuit> Does irc-idler make use of SASL? That'd avoid any race conditions with identifying/joining.

18:18 <isd> hrm, is there a way to do something similar to ghost for a nick that isn't registered? I am having this problem on oftc right now.

18:19 <liam> no. It would be unsafe to forcibly disconnect random people because "that's my nick" when it isn't really

18:20 <isd> Well yeah. Was more looking for a "can you please send the ping *now*" message, but I'm not surprised it doesn't exist.

18:20 <isd> Anyway, it seems to have figured it out

18:20 <liam> even if it did that, you'd still have to wait ~27X seconds for it to time out

18:21 <isd> Yeah. that's still a good bit faster than it sometimes takes though. Anyway, life goes on.

18:22 <asheesh> isd: You could imagine irc-idler detecting an old version of itself leaving the channel, and renaming itself to its desired nick.

18:22 <asheesh> As a random fwiw

18:22 <isd> asheesh: the problem I'm trying to solve is to get the old version of itself to disappear in the first place

18:23 <asheesh> Yeah, but in some cases that's impossible :)

18:23 <isd> asheesh: indeed. If the sandstorm box just barfs you're out of luck until the irc server figures it out

18:24 <isd> and in those cases it seems to handle things like most clients would without the proxy -- you pick a different nick, and you can send a NICK message to switch once it's freed up, or ust ghost if available

18:24 <isd> but it would be nice if clean shutdown was a possibilty, which right now it isn't

18:25 <isd> I could add a manual version of that without the wakelock support I suppose.

18:25 <isd> On my mental TODO list is to add something NickServ like for administering irc-idler without having to go to the web ui

18:26 <isd> I have hazy memories of reading about something like the wakelock-revoke notification, so maybe it does exist? I may have completely imagined that though.

18:31 <isd> Just one more bug I want to fix for alpha 1!

18:37 <liam> zarvox, progress: http://i.imgur.com/SaEKUK4.png

18:38 <liam> i had to manually run the hooks since those are broken but w/e

19:42 <isd> Alpha 1 is complete! I'm going to dogfood it for a day, maybe touch up the docs a bit, and probably tomorrow send an email to sandstorm-dev soliciting alpha testers.

19:43 <isd> Switching over to the new version; connection will die for a moment.

19:47 <isd> Huzzah! it's still super janky, but I've fixed the stuff that was perpetually apparent in my day-to-day use.