bean__ has quit [Quit: Computer has gone to sleep.]
rickmasta has quit [Quit: Leaving...]
txdv has quit [Read error: Connection reset by peer]
txdv has joined #cinch
leftylink has quit [Remote host closed the connection]
leftylink has joined #cinch
postmodern has quit [Remote host closed the connection]
davidh_ has joined #cinch
<davidh_>
anybody have cinch-memo working with 2.0.4?
<davidh_>
or an alternative?
<dominikh>
why wouldn't it work?
<dominikh>
it's been written for 2.x
<davidh_>
I keep getting Redis::TimeoutError
<dominikh>
well, that looks like an issue with redis ;)
<davidh_>
and I had to change the gemspec for it to even work
<dominikh>
oh, huh, hold on
<davidh_>
~> 1.1.1
<dominikh>
oh, heh, looks like it's for 1.x
<dominikh>
(the redis timeout is probably unrelated to that, tho)
<dominikh>
looking at the code, it would probably work with 2.x without requiring any modifications (other than the gemspec)
<davidh_>
I did add :use_prefix => false
<davidh_>
shouldn't make any difference
<dominikh>
nope
<dominikh>
have you configured redis properly? are you using the correct connection details in the plugin configuration?
<davidh_>
in cinch-memo configuration?
<dominikh>
yea
<davidh_>
ah. I thougt that meant the irc port. /blush/
<dominikh>
why would it care about that ;)
<davidh_>
lol, its working now. sorry for your trouble. ;)
<dominikh>
no problem
davidh_ has left #cinch [#cinch]
<leftylink>
hmm, I'm seeing some odd behavior with my cinch bot, and I'm not sure what to make of it
<dominikh>
what kind of odd behaviour?
<leftylink>
basically, sometimes some messages that should be sent to a channel get "stuck"
<dominikh>
stuck?
<leftylink>
someone runs a command, it should send multiple messages to a channel
<leftylink>
what I see is
<leftylink>
the first one or two of the messages gets sent
<leftylink>
but, the others don't
<leftylink>
until someone else runs a different command
<dominikh>
never? or are they just delayed
<dominikh>
uh
<leftylink>
at which time the old messages get sent
<dominikh>
show me the code of you sending the messages, as well as the log
<dominikh>
and which irc network is that on?
<dominikh>
and which version of cinch?
<leftylink>
I don't have a way to consistently repro though, so this is quite puzzling to me
<dominikh>
well, next time it happens, show me the relevant parts of the log from cinch (that is, beginning with the person invoking the command, cinch sending the messages, it getting stuck, someone sending a second command, the old messages being sent)
<leftylink>
it's the mibbit network, and cinch (2.0.4)
<dominikh>
mibbit has its own network? what's the server address?
<leftylink>
and if you should think the ruby version is somehow important, ruby --version == 'ruby 2.0.0p0 (2013-02-24 revision 39474) [x86_64-linux]'
<leftylink>
irc.mibbit.net
<leftylink>
let me see whether it happens both with multiple m.reply and a single multi-line m.reply
<dominikh>
most importantly, do the messages show up in the log when they get "stuck", or not?
<leftylink>
let's see if I can get at the most recent occurrence of this. just a second
<dominikh>
since I've never seen that before, there are pretty much two options: a bug in your code, or something changed in Ruby 2.x and broke Cinch.
<dominikh>
I hope it's the former :P
<leftylink>
sec
<leftylink>
one the one hand this is code that I'd rather not get around, and on the other hand it seems good to provide full information to help diagnose this -- gist updated with the code for the two plugins
<leftylink>
no, no reason for me to want to hide this particular code
<dominikh>
ashamed of the code, or internal?
<leftylink>
all the good stuff is in the tyrant gem anyway
<dominikh>
that's one long method :P
<dominikh>
so, how reliably can you reproduce it? that is, out of how many attempts does it fail?
JC` has joined #cinch
<leftylink>
you watching this catty?! you can get some of mah codes!!!!
<leftylink>
seems to be less than one out of every 20 attempts, maybe even elss frequent than that
<leftylink>
let's see if i can't do it right now
<dominikh>
meh, that's terrible for debugging purposes
<JC`>
hello, all. i know this is probably a broader ruby concept, but how can i reference a specific user in the hash returned by Cinch's Channel.users?
<JC`>
unfortunately, now i'm getting bitten by an undefined method error for irc_downcase. i noticed this same problem when i tried to do some_channel.opped? "Bob"
<dominikh>
JC`: a) that code wouldn't ever make sense. User#last_nick contains the nick a user had before changing his nick. if he changed it, there won't be an entry for the old nick anymore
<dominikh>
b) if the user never changed his nick, last_nick will be nil
<JC`>
last_nick did have a nick, but i see your point
<dominikh>
it did not, otherwise it wouldn't complain about it being nil
<JC`>
i don't suppose you know of a way to ignore the extra regex matches, too?
<Cinchy>
[gist] plugin_management.rb (at gist.github.com, dominikh on 2013-04-14 13:17)
<dominikh>
that there is the only version, but it really should also stop and get rid of timers
<leftylink>
let me check on this real quick
<leftylink>
for some reason I thought that once I reloaded a plugin, timers weren't firing again, but I'll whip up a small bot to test that
<leftylink>
ah
<leftylink>
so, very simple plugin, with timer 15, method: :simpletimer
<leftylink>
and def simpletimer Channel('#lozenges').send('the timer has fired!')
<leftylink>
!plugin load that plugin, but timer never fires
<dominikh>
ah, yeah, I see the issue
<dominikh>
hm.
<dominikh>
registered_plugin = @bot.plugins.register_plugin(const); registered_plugin.timers.each {|timer| timer.start } would start them, but unfortunately also starts them if they've been marked to not start automatically
<dominikh>
oh, and it would have to be registered_plugin = @bot.plugins.register_plugin(const).last
<leftylink>
that will probably work fine for my purposes, since I don't have any timers that don't start automatically
<dominikh>
ok
<leftylink>
great, looking good. now, let's see if I can get meta and !plugin reload the !plugin reload plugin...
<dominikh>
you can
<dominikh>
even though that fact surprises me every time :P
<Liru>
leftylink: I occasionally have the same problem as you
<Liru>
The one where some messages get stuck in queue and don't send until someone else sends a command
<dominikh>
Liru: Ruby 2, too?
<Liru>
Yep
<dominikh>
sounds like a Ruby 2 issue then.
<leftylink>
ah interesting. I wonder what changed
<dominikh>
me too...
<dominikh>
oh I have an idea...
<dominikh>
maybe, anyway
<dominikh>
we inherit from Queue to implement pushing at the front. effectively we just copied the 1.9.x push method and turned it into an unshift. looks like 2.x has redone some of the queue internals wrt waking up waiting threads
<leftylink>
oh... I was about to ask if catty has this problem too, but catty runs clemmy on EC2 which won't have ruby 2.0
<dominikh>
that'd explain that
<dominikh>
so yeah, I'll need to fix that
bean__ has joined #cinch
<dominikh>
but the obvious solution for now is to use ruby 1.9
<dominikh>
on the other hand, I don't think I'm using the unshift method at all anymore, so it really shouldn't be breaking…
<dominikh>
and I can't reproduce it, either, which is fun.
rickmasta has quit [Quit: Leaving...]
<catepillar>
yay ruby2.0 introduced bugs!
rickmasta has joined #cinch
<dominikh>
who would've expected that!
<catepillar>
and lefty is right, my server is running 1.9
<dominikh>
keep it that way :)
<catepillar>
my development machine is 2.0, lol
<dominikh>
unless an epiphany strikes me, I have no clue how to debug or fix this issue.
<catepillar>
debugging that is tough
<catepillar>
if it only could be reproduced reliably
<dominikh>
and frankly I expect it to be a Ruby bug, either in ConditionVariable, or in Queue
v0n has joined #cinch
<catepillar>
both of those are thread based, no?
<dominikh>
that's what they're for
<dominikh>
we use Queue, Queue in 2.0 uses ConditionVariable for signalling
<dominikh>
QUeue#pop waits for an element, Queue#push uses CV to signal waiting threads that there's a new element
<dominikh>
and apparently that's not working properly, else Cinch wouldn't wait with sending the messages
<dominikh>
oooor it's something entirely different
<catepillar>
oh?
<dominikh>
well since I can't reproduce it I'm just guessing here.
<catepillar>
what's the difference between send and safe_send?
<dominikh>
the safe variant removes unprintable characters from the message
<catepillar>
nice
<catepillar>
so it would just leave ascii stuff behind?
<dominikh>
nah, unicode too :P
<dominikh>
even though I'm wondering if I've might broken that