02:06 <bosma> I do https://gist.github.com/anonymous/09c8e18ef5e349a6e371 to set a value from a rabbitmq subscription. I'd ideally like to move that code into the plugin class (avoiding the global var), so I can have updates trigger methods in the class.

02:07 <bosma> I put it in the initialize but I'm pretty sure it wasn't working there

02:08 <bosma> what would be a nice place to put that code to get rid of global vars and make it have access to plugin methods?

02:29 <bosma> scratch that it does work in initialize. guess was another bug.

06:25 <dominikh> bosma: if you overwrite a plugin's initialize, you have to call super.

06:25 <dominikh> otherwise the plugin won't work correctly

06:25 <bosma> yeah I do that. I think there was something wrong with my code unrelated when I tested.

06:25 <dominikh> alright

06:25 <bosma> Everything all good

06:25 <bosma> ##forextraders 500x eurusd bot :D

06:26 <dominikh> sorry, not into trading :P

06:26 <bosma> wish the ruby bindings worked for zeromq on windows

06:27 <bosma> overheads a bit much but rabbitmq seems to have some good features

06:27 <dominikh> could always host it on one of the many systems better suited for it than Windows ;)

06:27 <bosma> :)

06:28 <bosma> yeah I value gaming too much. should get a linux dev environment on a vm

06:28 <bosma> had freebsd as my desktop for awhile would love to go back

06:29 <dominikh> had you picked linux, you could at least play *some* popular games

06:30 <bosma> you have no idea the amount of things I've been working on where every solution boils down to get off windows haha

06:31 <bosma> na directx / nvid drivers so much better. vm is solution

06:32 <bosma> thanks for the great framework btw

06:32 <dominikh> no problem

06:33 <bosma> oo you use void?

06:33 <bosma> was recommended

06:33 <dominikh> I do, yes

06:33 <dominikh> I'm a package maintainer for Void, even.

06:33 <bosma> should have a bitcoin address donation ;)

06:34 <bosma> awesome. I'll try it out

16:16 <awkisopen> so here's something that's going to sound like a pointless question: is there a way to accept the risk and force a plugin hook to run on the main thread?

16:16 <awkisopen> I realize this is a risky thing to do and goes against the design, but there is a strange use case

16:17 <awkisopen> when someone identifies to nickserv on any server, there's a quick leave-join that technically happens one after the other, but the information reaches the client at about the same time

16:17 <awkisopen> if you're trying to keep track of user state, it's a toss-up if the "changing host" leave happens first or the rejoin with the new hostname happens first. in general it tends to go in the right order, but there's the possibility it does not

16:18 <awkisopen> for myself I'm probably going to just keep track of recent leaves and joins and compare timestamps and make a few assumptions accordingly

16:20 <dominikh> no, that's one of the flaws of Cinch; there's no guaranteed way to determine order between messages. the message's timestamp should be "good enough"

16:21 <dominikh> actually, let me check…

16:21 <awkisopen> also, thank you again for the super quick patch yesterday, haha

16:22 <awkisopen> that's the second time I've come in here, said something was a bit off, and it was fixed within the hour

16:22 <dominikh> what was the first one?

16:22 <awkisopen> authname wasn't returning the right value on snoonet because the order of information from WHOIS wasn't in the order cinch expected

16:22 <dominikh> ah. always those WHOIS

16:22 <awkisopen> tricky bastards

16:23 <dominikh> anyway, Message#time is your best bet to get order, I think its precision should be nanoseconds (but probably depends on the OS)

16:24 <awkisopen> it's a linux server so I don't doubt it'll be nanoseconds

16:24 <dominikh> there's no way to disable threading. Cinch's core doesn't technically know about plugins to begin with, they're all individual handlers. and there's no (public) way of forcing a handler to run on the main thread

16:24 <dominikh> hm, there might be a hack

16:25 <dominikh> 1 sec

16:25 <awkisopen> yeah the only way I could ever think of it working is if you could specify a mutex when hooking events

16:25 <dominikh> hm no, even the hack would still be racy. one could have a per-plugin mutex, but that still doesn't mean that messages arive in the correct order

16:25 <dominikh> arrive, either

16:26 <awkisopen> dang

16:27 <awkisopen> the time comparison is a good one, now I'm just trying to work out /where/ I'd do the comparison. I guess both my join and leave methods could check for any other recent joins/leaves

16:27 <dominikh> yeah

16:27 <dominikh> make sure to have a mutex around the data structure you use for storing joins/leaves

16:28 <awkisopen> if I assigned both :leaving and :join to the same method, and put that method's contents in a mutex, would that still be racy? (I don't know enough about cinch's design to answer that myself)

16:29 <dominikh> yes, it would be. for each incoming message, we parse it and find the handler(s) to execute. we then spawn a thread and execute the handler.

16:29 <awkisopen> basically depends on how the hooks are actually called

16:29 <awkisopen> gotcha

16:29 <dominikh> once the threads are created, you don't know in which order they'll be scheduled

16:31 <dominikh> technically, I could add a per-handler mutex/queue, but that'd be a new feature, and I'm not sure I want to add new features to Cinch at this point

16:31 <awkisopen> I hear that

16:31 <dominikh> also… it wouldn't help exactly; I don't think a single handler can listen to multiple events

16:31 <dominikh> and two separate handlers wouldn't have the mutex again

16:33 <dominikh> oh, actually you can, hm.

16:34 <dominikh> okay, no, you can't. yeah, it'd be changing too much at this point. sorry.

16:39 <awkisopen> I think I figured out a solution for myself anyway: keep track of how many joins or leaves each user has, if they have an equal number or greater or leaves than joins, they've left; otherwise they're still on. that should work even if things get scheduled wonkily

16:39 <dominikh> well

16:40 <dominikh> I hope that if you restart the bot and it joins a channel full of people, it'll know that those people joined at some point

16:40 <dominikh> also, enjoy the race while you process the initial user list and people join/leave at the same time...

16:40 <awkisopen> I only have to track them when they've started interacting with the bot in a particular way, which means they have to be on in any case

16:55 <dominikh> why are you listening to joins and parts, anyway?

16:56 <dominikh> ah, the "knowing the host of someone who left" stuff, I remember

16:57 <awkisopen> yeah. each user has some data associated with them, and they're authenticated based on their authname or, failing that, their host

16:57 <awkisopen> obviously hosts are only good for temporary storage and they're encouraged to register with nickserv

16:57 <dominikh> and why is their authentication relevant once they left?

16:57 <dominikh> what is special about authenticated people leaving?

16:58 <awkisopen> it's a writing channel, and authenticated people can take part in something called a "word sprint," where they write against a timer (time is kept by the bot). if someone leaves, and they were the last person in the sprint, the sprint auto-closes after a minute, to avoid a dead sprint taking space in the channel

16:59 <awkisopen> there's also the matter of waiting for people to finalize their wordcounts at the end of the sprint, and the bot should not wait for someone who is no longer there to perform an action they cannot

16:59 <awkisopen> I could have it ignore both of these things but it leads to a messy channel

16:59 <dominikh> ah, okay

17:00 <awkisopen> anyway, the bot considers two nicks with the same host or same authname to be the same person, for convenience's sake