dominikh changed the topic of #cinch to: The IRC Framework | Latest version: Cinch 2.2.5
djbkd has quit [Remote host closed the connection]
djbkd has joined #cinch
djbkd has quit [Remote host closed the connection]
djbkd has joined #cinch
djbkd has quit [Remote host closed the connection]
_djbkd has joined #cinch
ChasedSpade has quit [Remote host closed the connection]
ChasedSpade has joined #cinch
ChasedSpade has quit [Quit: No reason specified.]
ChasedSpade has joined #cinch
_whitelogger has joined #cinch
djbkd has quit [Ping timeout: 264 seconds]
postmodern has quit [Quit: Leaving]
CaveJohnson is now known as Zackio
sarkyniin has joined #cinch
irsol has quit [Remote host closed the connection]
nekosune has joined #cinch
<nekosune> Hello all, sorry for the stupid question, is there anyway to make sure that a plugin only runs AFTER other plugins?
irsol has joined #cinch
britneywright has joined #cinch
sarkyniin has quit [Remote host closed the connection]
<apeiros> nekosune: don't worry, it's not a stupid question.
<nekosune> as I have a plugin that runs on any incoming message, just to keep track of whensomeone last spoke for a !lastseen command, but it turns out that causes acollision with other plugin s trying to use the databse
<apeiros> use Bot#synchronize
<apeiros> it won't ensure order, but it will ensure that there's no collision
<nekosune> thankyou! :)
<nekosune> the order dosnt matter, as long as they are not trying to hit the db at the same time
<nekosune> I have moved to mysql to continue dev, but as you can imagine, I dont want to need a mysql server for an IRC bot
<apeiros> I use a pg server for my irc bot :)
<nekosune> nice :)
Azure has quit [Quit: My MBP went to sleep.]
<apeiros> is there a list of all values Message#command can return?
<dominikh> the IRC spec :)
<apeiros> dominikh: the irc spec doesn't say anything about integers, symbols, strings :-p
<apeiros> ok, the docs actually say "String"
<dominikh> :)
<apeiros> so uppercase command name? like "KICK"?
<dominikh> yes.
<apeiros> ok
<apeiros> thx :)
<dominikh> why do you need to look at Message#command?
<apeiros> logging channels
<dominikh> ok
<apeiros> dominikh: I hope cinch does not sanitize Message#raw, right?
<dominikh> it's called raw.
djbkd has joined #cinch
<apeiros> dominikh: yeah, but I also expected raw to be binary, yet it is utf-8 ;-)
<apeiros> and I prefer not to make assumptions where I don't have to
<dominikh> http://www.rubydoc.info/gems/cinch/file/docs/encodings.md applies to everything you will deal with, including Message#raw
djbkd has quit [Remote host closed the connection]
djbkd has joined #cinch
djbkd has quit [Ping timeout: 256 seconds]
djbkd has joined #cinch
djbkd has quit [Ping timeout: 252 seconds]
djbkd has joined #cinch
sarkyniin has joined #cinch
nekosune has quit [Quit: Leaving.]
apeiros is now known as apeiros|not
apeiros|not is now known as apeiros
<apeiros> hm, when I do User("bots_nick"), I get an incomplete user object, no authname, no host. is that a known bug? I don't see it on the issue list.
<dominikh> what do you mean by "incomplete"? all of these attributes will be filled in when you use them for the first time
<apeiros> no, they remain empty for me
<apeiros> 19:51 apeiros: !debug User("ruboto")
<apeiros> 19:51 ruboto: apeiros# => #<Bot nick="ruboto">
<apeiros> even an explicit refresh doesn't fill them
<dominikh> what's that !debug supposed to show me?
<dominikh> where is that accessing or printing e.g. #host ?
<apeiros> oh, weird, I thought the inspect showed the other attributes when filled
<dominikh> no.
<apeiros> ok, so seems it just had a long delay. probably slow freenode.
<dominikh> at least not for the bot, no idea if it does for users
<apeiros> ok, I guess I have to guard against Cinch::Exceptions::SyncedAttributeNotAvailable
<dominikh> that fires when the server didn't respond to our request for some time (a minute or so, I forgot)
<apeiros> 30s
<apeiros> interesting. it happens reproducibly after op-ing
<apeiros> and only when the bot ops itself. when I perform the same, no issue.
<dominikh> show code and full logs
<apeiros> mhm, give me a second to make a minimal example.
<apeiros> (well, more like 5min)
postmodern has joined #cinch
<apeiros> dominikh: ok, got it prepared: https://gist.github.com/apeiros/edbdfe6510bcfa74283e
<apeiros> relevant log lines start from 233
<apeiros> oy
<apeiros> got to fix the example
<dominikh> hm, I thought I fixed that bug
<apeiros> ok, so it actually happens without op-ing too
<dominikh> yeah okay, I see the issue
<dominikh> sort of, anyway
<apeiros> should I try to pin down when it happens? or do you have an idea where to look?
<dominikh> I know what's wrong, pretty much
<dominikh> sigh, I really ought to rewrite those bits…
<apeiros> I know that feeling
<dominikh> fwiw, you probably do not want catchall, that catches everything, including e.g. the WHOIS replies
<apeiros> I do ponder logging all messages I get
<dominikh> anyway, the bug is with how we treat users and the bot separately. back then I decided that whenever you dealt with the bot, you should get the Bot instance, not a User instance with that nick
<apeiros> after all, space is nowadays not really an issue
<dominikh> alas, in some places, I "forgot" that, so some operate on the Bot, and some on a User with the same nick
<dominikh> which means the attribute gets synced for the wrong object, or alternatively you operate on the wrong object
<dominikh> I should've never made that decision in the first place, but now we're stuck with that
<apeiros> mhm
<dominikh> so I guess I got to fix the bug
<apeiros> iirc I used a multiton pattern in butler
<apeiros> where you would never get a new user object as long as that user was "in sight" of the bot
<dominikh> yes, we use that, too.
<apeiros> and the bot simply never went out of its own sight :)
<dominikh> well, except for the "in sight" bits, which is why explicit User#refresh is needed
<apeiros> (that did mean a potential bug when your own ip address would change, but not sure how irc would react to that anyway…)
<dominikh> however, the issue is that Bot and User are two different types, and ideally there should never be a User for the bot itself
<dominikh> that's the bug
<dominikh> well, ideally ideally there should be, but that's something for Cinch 3 :)
<dominikh> maybe Cinch 3 will also have less race conditions…
* apeiros wants more time
<apeiros> would love to revive butler
<dominikh> I'm sick of IRC ;)
<apeiros> ok. lets use the time instead to implement a new distributed text protocol based chat! :)
<apeiros> can't be that hard. go & ruby version.
<dominikh> have fun ;)
<apeiros> =(
<dominikh> man, try to fix a bug, find more bugs…
<dominikh> if I still liked ruby or IRC, I'd rewrite Cinch from scratch…
<apeiros> oh, that you no longer like ruby is unexpected
<dominikh> try your luck with http://sprunge.us/CePH
<apeiros> any advice on how to apply it?
<apeiros> I assume using the patch command?
<dominikh> that's how it's usually done, yes ;)
<apeiros> never used that command :-/
* apeiros is man'ing up
<dominikh> … I can push a branch
<apeiros> na, let me figure this. it's high time :D
<dominikh> (how can a developer not have used patch in >20 years?)
<apeiros> by using svn/git
<apeiros> I never had the need to
<apeiros> ok, I *think* it worked (the patching, that is)
<apeiros> trying to run it…
<apeiros> looks like the problem is gone
<apeiros> let me try it on the real bot
<apeiros> ok, seems to do the trick
<dominikh> ok, cool
<apeiros> btw., any advice on how to properly wrap https://gist.github.com/apeiros/edbdfe6510bcfa74283e#file-cinch_bug-rb-L16 in a block which waits for the MODE +o?
<dominikh> yes: Wait for Cinch 3...
<apeiros> can't wait that long
<dominikh> I can only suggest callback-based solutions, nothing that blocks. well, unless you implement the blocking yourself
<apeiros> callback is fine. I can pass the block on.
<dominikh> but then that won't block, and with_op will immediately return, unless you somehow wait for the callback to fire.
<apeiros> my issue is with how to register/unregister for the MODE properly
<apeiros> ah
<dominikh> you can execute Bot#on at runtime, and there's some API to remove handlers again, too
<apeiros> well, ok, it gets even uglier than I thought then.
<dominikh> yeah. the lack of a "wait for that message" API annoys me greatly, too
* apeiros bites his tongue
<dominikh> but hey, there's a "next" branch now. ~2 more years and thre might be Cinch 3
<apeiros> I think I'll sacrifice a goat and hope the gods give me more time to work on projects…
<dominikh> it's somewhat straightforward to write that APi yourself, though
<apeiros> I'd rather revive butler
<dominikh> waste of time, but sure
<apeiros> the reason I'm using cinch is because I didn't want to spend time on the infrastructure
<apeiros> well, I'll do a simple but dirty implementation.
<apeiros> the `on` blocks, are they instance_exec'ed on the bot?
<dominikh> in an instance of Callback
<apeiros> ok, which has a bot method.
<apeiros> is there a proper way to initialize additional state in the bot?
<dominikh> really you should be writing plugins.
<apeiros> probably
<dominikh> apeiros: http://sprunge.us/HTFP
<dominikh> minus the debug output…
<apeiros> yeah, that looks quite similar to what I was going to do
<apeiros> yours is a bit cleaner, though
nekosune has joined #cinch
<dominikh> probably should unregister first, then push to the queue
nekosune has quit [Changing host]
nekosune has joined #cinch
<apeiros> I've added it as an instance method on Cinch::Bot
<apeiros> where is the mapping between :message and "PRIVMSG" listed?
<apeiros> thanks
<apeiros> ah I remember why I wanted block-form. otherwise you get a race condition.
<dominikh> by all means. I showed you the primitive, whcih you can reuse in a block form ;)
<apeiros> yes, working on it
<apeiros> will gist when done
<apeiros> actually I'm just testing right now whether it works :)
<apeiros> ok, seems to work. cleaning up and pasting after :)
<apeiros> interface is ugly, but whatever.
<apeiros> (the optional arguments - you'll see)
<dominikh> jesus
<apeiros> he knows you?
<dominikh> he fears me
<apeiros> something wrong with the code? :)
<dominikh> except for the horrible interface, the optional arguments and the lambda? naah, it's fine :P
<dominikh> also, why aren't you waiting for the deop to take effect? ;)
<apeiros> yeah, ruby still doesn't accept 2 blocks on a method :(
<dominikh> (also what's with all those freeze?
<apeiros> ruby 2.2 goodness. single string allocation.
<dominikh> "we can't optimize that, so let's make users' code really really ugly"
<dominikh> sure.freeze makes.freeze it.freeze very.freeze readable.freeze
<apeiros> well, mutable strings are indeed hard to optimize
<apeiros> but I agree that they could have made better choices earlier on
<apeiros> with GCed symbols and single string allocations it might have been possible to unify those
<apeiros> i.e., make :foo an immutable string and no longer have a separate symbol class
<dominikh> or have immutable strings in general :P
<apeiros> +literal, I assume?
<apeiros> because "foo".freeze is an immutable string :)
<apeiros> or you mean make all strings immutable?
<dominikh> I mean, don't have mutable strings.
<apeiros> ah, I see
<apeiros> naw, I like my mutable strings
<dominikh> if you want to mutate it, explicitly require a conversion to an array of runes, or something
<apeiros> runes?
<dominikh> you way more often have immutable strings than mutable strings
<dominikh> unicode code points
<dominikh> runes
<dominikh> characters
<dominikh> whatever tickles your fancy :P
<apeiros> would need bytes, since a single codepoint can have different byte representations
<dominikh> string indexing etc operates on characters, which is why I did not suggest bytes
<dominikh> bytes would contradict with most of the encoding-related logic in Ruby
<apeiros> bytes is precisely what ruby uses right now for strings
<apeiros> and yes, that's the reason why string indexing in ruby is O(n) for VB encodings
<dominikh> all the string operations are aware of encodings and characters, which is why I suggested converting to arrays of characters for mutable functions.
<dominikh> if strings were just arrays of bytes, then yes, I would've suggested bytes
<apeiros> you can still operate on it on a byte level
<apeiros> which is sometimes necessary
<dominikh> that is besides the point
<apeiros> also you can't convert a string with invalid content
<dominikh> stop arguing over a stupid detail, I don't care if you make it an array of bytes, runes, or unicorns :) it's the exact same concept wrt mutable vs immutable
<apeiros> fine. I want an array of unicorns.
<apeiros> and yes, I agree with your main point, that mutable strings are far less often needed than immutable strings
<dominikh> heck, even most of the bang methods on string don't mutate, they allocate a new one and replace the old one
<dominikh> unless that changed.
<apeiros> and I also agree that if you'd design a language, you could easily use the nice syntax for immutable strings and the less nice syntax, or even only methods, for mutable ones
djbkd has quit [Remote host closed the connection]
<apeiros> dominikh: thanks a lot for all your help!
<dominikh> no problem
nekosune has quit [Read error: Connection reset by peer]
Azure has joined #cinch
djbkd has joined #cinch
britneywright has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
sarkyniin has quit [Remote host closed the connection]