<dominikh>
according to that line, he did keep his host
<qb>
the vhost is going to stick on forever it seems
<dominikh>
as in, the server didn't change it
<dominikh>
so that's not my problem :D
<qb>
I think the user would have to reconnect to have it removed
<qb>
yeah it's not
<dominikh>
yeah give me five minutes…
<dominikh>
qb: git clone, build from the fix/unsync_auth branch and see if that fixes it and works properly :)
<qb>
looks like it fixed it
<dominikh>
cool. now we'll fait and see if it breaks something else :P
<dominikh>
wait, too
<qb>
but like I said before it was working fine for a while so I can't be 100% sure it was something with cinch
<qb>
but I'll report anything I notice
<dominikh>
qb: I'm pretty sure you just never tested it. or you did have an unconditional User#refresh in your check, which would work around the issue
<dominikh>
either case it's a bug in Cinch that we fixed :)
leftylink has quit [Ping timeout: 272 seconds]
leftylink has joined #cinch
waxjar has quit [Ping timeout: 240 seconds]
DeepBlue has joined #cinch
DeepBlue is now known as lalala_oops
kludge` has quit [Ping timeout: 264 seconds]
kludge` has joined #cinch
mpapis has joined #cinch
<mpapis>
good morning!
<mpapis>
does someone remember the online list with cinch plugins / applications?
lalala_oops has quit [Read error: Connection reset by peer]
DeepBlue has joined #cinch
kludge` has quit [Remote host closed the connection]
leftylink has quit [Ping timeout: 272 seconds]
leftylink has joined #cinch
kludge` has joined #cinch
postmodern has quit [Quit: Leaving]
<dominikh>
mpapis: search rubygems for "cinch-". the website doesn't exist anymore
<mpapis>
ah ok, maybe a wiki page then?
DeepBlue has quit [Quit: Konversation terminated!]
<dominikh>
there's a wiki with bots that use Cinch. and if you want to maintain a page of plugins, go ahead ;)
DeepBlue has joined #cinch
DeepBlue has quit [Quit: Konversation terminated!]
xeviox|afk is now known as xeviox
DeepBlue has joined #cinch
DeepBlue is now known as lalala_oops
waxjar has joined #cinch
lalala_oops has quit [Ping timeout: 245 seconds]
mpapis has quit [Ping timeout: 264 seconds]
mpapis has joined #cinch
<mpapis>
dominikh, so can I use exception method directly in plugin or need to get logger first?
<dominikh>
it's Helpers#exception, Helpers is included in plugins, so yeah, you can use exception directly
<mpapis>
thanks
<dominikh>
note that it's for logging actual Exception objects
<mpapis>
yep I catched it to print message to user and was missing the exception in logs
<Cinchy>
[URL] Why is it bad style to `rescue Exception => e` in Ruby? - Stack Overflow
<dominikh>
and apart from that the obvious race condition on lines 30/31 ;)
<mpapis>
fixed Exception, as for the condition - I do not expect that many deploys ;) had situation travis reports two times the same build, wanted to avoid duplicate builds
<dominikh>
yeah, but if it reports them two times at the same time, and you have a thread switch after the check and before setting the status, you'll end up running it twice
<mpapis>
i tusually has offset of a 30 seconds
<dominikh>
okay, fair enough then
<dominikh>
if that still races you have other problems
<mpapis>
yes fixing them ;) pushed two versions already, the biggest problem was missing LANG from Upstart
<dominikh>
upstart, heh
<dominikh>
anyway, nice plugin
<mpapis>
yes will need to create list of my plugins, have already few
<awkisopen>
is there a way to access the bot's default command prefix during plugin initialization time? I imagine it's at @bot.configuration.something but @bot is nil during that time
<dominikh>
awkisopen: depends what you're actually trying to do
<awkisopen>
I've written a command parser that runs at initalization time (like match) and I would like to assign it the prefix/suffix the actual commands will be using to make regexes more accurate
<awkisopen>
if that makes sense. if not I'll try to rephrase
<dominikh>
I'm not really much smarter now, no :) obviously there's no way to access the bot configuration in class methods (like match), because a plugin can be used in many different bot instances. match and prefix/suffix support lambdas, to generate regexps at runtime, based on the message/bot
<awkisopen>
ahhh see I was under the impression that each Matcher got assigned the default prefix/suffix values for the bot somewhere during initialization and I was just blind as fuck
<dominikh>
well, it happens when we instantiate the actual bot. at that point, Matchers get turned into actual handlers
<dominikh>
for that specific plugin instance
<awkisopen>
so to change my question, can a plugin get the default prefix/suffix values during runtime?
<awkisopen>
I'm guessing by going into @bot's configuration
<dominikh>
making peep show references is a bit dangerous, not many people get them.
<awkisopen>
I'm actually mildly excited about this parser, I'm using ActiveModel for validations and error messages
<awkisopen>
it's a lot easier than coding in every little way things could be parsed wrong, because the bot is for a channel that loves to break everything in every way possible
<dominikh>
I have absolutely no idea what you could be doing that involves parsing, ActiveModel and plugin prefixes
<awkisopen>
this is almost certainly where I find out I'm being an idiot, but it works like this
<awkisopen>
instead of using #match in a plugin, I have a different method, #register_command, which takes a splatted hash of the name of each parameter the command will have, along with a few other options, such as a regex to match that parameter with /(/^#/ for channel names, for instance)
<awkisopen>
at the end of that it takes a code block that uses ActiveModel's validation methods, so you can cpeciy what the expected input for any of those parameters is
<awkisopen>
if any of those parameters fail validation, the first error message from ActiveModel::Errors is printed, and the command is not run
<awkisopen>
if validation and parsing succeed, the values for each parameter are collected into a hash and unsplatted into a given method in the plugin, because I'm using ruby 2.0
<dominikh>
okay, sounds sensible, to a degree. what I wonder is why it needs access to the plugin prefix. won't that just use #match under the hood?
<awkisopen>
it does use #match under the hood, but the full message is passed to the parser, including the prefix
<dominikh>
ah, right. fair enough
<awkisopen>
but most importantly once I get the prefix/suffix properly stripped off, no one will whine about unhelpful error messages again
<awkisopen>
anyway thanks for the help, hopefully that wasn't too dull
<dominikh>
nah. interesting idea, actually
<awkisopen>
I could throw you the WIP of the Command class in a gist, it's still messy but it has the general idea