00:12 <ahh> is there a link to the api page

00:12 <dominikh> http://rubydoc.info/gems/cinch/index

00:14 <ahh> thanks i'll take a look through it. i'm still getting some errors trying to keep it running and sending couple messages

00:14 <dominikh> what errors?

00:16 <ahh> well it just stops after the t.join. i think i need to understand this a bit more :) most of the examples are event driven didn't see much in being able to make method calls after bot.start

00:16 <ahh> just ruby newbie :)

00:17 <dominikh> that's the point of t.join. that's Thread#join. it waits for the thread to finish

00:17 <ahh> and bot.start ?

00:17 <ahh> initializes and starts the method

00:17 <dominikh> tells the bot to connect, which runs its read/write loop

00:17 <dominikh> which blocks. hence its own thread around it

00:17 <ahh> ah

00:17 <ahh> i see

00:18 <ahh> so how would you not block

00:18 <dominikh> you sound confused. Bot#start will always block. if you want to do stuff after the Bot#start, like in my example, you put it in a thread

00:22 <ahh> i must be yeah

00:24 <ahh> maybe not familiar with threads enough

00:50 <ahh> guess i'll keep trying it. I ahve more rails/fob work to do for now. thanks for the help

00:50 <dominikh> no problem, and good luck

03:57 <placer14> Hiyas. curious if anyone has any suggestions on a good pattern to get external signals triggering cinch actions?

03:58 <placer14> (signals from outside of IRC, but still on the same system as the one running the bot)

03:58 <dominikh> placer14: depends how external. different process?

03:58 <placer14> yes, outside process

03:58 <dominikh> a fifo or a unix socket is usually a decent choice

03:58 <placer14> but filesystem, pipes, sockets are all reasonable solutions... pipe is reasonable as I only need one-way comm

03:59 <dominikh> I suppose you're more interested in the triggering bit than the transmitting data bit then I guess

03:59 <placer14> Yeah...

03:59 <placer14> I'm thinking about a thread listening to a file pointer.

03:59 <dominikh> given a Bot instance called bot, you can do bot.handlers.dispatch(...) to dispatch any sort of event you wish

03:59 <placer14> And have it pipe that to cinch.

03:59 <placer14> What if I don't have the bot instance handy in the process?

04:00 <dominikh> surely the process that is reading from the fifo has the bot handy.

04:01 <placer14> I suppose the bootstrap script for the bot would also bootstrap listening to the fifo...and would have access to the bot instance... it just seemed heavy

04:01 <placer14> Wondered if there was a more direct route that I was overlooking.

04:01 <dominikh> I'm not sure what you're asking for. entity A writes to the fifo, entity B reads from the fifo. what use is it then, if entity C is the bot? how would C know anything?

04:02 <dominikh> bot = Cinch::Bot.new {...}; Thread { for each line on fifo { bot.handlers.dispatch(...) }; bot.start

04:02 <dominikh> well, one more } before the ;

04:03 <placer14> yeah... perhaps I'm overthinking it.

04:03 <placer14> Thanks :)

04:04 <placer14> PS: I've been playing with cinch for 10 minutes and it's stupid-easy/fun to use.

04:04 <placer14> So thanks! :)

04:04 <dominikh> glad to hear that :)

04:05 <placer14> Bonus points for making yourself available on IRC.

04:05 <dominikh> well, it is an IRC framework after all :P

04:06 <dominikh> you're lucky I screwed up my sleep though. timezone wise it's 6am

06:03 <dominikh> then don't mistake my sleep for lack of dedication. good night.

14:51 <Rylee> Is there any quick way to send a /kill from inch?