dominikh changed the topic of #cinch to: The IRC Framework | Latest version: Cinch 2.1.0
postmodern has quit [Quit: Leaving]
ColdBlooder_ has joined #cinch
ColdBlooder has quit [Ping timeout: 265 seconds]
postmodern has joined #cinch
Spami has joined #cinch
rails has quit [Ping timeout: 240 seconds]
XESavant has joined #cinch
Spami has quit [Quit: This computer has gone to sleep]
kludge` has quit [Ping timeout: 252 seconds]
postmodern has quit [Quit: Leaving]
kludge` has joined #cinch
kludge` has quit [Ping timeout: 265 seconds]
kludge` has joined #cinch
ColdBlooder_ has quit [Remote host closed the connection]
aclearman037 has joined #cinch
aclearma_ has joined #cinch
aclearman037 has quit [Ping timeout: 255 seconds]
aclearma_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
aclearman037 has joined #cinch
kludge` has quit [Remote host closed the connection]
kludge` has joined #cinch
cout is now known as P1azma
P1azma is now known as cout
Spami has joined #cinch
Spami has quit [Quit: This computer has gone to sleep]
aclearman037 has left #cinch [#cinch]
<Paradox> dominikh uhh…shit
<Paradox> thats a good question
<dominikh> hehe
<dominikh> yeah. Went with Helpers.sanitize and Helpers#Sanitize now
<Paradox> good enough heh
badeball has joined #cinch
<badeball> is there a way to ensure that a queued message has been sent? or a way to send a message in a blocking way?
<dominikh> unfortunately there isn't :/
<badeball> auch, what a bummer. easiest workaround? accessing the queue from the irc instance and loop-wait until its empty?
<dominikh> there's no valid workaround, either :/
<dominikh> that's all internal state
<dominikh> complex one, at that
<badeball> yeah, I've noticed
<dominikh> I've been pondering adding that feature, but I haven't taken a look yet at how feasible that would be
<badeball> the reason I ask is because we're working on re-exec feature that will reload the application while maintaining the network connection
<badeball> which we've actually gotten to work pretty well
<dominikh> mhm!
<badeball> but we can't actually inform channels that the application is re-execing as the message is just queued and then the application is respawned with a new state
<dominikh> will have to check something in a minute, regarding the queue behaviour when quitting
<badeball> it looks like #quit only queues an exit message (using IRC#send), but if one eg. were to use it within a signal trap, then I guess that message will probably never be sent
<dominikh> there really seems to be no way to ensure or wait for all messages to be sent… that's quite annoying
ColdBlooder has joined #cinch
<dominikh> more importantly, I don't see the queue ever exiting its loop. surely that leaks when reconnecting to a server oO
<badeball> this is how I'm currently thinking: https://gist.github.com/badeball/0ff61f1677aa87b2e360
<dominikh> I'm also curious how the current MessageQueue implementation isn't burning CPU when there is nothing to send
<badeball> the private #wait method on MessageQueue does contain sleep
<dominikh> only for rate limiting purposes
<dominikh> if it doesn't have to limit, it doesn't sleep
<badeball> oh, you're right
<badeball> hmm
<dominikh> that whole thing is a weird mess :/
<badeball> btw, this is how we trap a HUP, save state (joined channels, etc.) and re-execute the application: https://github.com/badeball/itera-bot/blob/master/itera-bot.rb#L19-L24
<dominikh> fwiw, my own bot runs behind a ZNC, so it can be completely restarted; but that still has the exact same problem :D
<dominikh> also had no idea Ruby's exec could do that
<badeball> the fun stuff
<badeball> upon restarting, the application will for previously saved environment variables containing state and this tricks cinch to believe that it's in channels without having joined them
<badeball> s/will for/will look for/
<dominikh> ah
<badeball> somehow I'm beginning to think that using bouncer would be easier
<dominikh> you'd still have the same problem though. when terminating the process, you want to wait for all messages to be sent
<dominikh> imagine you send 10 messages, 5 get queued due to rate limiting, and you restart the process in the middle
<badeball> yes, true, we it would get rid of the ugly overriding
<badeball> s/we it/but it/
<dominikh> true. also, you could make use of the bouncer's buffering/backlog
<dominikh> instead of missing messages while the bot is restarting
<badeball> I don't have any experience using anything like znc (I just screen my irssi), does it introduce its own procotol or is it a transparent service for an irc client?
<dominikh> except for some extensions, ZNC just acts as a proxy. to the client (the bot) it looks like an IRC server, and to the real server it acts as a client
<dominikh> while you're connected, it will mostly just relay messages. when you're not connected, it can for example buffer up to N messages and replay them once you connect
<badeball> very neat
<dominikh> so Cinch would connect to ZNC would connect to the real server
<badeball> how does cinch know which channels znc is connected to?
<dominikh> ZNC sends JOIN messages to the client when it connects
<dominikh> and name lists etc
<dominikh> it's a smart proxy
<badeball> ah, okey
<dominikh> one special case is that ZNC would handle SASL, instead of Cinch
<onewheelskyward> I use that setup.
<onewheelskyward> It works really well.
<dominikh> ah, nice. I only use it with my other IRC library
<onewheelskyward> When I restart cinch, it does re-join the channels, from the bot to ZNC. ZNC manages the connection to the server.
<onewheelskyward> I don't really care if messages are lost.
<onewheelskyward> My next project is to daemonize cinch somehow.
<onewheelskyward> So I can capistrano restart it.
<dominikh> don't :/
<onewheelskyward> Bad idea?
<dominikh> daemonization as a whole is a bad idea
<dominikh> supervision is where it's at
<onewheelskyward> Is there a better idea to put it in a container?
<onewheelskyward> Ah, have a link?
<dominikh> I have no idea what exactly capistrano is though
<onewheelskyward> It's just a deploy tool.
<onewheelskyward> Blow the code out to the server, then fire off a restart task
<onewheelskyward> The latter is manual for me right now.
<dominikh> but the way one should run something is 1) in the foreground 2) managed by a supervisor, like daemontools/runit/upstart/systemd
<badeball> dominikh: +1
<onewheelskyward> Oh, we're saying the same thing. I had the terminology wrong.
<dominikh> ah, okay.
<dominikh> daemonization is the silly sysvinit model, with PID files and races and sad faces
<onewheelskyward> hahaha
<onewheelskyward> ༼ ºل͟º༼
<onewheelskyward> I just want unicorn for my cinch.
<onewheelskyward> Maybe if we make cinch extend rack...
* dominikh gets a gun
postmodern has joined #cinch
<onewheelskyward> lol
<onewheelskyward> You'd probably flinch if I told you I've implemented sinatra in one of my plugins.
<onewheelskyward> I have it responding to incoming sms.
<dominikh> I used sinatra in one of my Cinch bots
<dominikh> and hated it because it caught ^C...
<onewheelskyward> Oh, mine doesn't do that, thankfully.
<dominikh> wonder why mine does…
Azure has quit [Quit: My MBP went to sleep.]
<dominikh> truth be told, though, is that my current bot doesn't use Cinch
<onewheelskyward> I think this is the one I'm using https://github.com/Quintus/cinch-plugins/blob/master/plugins/http_server.rb
<onewheelskyward> What is it using?
<onewheelskyward> Built another whole framework? Go this time? :)
<dominikh> a minimalistic IRC library I wrote in Go
<onewheelskyward> LOL
<onewheelskyward> I had a feeling it'd be something intrinsically multithreaded.
<dominikh> well, more importantly, it's not frameworky. sort of
<onewheelskyward> Is it open source?
<dominikh> it's not public (yet). it's barely usable :)
<dominikh> I don't think I'll ever release it
<onewheelskyward> Oh you should. I'd love to check it out.
<dominikh> well, I don't intend to polish and finish it
<dominikh> which I'd have to do if I wanted to release it ;)
<onewheelskyward> Leaving more fun for the rest of us. Gotchya. :)
Azure has joined #cinch
<dominikh> good night.
<onewheelskyward> night!
<ColdBlooder> Hi. Is there a way to restart a cinch plugin when the bot is already running?
<leftylink> I use it and can attest to its general coolness
<leftylink> it's pretty rad
<ColdBlooder> Awesome, thx
<ColdBlooder> A little followup question. "Bot.plugin_restart (<plugin name>)" ?
<ColdBlooder> *reload
<ColdBlooder> nearly 1am over here an it shows lol
<leftylink> hmm, I think I need clarification on your question, because I see no such thing in either https://github.com/cinchrb/cinch/blob/master/lib/cinch/bot.rb or https://gist.github.com/dominikh/2179973
Azure has quit [Quit: Blue Sky Fish]
<ColdBlooder> Oh *facepalm*. nvm but one other thing, lol... What is when i reload a plugin? "mapping"?
<leftylink> ah, well if we see how it is used on line 15 of the gist... it is basically the filename of the file containing the plugin
<ColdBlooder> Oh so cinch/plugins/plugin.rb?
<ColdBlooder> (as example)
<ColdBlooder> is there an example how to use this? My brain apparently is out of order atm :-(
Azure has joined #cinch