When adding a duplicate value to a small replacable, Bucket will reply "$who, I had it that way!" and will not attempt to query the database to insert the dupe.

When adding a duplicate value for a large variable, when the value is not cached (at least that's when I've confirmed this), Bucket will simply say "Okay, $who" and then spew a DB Error regarding a duplicate entry.

It would be nice if you could stop bucket from accepting items without having to add three(?) seperate factoids

The flipside of this is that one rejection line would might not make sense for all the item-given forms

So what I propose is this:
First bucket checks "given item $item" or similar
then he checks "gives bucket $item" or "hands bucket $item" or "puts $item in bucket" depending on which of the three was used
Finally if either of them exist, he rejects with the factoid, otherwise he accepts the item like a good little bucket.

I haven't figured out yet where to look for this, so filing an issue in case anyone else has ideas.

Example case 1

[18:58:08] <&Kaede> Tales of Tents: Pokemon of the Amazing Ace
[18:58:22] <~dgw> Kaede: what was that
[18:58:22] <&Kaede> dgw: That was '!tales' (#2195): <reply> Tales of $Nouns: $Noun of the $Adjective $Noun;  vars used: { 'Noun' => [ 'Pokemon', 'Ace' ], 'Nouns' => [ 'Tents' ], 'Adjective' => [ 'Amazing' ]};.
[18:58:42] <&Kaede> dgw removed a value from $noun in dgw: pokemon
[18:58:53] <&Kaede> dgw added a value to $noun in dgw: Pokémon
[19:01:26] <+JAKQ> !fate
[19:01:26] <&Kaede> Fate/Read Pokémon
[19:01:34] <+JAKQ> !tales
[19:01:34] <&Kaede> Tales of Pokémons: Pokémon of the Strict Pokémon
[19:01:38] <~dgw> Uh
[19:01:47] <~dgw> Kaede: restart
[19:01:47] <&Kaede> Restarting at dgw's request
[19:01:47] <&Kaede> Okay, dgw, I'll be right back.
[19:03:28] <~dgw> !fate
[19:03:28] <&Kaede> Fate/Finance Pepsi

Example case 2

[19:07:34] <&Kaede> JAKQ removed a value from $noun in JAKQ: sata andagi
[19:07:49] <&Kaede> JAKQ added a value to $noun in JAKQ: saataa andagi
[19:08:06] <~dgw> Slyphoria's obsession with foods strikes again
[19:08:11] <~dgw> !fate
[19:08:12] <&Kaede> Fate/Furry Saataa Andagi
[19:08:39] <@JAKQ> !tales
[19:08:40] <&Kaede> Tales of Saataa Andagis: Saataa Andagi of the Ruined Saataa Andagi
[19:08:44] <&Kaede> Restarting at dgw's request
[19:08:52] JAKQ furrows eyebrows at that bug

A user experimenting with factoids in PM on my instance noted that $getitem only ever returns "bananas" in PM. @zigdon is this intended behavior, so inventory factoids don't work outside a channel, or should it be fixed?

Sat Apr 9 14:38:32 2011 - Creating band name database/query handles
Sat Apr 9 14:38:32 2011 - Executing band name word count (since its items)
Sat Apr 9 14:38:32 2011 - Finding union
Use of uninitialized value in numeric eq (==) at ./bucket.pl line 3514.
Use of uninitialized value in numeric eq (==) at ./bucket.pl line 3514.
Use of uninitialized value in numeric lt (<) at ./bucket.pl line 3518.
Use of uninitialized value in numeric lt (<) at ./bucket.pl line 3518.
Can't call method "fetchrow_hashref" on an undefined value at ./bucket.pl line 3522.

what could be causing this?
I'm not very good with perl...

I wrote in irc "since it's items".
That seemed to have triggered this, and made it crash.
I did not write "Bucket: since it's items".

Current behaviour:

05:10:23 @icekarma | Bucket, lookup #1
05:10:24 Bucket | 1 is its own reword
05:10:48 GreenWolf | bucket: what was that
05:10:49 Bucket | GreenWolf: That was 'good pun' (#1): is its own reword

Desired behaviour:
05:10:23 @icekarma | Bucket, lookup #1
05:10:24 Bucket | factoid #1: good pun its own reword

Would be nice to have a plugin that will allow ops to set RE triggers. General idea would be define a trigger, and the response would be either a string or a factoid.

Bucket: addre /^real programmers/ text: Real programmers cite http://xkcd.com/378/
Bucket: addre /\brandom\b/ lookup: something random
Bucket: listre
1. /^real programmers/ text: Real programmers cite http://xkcd.com/378/
2. /\brandom\b/ lookup: something random
Bucket: deletere 2

Probably allow listre to accept a filtering argument.

List of REs will have to be checked against every new line, might want to consider limiting RE complexity or number of trigger. (set re_max_number?)

If implemented properly, should be able to replace the metabutterfly plugin.

Clearly something to do with how Bucket strips off the first bit for use as $to in the tidbit. With #75 enabled on my instance, pinning this down was pretty easy.

What's less clear is the way ahead. For my particular case it would work simply to avoid stripping off the first part of the line if there's no space following the colon…but what of legitimate triggers of the form Word: More Stuff?

Basically, is it worth e.g. checking to see if the potential value of $to is in the channel before stripping it from the line start? Or have I crossed into truly esoteric territory that should be left alone?

As far as I can tell, from searching through the code and the documentation, Bucket doesn't support servers with passwords. The IRC library does, though, and I've hacked that function into my copy of bucket.pl.

I'm happy to submit a pull request for this, if it's something that could get merged, after I've had time to run my tweaked version for a while. Is there anything I should be aware of besides adding the Password element to the IRC connection data ($irc->yield)? Like maybe a default value besides the obvious "" (empty string)?

hi there!

The problem I have is as follows:

Sun Jan 6 12:42:26 2013 - Error loading plugin settings: Can't locate object method "settings" via package "Bucket::Plugin::topic" at ./bucket.pl line 3641.

This is the only error I can see it logging :|

The bot will connect to the control channel, but nothing else. If i say anything in the control channel, it sends it into a tailspin, and it generates a huge log file, viewable here:

http://weezel.co.uk/files/logs.txt

It seems to generate "delayed messages" which it seems to multiply so that each new line is longer than the last.

I've tried removing the topic plugin (as it could see it referenced in the error) but the bot still only joins the control channel, and will generate huge log files if triggered in any way

Here's what happens:

<Xunie> bucket, trigger <Reply> response
<bucket> Okay, Xunie.
<Xunie> trigger
<bucket> trigger Reply response

I remove it:

<Xunie> bucket, undo last

Set it again with <reply> instead:

<bucket> Okay, Xunie, deleted that 'trigger' is 'response'.
<Xunie> bucket, trigger <reply> response
<bucket> Okay, Xunie.
<Xunie> trigger
<bucket> response

I'd be happy to PR this, but first I'd like to know if the use of (\w+) intentionally does not match on messages like "Do you know Nowhere Man" or "Do you know Elvis?". Might have to change the check for who/what/how/etc. to do it if desired, but the current behavior doesn't make a whole lot of sense to me.

I propose that Bucket remove users who part, quit, or change nick from the list of possible values for $someone.

Thoughts?

As stated in the title, giving bucket 1000 digits of pi will cause bucket to crash.
The error given is
"Use of uninitialized value $string in pattern match (m//) at /usr/local/share/perl/5.10.1/POE/Filter/IRC/Compat.pm line 310."

19:15 < IceKarma> zigdon, if Joe says "puts his thing in Bucket", what's added to the inventory is "Joe's thing". if Joe says "puts their thing in Bucket", it instead adds "their thing"

Odd little thing with a denizen's quotesfile. "literal[*] nick quotes" resulted in a listing of "Alias to oldnick quotes" plus all factoids for oldnick quotes, and new quotes for [nick] were directed there - but asking Bucket for "Bucket: nick quotes" resulted in one of five factoids every time, and none of them were in the listing. It turned out that the aliased trigger still had some factoids of its own. The resolution:

< barometz> Bucket: delete nick quotes
< Bucket> Okay, barometz, 5 factoids deleted.
< barometz> Bucket: alias nick quotes => oldnick quotes
< Bucket> Okay, barometz.
< barometz> Bucket: nick quotes
< Bucket> [factoid from the new listing]

Right now I'm not sure whether this is an ongoing issue with alias (what is the expected behaviour for existing triggers?) or just some remnants of an old DB mixup. Don't have time for extensive testing at this point, might look into it later.

After mentioning #47 (on literal[*]) on IRC, a discussion started on Bucket's match/replace syntax. This is another example of things that are fairly obvious to many programmers but entirely weird to most people who aren't.

What

< barometz> Bucket: blorgh is foo
< Bucket> Okay, barometz.
< barometz> Bucket: blorgh is bar
< Bucket> Okay, barometz.
< barometz> Bucket: blorgh ~= /foo/
< Bucket> blorgh is foo
< barometz> Bucket: blorgh =~ /foo/
< Bucket> blorgh is foo
< barometz> Bucket: blorgh ~= s/foo/baz/
< Bucket> Okay, barometz, factoid updated.

The s/stuff/newstuff/ thing seems fairly ubiquitous across IRC (at least in my circles) to rectify what someone said, but on the whole people seem to have trouble remembering how any of this works. I'm not advocating to make Bucket "intuitive" or anything like that, but using keywords that are easier for people to remember might be helpful. Even candide, the C compiling bot over at freenode/##c, has more readable support for this sort of thing.

Alternatives

Any alternative will be more verbose and might be harder to parse and escape for. If we're going for plain English, Bucket: replace "foo" with "baz" in "blorgh" might do the trick.

I find that Bucket often learns band names that originally contained ', like contractions (it's, that's, you're, etc.). They make no sense, and look bad, unless I or another admin manually delete the band name and re-add it with the apostrophe.

Somewhere in Bucket's code, it'd be great to disable stripping that out for band names.

tail -f /path/to/bucketlog is basically useless, since it might take minutes or hours to update. And when it does update, it dumps out a ton of lines.

When I shut down my Bucket instance, it also throws away some log data that is never written out. (I do shut it down with service bucket stop on Ubuntu, so Bucket might not be given the chance to clean up before it exits.)

I'm looking into this, because I really want to be able to tail Bucket's log to find more info on another issue.

line 1623-1626, right after the "#Mathing!" section:

elsif ( $bag{addressed} ) {
            &error( $bag{chl}, $bag{who} );
            return;
        }

leaving the function (db_success, I believe). But later in the section, after the hardcoded "hum a few bars" response, ass hyphenation (clearly, none of which are meant to respond to bucket being addressed), is the "hands bucket $1" section. After that section is the problematic part, which responds to "bucket, take this $1" and "bucket, have a(n) $1".

Relevant lines (1668-1683):

elsif (
            $bag{orig} !~ /\?\s*$/
            and $bag{editable}
            and $bag{orig} =~ /^(?:
                               puts \s (\S.+) \s in \s (the \s)? $nick\b
                             | (?:gives|hands) \s $nick \s (\S.+)
                             | (?:gives|hands) \s (\S.+) \s to $nick\b
                            )/ix
            or (
                    $bag{addressed}
                and $bag{orig} =~ /^(?:
                                 take \s this \s (\S.+)
                               | have \s (an? \s \S.+)
                              )/x
            )
          )

I don't know perl very well but I can probably work on a PR over a few days or weeks if nobody else wants to work on it.

I'm not 100% sure, but I think this regressed in 6989681. Bucket has been giving responses like this lately:

 <Bucket> bucket am made of AWESOME

That's true, but he should be saying "I" and is not.

vehicle and room are unknown even though the wiki says they're available. if you say bucket: testfactoid foo $vehicle drives into $room

and then

: testfactoid

bucket: foo $vehicle drives into $room

After taking over issue #6 for a while, it was suggested to move this to a new issue. I've been attempting to get the "band names" thing working. I hadn't realized that loadlog.pl was involved before, and after being told how to feed it data, it doesn't seem to be working, even with the log snippet from the end of the file itself.

izzy@Veda2:~/xkcd-Bucket$ ./loadlog.pl < loadlogtest.txt
Use of uninitialized value $max in concatenation (.) or string at ./loadlog.pl line 27.
max timestamp:
Date = 2006-08-15
Use of uninitialized value $stats{"added"} in concatenation (.) or string at ./loadlog.pl line 111, <> line 42.
Use of uninitialized value in concatenation (.) or string at ./loadlog.pl line 111, <> line 42.
Use of uninitialized value in concatenation (.) or string at ./loadlog.pl line 111, <> line 42.

lines added, new words, pointers.

That's the output I get, with loadlogtest.txt containing the log snippet from loadlog.pl, everything between and including the "Log opened" and "Day changed" lines.

Today someone tried to quote the following line:

<iirelu> ladymondegreen: solution: enslave grandmothers

And Bucket only remembered "enslave grandmothers". I believe this is because before handing the %bag to the quotes plugin, Bucket strips out any addressee (at bucket.pl#L304), so the quotes plugin receives only "solution: enslave grandmothers" and dutifully strips out what it sees as a nick address.

Is this second stripping ever necessary, if Bucket already pulls out the nick? In a cursory glance it seems that the quotes plugin could just not strip any nicks, but I'm not familiar enough with the codebase to know that for sure. I may play with it later to see.

The form like $var$who or similar forms containing actual variables or different pseudo-variables will resolve incorrectly if the rightmost one is expanded first by the code into something with an alphanumeric start.
Building a hash of all substitutions and substituting at once might be in order to fix this.
(Discovered when adding "random webiste" factoids, id didn't quite work out gluing stuff together.)

Right now bucket will simply add "himself" or "herself" to the inventory. Along the lines of giving bucket "his/her thing", I would like to make this behave sensibly.

Currently planning to match something like (h(im|er)|the(ir|m))self.

A meme currently going around the fanbase of a certain anime franchise proved impossible to replicate faithfully in a Bucket response. Observe the following:

<dgw> Kaede: it's joke <reply> I T S   J O K E
<Kaede> dgw taught in #Kaede (#4886): 'it's joke', '<reply>', 'I T S J O K E'

The extra whitespace is part of the meme, but is removed before the tidbit is saved.

I think it's because of sub irc_on_public performing the following replacement before processing an incoming line:

    $msg =~ s/\s\s+/ /g;

Is there a downside to moving this substitution later in the chain of processing, so teaching operations can learn tidbits verbatim (using &decommify or similar to clean the fact part)? Or is it actually caused somewhere else?

<IceKarma> XMPPwocky, ??
<Bucket> XMPPwocky, ??'s puppies look like silverfish

If a message in the format $nick[:,] ?what are your pronouns\? (regex) is used, bucket should print $nick's gender/pronouns.

http://wiki.xkcd.com/wirc/index.php?title=Bucket&diff=12755&oldid=12741

"it's not clear the reason $possessive doesn't work though"

I poked at the code, turns out its because the config is setup as posessive not possessive

Essentially, verify that there are no alias relationships between the teaching nick and the fact nick in either direction.

Noted in logs from a couple weeks ago that a user managed to teach a factoid about himself by using his alternate nick. Specifically, the flow went like this (where 'altnick' => 'nick' is aliased in the database):

[Chat channel]
<nick> Bucket, nick is x
<Bucket> Please don't edit your own factoids, nick.
<nick> Bucket, altnick is x
<Bucket> Okay, nick.

[Log channel]
<Bucket> nick taught in #chat-channel (#4946): 'nick', 'is', 'x'

Using altnick allows nick to teach a factoid even though upon being saved altnick is redirected to nick and thus shouldn't be allowed.

I can already tell that this is probably going to require a new function and custom SQL to perform the lookup. Good excuse to beef up my practical Perl experience whenever I get motivated to work on this…

The random factoid after $a_few minutes is supposed to start a conversation, but since most and factoids are meant to be in-context gags, not out-of-context… facts, it usually results in either confusion, "Bucket: what was that?", or some combination of the two.

2014-04-08 07:03:37 @icekarma WassPord, >.>
2014-04-08 07:03:38 WassPord, >.> is jealous because he isn't the Messiah

... but ...

2014-04-08 07:03:59 WassPord, >.>
2014-04-08 07:04:00 laptop + WassPord = warm WassPord

While he is happy to act upon users' /me actions in channels, Bucket ignores these in queries. This makes life interesting, and a little confusing, when it comes to testing factoids in private.

This week I came across a channel that I couldn't tell Bucket to join a channel that wasn't handled properly:

<dgw> Kaede: join #nkc48.lounge
<Kaede> joining #nkc48 at dgw's request
<Kaede> dgw: joining #nkc48

I'm guessing it's because the join/part command regex doesn't allow for . in channel names: /^(join|part) (#[-\w]+)(?: (.*))?/i

This is because [-\w] expands to [-A-Za-z0-9_], which means anything that isn't in that set (or a hyphen) will end the match. (It also won't handle channels that start with &, for example, but maybe it would be too much trouble to handle the server's CHANTYPES response.)

Working on a better regex right now, possibly using \S instead of \w due to the fact that basically any non-whitespace character seems to be valid in channel names on a lot of IRCds… but comments and suggestions are welcome. I'm going to test for quite a while before I consider any solution PR-ready.

Probably trigger a refill if remaining value count is less than &config("var_limit"). Things like this wouldn't happen then.

Kaede: dgw: That was '!tales' (#2195): <reply> Tales of $Nouns: $Noun of the $Adjective
       $Noun;  vars used: { 'Noun' => [ '', '' ], 'Nouns' => [ 'Shines' ], 'Adjective' =>
       [ 'Poor' ]};.

Discussion in #53 brought up the possibility of moving most of Bucket's options into the database.

Other than the DB connection details, what (if anything) should be left out? From a security standpoint, I'd say the following additional options should be stored in bucket.yml only:

• bucketlog
• control_channel
• db_dsn
• db_password
• db_username
• logchannel
• logfile
• main_channel
• nick
• nickserv_msg
• nickserv_nick
• password
• plugin_dir
• port
• server
• server_pass
• ssl
• www_root

Many of these could live in the database if secured in such a way that only the bot's owner could change them, and nobody else could even see the values (that goes triple for passwords).

Anyone have thoughts on this? One of my goals is to eventually learn enough Perl to actually effect this change myself, but until then we have some time to discuss.

Eighty | bucket: forget everything daisy, daisy...
+Bucket | Eighty taught in #xkcd (#150334): 'forget everything', '', 'daisy daisy'

Bucket.pl, line 1432:
&error( $bag{chl}, $bag{who} ) if $bag{chl};
Probably should be:
&error( $bag{chl}, $bag{who} ) if $bag{chl} and $bag{addressed};
so that Bucket won't throw database errors in channels unless he's being addressed.

If someone says the same thing 5 times, even if it's not directed at Bucket and is not a valid factoid trigger, he attempts to volunteer a .txt dump and throws an error. Example:

xkcd:

 <Ariamis> <    rcombs > the mile-away-from-where-you-started club
 <Ariamis> <    rcombs > the mile-away-from-where-you-started club
 <Ariamis> <    rcombs > the mile-away-from-where-you-started club
 <Ariamis> <    rcombs > the mile-away-from-where-you-started club
 <Ariamis> <    rcombs > the mile-away-from-where-you-started club
 <Bucket> That is not a chair listing.

bucketlog:

 <Bucket> Volunteering a dump of '< rcombs > the mile-away-from-where-you-started club' for Ariamis in #xkcd
(the spam was accidental on Ariamis's part, for the record)

My personal preferred solution to this for Bucket not to send error messages to channel unless his nick was mentioned in the triggering line.

A recurring issue has been that the syntax to get literal dumps (i.e., to get Bucket to spit out a link to a literal foo.txt) is slightly arcane and hard to remember for most people. I suggest that a new keyword or keyphrase is chosen that can be used to retrieve all factoids for a given trigger.

Why

The current syntax is Bucket: literal[*] spork quotes. A variation I see very often is Bucket: literal [*] spork quotes. There are others as well that I don't immediately recall.

The reasoning behind the current syntax is - as far as I can tell - that it matches the literal-paging system:

< barometz> Bucket: literal spork quotes
< Bucket> spork quotes (#44171) <reply> <Spork> DS9 is about as good as TNG and way better than
                   TOS|(#44172) <reply> <Spork> Make [...] |752 more
< barometz> Bucket: literal[2] spork quotes
< Bucket> spork quotes (#44175) <reply> <Spork> Of course you can't get vim for Windows -- it already
                   has Word.|(#44176) <reply> <Spork> [...] |747 more

The literal paging system in turn is tricky to internalize for anyone who isn't a programmer, and nobody ever uses it, so most people have no clue why literal[*] looks like that.

Alternatives

I'd like to see a keyword for this function that's plain English. My preference goes to "dump out", although something using the word "literal" might be good as well. Other suggestions are of course welcome.

learn2 fails to insert the data, as it's missing the RE, mood and chance columns.

Also, I'm not sure where those columns are actually used. I can't see anywhere.

Hi, this is my first time using bucket, and i just installed it. But when i start it up this error appears around the time it loads the small replacebles

RESULT:
$VAR1 = undef;
Use of uninitialized value in numeric gt (>) at C:\Users\Jeff\Downloads\xkcd-Buc
ket-master\xkcd-Bucket-master\bucket.pl line 2741.

Here is a more detailed version of what was shown in the terminal
http://pastebin.com/m73vzmzE

It would be great to be able to get a quote from anyone at random, not just from a specific user.

Maybe implement as storing an additional alias to $nick quotes under a random quote factoid when saving new quotes. Would need a migration routine that looks for existing quotes factoids and aliases them IF random quote doesn't already exist in the DB.

Might also be desirable for new aliases to be saved only if random quote was created by the quotes plugin—but that could be hard to track.

Mostly just throwing implementation ideas out there without prototyping anything, so there's no proof of concept yet.

$verb works fine for me (default values plus a couple dozen of my own), but $verbs, $verbed, and $verbing all seem to be broken. Literally '$verbs' is output in the factoid. $nouns works as expected.

There is no way (currently) for the verb "am" to make it into that block, so the code inside this conditional is not reachable. I'm not sure if the regexes should be adjusted or that block should be removed.

Edited by @dgw 2018-10-10 to point to the correct line as it appeared when this issue was opened.

When earlier today I asked a certain bucket about everyone who was ignored to check for something, I got this back:

08:59:37 <Bucket> Long, alphabetic, list, of, nicks, going, from, a, to, t, âXC

That last bit is â and reverse-video XC. The list ended after a nickname that starts with T, so I imagine there was something missing.

Expected behaviour: split this across lines, like the detailed inventory already does.

Bucket silently truncates (or rather, lets the database engine truncate) values that don't fit in the default VARCHAR(32) bucket_values.value column. Not only that, but the full-length version is what's inserted into Bucket's cache and used until the next bot restart, when the truncated version from the database is loaded and used instead.

It would be better to let users know when they add a value if it's too long for the database.

If there's interest in adding this, I might try to teach myself enough Perl to write it. Advice would be helpful, though, like how to get the width of the column (cache it on startup?).