<olistik>
with this trick I can't see exceptions anymore
<olistik>
but I'm not sure bot.quit has been called properly..
<olistik>
indeed, the message I can see from the bot quitting is only this one: "peephole-42 has left IRC (Client Quit)"
<olistik>
so, it quits gracefully but without sending the proper quit message
<leftylink>
we should check whether the irc server in question is respecting client-sent quit messages (and we can also check in logs whether the bot sent the right quit message)
<leftylink>
it is an interesting question though
<olistik>
I'm using irc.freenode.org on #bot-test
<olistik>
I think I'll dive deeper into Cinch internals
<olistik>
imo, it would be better to provide system callbacks out of the box
<dominikh>
a) most channels block the quit messages of unregistered users b) I have no idea what you mean by system callbacks
<olistik>
dominikh: b) responding to signals sent to the process running the cinch client
<olistik>
dominikh: a) that's probably the case :-)
<dominikh>
that's none of cinch's business. cinch handles irc, not the process abstraction of your OS
<olistik>
dominikh: regarding b) is there another way, not implying sending irc messages, to gracefully stop the process
<olistik>
?
<dominikh>
yes. call Bot#quit.
<dominikh>
it doesn't care where or why the method gets called
<leftylink>
even if my bot identifies, freenode isn't taking its quit message. perhaps freenode just doesn't take quit messages from anyone
<olistik>
dominikh: is everything alright? :-) Just asking questions here..
<dominikh>
install a signal handler (trap) and do your thing
<dominikh>
leftylink: iirc there's a channel mode to block quit messages in general. generally speaking, freenode does allow them.
<olistik>
Signal.trap('INT') do |signal_number|
<olistik>
bot.quit
<olistik>
exit 0
<olistik>
end
<dominikh>
for example.
<leftylink>
yeah what happens there is ^C/home/leftylink/.gem/ruby/2.2.0/gems/cinch-2.2.3/lib/cinch/message_queue.rb:46:in `synchronize': can't be called from trap context (ThreadError)
<dominikh>
the only valid workaround I can think of involves polling a variable, and that sounds awful
<leftylink>
this may be better suited for a ruby-internals place or something but perhaps I collect my thoughts somewhere before bringing them somewhere public
<leftylink>
s/public/more public/ I guess
<leftylink>
acquiring a mutex could block for an unknown amount of time, so I guess it could be a noble cause to say you shouldn't do that in a trap
<leftylink>
and yet, Thread.join is OK, apparently? and that also implies we're doing a context switch inside a trap. well, I hope that's not unsafe
<leftylink>
oy vey
<leftylink>
I'll look at message_queue and see if I can think of something, but polling does sound quite silly
<dominikh>
technically, Ruby 2's behaviour is more correct than that of 1.9. a trap *should* do the minimal amount of work, that's been known outside of Ruby for a long time
<dominikh>
but it's also a pain in the ass
<leftylink>
also I think I made a conceptual error... of course it should be OK to do a context swich inside a trap... all context swiches happen inside traps. but I guess I was complaining about context switches that the user specifically requests, rather than the system
<leftylink>
heh
apt-get_ has joined #cinch
sarkyniin has quit [Ping timeout: 252 seconds]
Wobbley has quit [Remote host closed the connection]
green-big-frog has quit [Quit: Does this rag smell like chloroform to you?]
argoneus has quit [Ping timeout: 255 seconds]
argoneus has joined #cinch
postmodern has joined #cinch
Wobbley has joined #cinch
Azure has quit [Quit: Oops.]
Azure has joined #cinch
apt-get_ has quit [Ping timeout: 256 seconds]
apt-get_ has joined #cinch
apt-get_ has quit [Client Quit]
Azure has quit [Ping timeout: 255 seconds]
Azure has joined #cinch
thews has quit [Read error: Connection reset by peer]