robotmay has quit [Read error: Connection reset by peer]
aytch has quit [Read error: Connection reset by peer]
opus has quit [Quit:]
aytch has joined #cinch
<Divinite>
dominikh: Here?
<dominikh>
Divinite: yea
<Divinite>
dominikh: Need a little bit of help making user authentication and "settings"
<dominikh>
heh
<Divinite>
Any recommendations?
<dominikh>
yes. more concrete questions :P
<Divinite>
How can I make cinch "recognise" a userv
<Divinite>
*?
<dominikh>
if on a network with Q (quakenet) or nickserv, you can use User#authname
<Divinite>
What do you mean?
<dominikh>
on those networks, a user will have an account, and log in, so you can use that to verify him.
<Divinite>
But how do I check they're verified?
<dominikh>
by looking at User#authname?
<Divinite>
How do I look at it?
<dominikh>
By calling the authname method on a User object?
<Divinite>
Thanks!
<Divinite>
Secondly, how can I store a user's settings?
<dominikh>
what settings
<Divinite>
For instance:
<Divinite>
Divinite has points: 4938
<dominikh>
save them to disk, load them from disk on bot start
opus has joined #cinch
<Divinite>
Yaml?
<dominikh>
for example
<Divinite>
Any other way apart from YAML?
<dominikh>
any other serialization, databases, whatever floats your boat
<Divinite>
I'd prefer just a static file
<dominikh>
then use yaml
<Divinite>
Thanks for the advice!
<aytch>
YAML, maybe CSV? CSV would probably be simpler
<Divinite>
aytch: In what way?
<aytch>
YAML was kind of hard for me to grasp at first
<Divinite>
aytch: Does CSV use an external gem?
<dominikh>
save yourself the trouble, don't use CSV
<Divinite>
dominikh: Alright, thanks
<aytch>
listen to that guy
<dominikh>
that's generally a good idea, yeah :P
opus has quit [Quit:]
v0n has joined #cinch
<v0n>
hi
<v0n>
does the bot #plugins.plugins method can accept an array of class names as strings?
<v0n>
like c.plugins.plugins = ["PluginFoo", "PluginBar"]
<dominikh>
no.
<dominikh>
c.plugins.load(plugins: ["Foo", "Bar"]) should work though
<dominikh>
(#load being a method of the Configuration class for loading/merging configuration from a hash)
<v0n>
ho ok, gonna test it
<aytch>
dominikh: do you think there would be any value in being able to pass a name to a thread?
<dominikh>
aytch: what?
<aytch>
Well, right now I'm trying to identify syllable strings with regex. I have to figure out which @event=:message pattern=#<Cinch::Pattern:0x007fbf9b8afb30 message is being triggered
<dominikh>
the pattern should give you an idea, shouldn't it? and you can add debug statements in your methods
<v0n>
dominikh: can this #load method "reloads" the plugins?
<dominikh>
no. load simply "loads" a hash into the configuration. the list of plugins only gets evaluated once, when the bot starts
<v0n>
btw I confirm #load works as expected with an array of strings :)
<dominikh>
:)
<v0n>
ho yes, I read somewhere that cinch doesn't actually support "hot reload" of plugins
<v0n>
I will have to kill and restart the bot, right?
<dominikh>
well, it does. just not in the core
<dominikh>
you can very well write reloading code, and I did
<dominikh>
it just expects a very certain file system layout
<dominikh>
remove line 5, take note of line 16, note the issue at line 52 and you're set
<dominikh>
hot reloading of plugins. Cinchy here has reloaded plenty of plugins without a restart
<aytch>
that would be a pretty awesome addition to the cinch core
<dominikh>
I disagree. there's more than one way to reload code, there are limitations, and one of Cinch's philosophy is to not expect any file system layout. that there expects one
<dominikh>
it's really not something I want to maintain "for everybody"
<aytch>
I can understand that philosophy.
<aytch>
as a new programmer, I spend a lot of time testing my failing plugins, so for myself personally, it's a thing I'd like to see - but I do understand your reasoning.
<dominikh>
well, you can use that code there. it's a plugin
<dominikh>
it just won't be in core.
<aytch>
And I most certainly shall :D
<v0n>
dominikh: interesting! I find I'm gonna use this plugin manager with only the load feature
<v0n>
dominikh: btw, how are plugins loaded at startup?
<dominikh>
v0n: essentially, we take c.plugins.plugins, instantiate the classes and register the patterns
<v0n>
dominikh: but you have to initialize kind of a "load" command, right?
<dominikh>
including Cinch::Plugin pulls in an initialize class method, as well as a bunch of register code
<v0n>
dominikh: so you meant that I can do a "load" in the initialize() method of the PluginManager?
<dominikh>
v0n: what exactly are you trying to do?
<v0n>
dominikh: we want to have plugins in a plugins/ directory, and implement a "!reload" command, that actually reload every plugins under that folder
fridim has joined #cinch
<v0n>
we alors want the bot to load the plugins on startup as well, for sure