| 05:17.57 | *** join/#debian-bots streuner (n=streuner@p54A5F7F3.dip.t-dialin.net) |
| 05:18.13 | *** part/#debian-bots streuner (n=streuner@p54A5F7F3.dip.t-dialin.net) |
| 08:36.21 | *** join/#debian-bots markybob (n=markybob@unaffiliated/markybob) |
| 08:36.43 | *** part/#debian-bots markybob (n=markybob@unaffiliated/markybob) |
| 08:36.50 | *** join/#debian-bots markybob (n=markybob@unaffiliated/markybob) |
| 08:50.37 | *** part/#debian-bots markybob (n=markybob@unaffiliated/markybob) |
| 11:05.17 | *** join/#debian-bots dpkg (n=dpkg@unaffiliated/dpkg) |
| 16:22.14 | *** join/#debian-bots streuner (n=streuner@p54A5FF5F.dip.t-dialin.net) |
| 18:30.34 | *** join/#debian-bots ravenbird (i=ravenbir@unaffiliated/simonrvn/bot/ravenbird) |
| 18:39.13 | *** join/#debian-bots simonrvn (i=simon@unaffiliated/simonrvn) |
| 18:45.37 | *** join/#debian-bots ravenbird (i=ravenbir@unaffiliated/simonrvn/bot/ravenbird) |
| 18:55.06 | *** join/#debian-bots troubled (n=troubled@pdpc/supporter/sustaining/troubled) |
| 18:56.31 | troubled | !+help crypt |
| 18:56.32 | dpkg | It's good that you thought about encryption. I can do it for you. |
| 18:56.32 | b0r9 | It's good that you thought about encryption. I can do it for you. |
| 18:56.32 | b0r9 | <PROTECTED> |
| 18:56.32 | b0r9 | Example: crypt changeme 69 |
| 18:56.33 | dpkg | <PROTECTED> |
| 18:56.33 | dpkg | Example: crypt 69 changeme |
| 18:56.33 | dpkg | Example: crypt $1$abcde changeme |
| 18:57.57 | *** join/#debian-bots streuner (n=streuner@p54A5FF5F.dip.t-dialin.net) |
| 19:10.53 | *** join/#debian-bots ravenbird (i=ravenbir@unaffiliated/simonrvn/bot/ravenbird) |
| 20:07.43 | *** part/#debian-bots streuner (n=streuner@p54A5FF5F.dip.t-dialin.net) |
| 21:55.53 | troubled | dondelelcaro: personally, I would think it better to just have one master flood setting for bytes:seconds and lines:seconds to govern it all rather than the current .... |
| 21:56.24 | troubled | !chanset _default sendPrivateLinesLimit |
| 21:56.25 | b0r9 | troubled: No idea |
| 21:56.34 | troubled | or whatever it is, sec |
| 21:57.13 | troubled | !chanset _default sendPublicLimitBytes |
| 21:57.13 | b0r9 | troubled: Wish i knew |
| 21:57.33 | troubled | well, i cant query it, by there are 3 of them, notice, public and private |
| 21:57.51 | dondelelcaro | troubled: oh, the current flood limit code is total crap |
| 21:58.08 | troubled | one for bytes and one for lines. thinking it would be better to use a syntax similar to floodMessages => 10:30 |
| 21:58.14 | dondelelcaro | troubled: what really needs to be done is someone needs to rewrite the bot to shift from Net::IRC to POE::Component::IRC |
| 21:58.19 | dondelelcaro | which handles all of that for you |
| 21:58.28 | troubled | ya, im looking into that right now actually |
| 21:58.54 | troubled | the guys in #perl basically told me Net::IRC is go the way of the dinosaurs |
| 21:58.54 | dondelelcaro | I had started on it a few years ago, but I just don't have time to deal with it |
| 21:59.06 | dondelelcaro | yeah, Net::IRC is a PoS |
| 21:59.20 | troubled | well, I can see the main hooks, the question is, how much stuff is hidden elsewhere |
| 22:00.19 | troubled | would be a shame to waste whats already done with blootbot. if the Net::IRC could be replaced only I think it would be better. replace the pieces gradually rather than all at once |
| 22:00.29 | troubled | god knows the db's could use a rewrite |
| 22:01.12 | troubled | whats worse, nobody seems to know what version assufield pulling in for etch |
| 22:05.16 | dondelelcaro | that's actually Neil McGovern who did that |
| 22:05.49 | troubled | the etch release? |
| 22:06.03 | dondelelcaro | !+maint blootbot stable |
| 22:06.05 | dpkg | blootbot: Neil McGovern <neilm@debian.org> |
| 22:06.05 | b0r9 | Updating debian files... please wait. |
| 22:06.08 | b0r9 | blootbot: Neil McGovern <neilm@debian.org> |
| 22:06.22 | troubled | b0r9: owner |
| 22:06.23 | b0r9 | dondelelcaro owns me |
| 22:06.32 | troubled | heh, your bot? |
| 22:07.16 | troubled | i assume we don't know what svn rev he pulled it in from do we? |
| 22:09.20 | troubled | i know a few people have grabbed the cvs source which is way out of date, off of sourceforge. Need a more recent release pasted, but who am I to make such calls. And riker is rarely available to ask |
| 22:11.39 | dondelelcaro | troubled: no, it's someone who has imported dpkg's database, apparently. |
| 22:12.10 | troubled | i figured as much. and apparently they didnt care to avoid duplicate addressCharacter's either |
| 22:13.07 | dondelelcaro | well, at least cydork set the whois info correctly |
| 22:15.41 | troubled | probably just in here to allow sharing factoids cause I dont see it in #debian |
| 22:36.39 | *** join/#debian-bots cydork (n=vihang@unaffiliated/cydork) |
| 22:37.37 | cydork | !stats |
| 22:37.37 | b0r9 | Since Mon Sep 17 09:09:18 2007, there have been 4 modifications and 3 questions and 5 dunnos and 0 morons and 3 commands. I have been awake for 5d 15h 28m 19s this session, and currently reference 37612 factoids. I'm using about 16776 kB of memory. |
| 22:37.37 | dpkg | Since Sat Sep 22 11:05:03 2007, there have been 1 modification, 103 questions, 0 dunnos, 0 morons and 80 commands. I have been awake for 11h 32m 34s this session, and currently reference 37612 factoids. I'm using about 15700 kB of memory. With 0 active forks. Process time user/system 35.07/2.23 child 0/0.01 |
| 22:37.59 | troubled | tad of a conflict ;) |
| 22:38.07 | cydork | ~stats |
| 22:38.08 | apt | Since Fri Sep 21 17:51:09 2007, there have been 24 modifications, 190 questions, 0 dunnos, 0 morons and 133 commands. I have been awake for 1d 4h 46m 59s this session, and currently reference 113637 factoids. I'm using about 19524 kB of memory. With 0 active forks. Process time user/system 2113.86/209.37 child 0/0 |
| 22:38.18 | cydork | yeah i know :P |
| 22:38.19 | troubled | ok, well maybe not ~ |
| 22:38.25 | cydork | %stats |
| 22:38.37 | troubled | :) |
| 22:39.08 | cydork | well we got one or ravenbird is working |
| 22:39.11 | cydork | ravenbird: stats |
| 22:39.12 | ravenbird | Since Sat Sep 22 19:10:02 2007, there have been 0 modifications, 0 questions, 0 dunnos, 0 morons and 0 commands. I have been awake for 3h 29m 9s this session, and currently reference 20847 factoids. I'm using about 26336 kB of memory. With 0 active forks. Process time user/system 39.17/1.95 child 0.01/0.07 |
| 22:41.58 | *** join/#debian-bots b0r9 (n=blootbot@gridtutorial15.ba.infn.it) |
| 22:42.02 | cydork | ,stats |
| 22:42.03 | b0r9 | Since Sun Sep 23 00:41:44 2007, there have been 0 modifications and 0 questions and 0 dunnos and 0 morons and 0 commands. I have been awake for 18s this session, and currently reference 37612 factoids. I'm using about 17352 kB of memory. |
| 22:42.07 | troubled | well, i know its @ in another channel |
| 22:42.13 | troubled | @stats |
| 22:42.14 | ravenbird | Since Sat Sep 22 19:10:02 2007, there have been 0 modifications, 0 questions, 0 dunnos, 0 morons and 0 commands. I have been awake for 3h 32m 12s this session, and currently reference 20847 factoids. I'm using about 26336 kB of memory. With 0 active forks. Process time user/system 39.52/1.98 child 0.01/0.07 |
| 22:42.16 | cydork | ahh |
| 22:42.28 | troubled | its per channel, so you never know |
| 22:42.35 | troubled | well, can be at least |
| 22:42.46 | cydork | nope its a blootbot so it can't be. |
| 22:42.53 | troubled | sure it can |
| 22:43.01 | troubled | i do it with my factbot |
| 22:43.15 | troubled | perhaps you have an old blootbot |
| 22:43.25 | cydork | which one are you using? |
| 22:43.27 | troubled | mine is from svn, not etch |
| 22:44.04 | cydork | aah then it's possible. coz it has lot of new features. |
| 22:44.30 | cydork | it even has support for pgsql. |
| 22:44.40 | *** join/#debian-bots FactBot (n=factbot@pdpc/supporter/sustaining/troubled) |
| 22:44.40 | FactBot | Okay, I'm here. (courtesy of troubled) |
| 22:45.39 | troubled | *chanset #debian-bots addressCharacter |
| 22:45.40 | FactBot | addressCharacter for #debian-bots is '*' |
| 22:45.46 | troubled | *chanset #botpark addressCharacter |
| 22:45.46 | FactBot | addressCharacter for #botpark is '!' |
| 22:46.37 | troubled | well, pgsql support was my doing. seems to work, but I havent stress tested it too much. seemed to work without crash and just fine though |
| 22:46.56 | troubled | if anything its a tad faster with the index's that mysql is missing |
| 22:47.27 | troubled | what copy are you using anyways? etch copy? |
| 22:47.32 | cydork | yeah |
| 22:47.54 | cydork | with some changes :P |
| 22:47.59 | troubled | nobody seems to know what rev that is. Im leaning towards an old cvs copy though |
| 22:49.50 | cydork | hmm i should try the new cvs source |
| 22:51.08 | cydork | i still think sqlite support should be a good idea. |
| 22:51.23 | troubled | it does seem to be a popular option |
| 22:51.28 | troubled | and its svn now, not cvs |
| 22:51.31 | cydork | i know. :( |
| 22:51.44 | cydork | oh ok |
| 22:51.55 | troubled | the db schema is still simple enough that sqlite is not a problem at least |
| 22:52.31 | troubled | stored procs are the problem, but I honestly cant see that ever making it into the tables. isnt needed really |
| 22:53.06 | dondelelcaro | there are some places where procedures would be useful, but since its been using mysql since before, it's really not a problem. |
| 22:54.11 | dondelelcaro | whatever is done to the db though, it really should be as backend agnostic as possible |
| 22:54.14 | troubled | if anything, the one change I would have liked to see would be a secondary lookup table to store all the repeatative data like user hostmasks. and maybe view's that select where not like '%#DEL#' |
| 22:54.43 | *** join/#debian-bots cydork (n=vihang@unaffiliated/cydork) |
| 22:54.55 | dondelelcaro | what'd be better is just to do versioning on the tables or similar |
| 22:55.20 | troubled | ya, thats the problem. although the mangos (world of warcraft server) I was hanging around with a while back had an interesting method of schema updates. the had a dir in svn with the sql needed to bring the schema up to date, and carried the db along. plug they updated the full-schema.sql each update as well for new installs |
| 22:56.27 | dondelelcaro | heh. I actually have code that automates that sort of thing for postgresql (for simple schema changes) |
| 22:56.29 | troubled | its the method i use with my db logger actually. works ok so far. but the updates can have issues. personally, I think the bot should just do the right thing each time it starts |
| 22:57.42 | troubled | i suppose a _registry table could work. store settings and schema versions in it. would at least give the bot something to compare against. then you can start loading the bot code with update sub's to incrementally bring it to current |
| 22:58.01 | dondelelcaro | yeah, I'm not so fond of those sort of hacks |
| 22:58.14 | dondelelcaro | 'cause you get into the chicken and egg problem when you have to update the registry table |
| 22:58.43 | troubled | ive seen your schema from the dump though. its in serious need of cleanup. one case that comes to mind is that CMD:'s became cmd:'s |
| 22:59.07 | troubled | that and you have many factoids with > 1k enteries that dont even fully display with the current code |
| 22:59.26 | troubled | when is the last time youve ran a #DEL# cleanup? |
| 22:59.38 | dondelelcaro | never bothered |
| 23:00.10 | troubled | do you think that cleanup code would be handy? not like you dont have regular db dumps saved for restores |
| 23:00.16 | dondelelcaro | the problem is that the schema is encoding things in the factoid value that probably shouldn't be (and the issues you've brought up aren't with the schema) |
| 23:00.22 | dondelelcaro | shouldn't matter, actually |
| 23:02.07 | troubled | any chance you can do a select avg(length(factoid_key)) from factoids; on your db? |
| 23:03.06 | troubled | actually, thats not the field I wanted :/ requested_by, created_by and locked_by should be lookups |
| 23:03.38 | troubled | troubled!n=troubled@pdpc/supporter/sustaining/troubled should only appear onces in the db, and an int4 should be used instead to reference it and a join performed |
| 23:04.07 | troubled | 3 fields * avg length * # tuples vs. 12bytes * # tuples in savings |
| 23:05.03 | troubled | problem is that it would be tricky sql to perform the update on existing db's automatically. surely it could be checked for an coded, but would just be easier to get the user to run the update manually once |
| 23:07.00 | troubled | im sure the seen stats could benifit from an int2 or int1 on the channel field as well. #debian is 7 bytes * number of seen rows vs. 1byte * num rows |
| 23:07.14 | troubled | basically I could probably redo the db to 1/8th the size |
| 23:07.19 | troubled | if not more |
| 23:07.44 | dondelelcaro | the space saving really isn't that big of a deal though |
| 23:07.51 | dondelelcaro | the main issue is lookup performance |
| 23:07.58 | dondelelcaro | (and that's really a function of indexes) |
| 23:09.09 | troubled | well, i did add the index's to pgsql schema. the mysql schema already has one on the factoid pkey. cant really see much else to index unless you use some of the factstat features often though |
| 23:09.30 | dondelelcaro | yeah, that's pretty much it |
| 23:09.31 | troubled | maybe on factoid_value for !listvalues |
| 23:10.45 | troubled | also, it would have been nice if the timestamps in the db were stored as such rather than the current format. make looking at the db in sql easier |
| 23:10.58 | troubled | just not sure about sqlite and timestamp fields |
| 23:11.52 | dondelelcaro | sqlite should have support for timestamp+timezone |
| 23:11.58 | dondelelcaro | can't imagine it not |
| 23:12.30 | troubled | do you think thats a worthwhile change though? really dpkg is the primary use of blootbot atm |
| 23:12.42 | troubled | so it all comes down to your db really |
| 23:13.27 | dondelelcaro | not sure; I've actually been wanting to switch it to using postgresql for a long time, but haven't had the chance |
| 23:14.20 | troubled | well, the support is in the trunk copy and should work 100%. my test bot was on your db converted over. although i cleaned it up a bit with the #DEL#'s |
| 23:14.46 | dondelelcaro | ok. I should do a merge back then; just haven't really had a chance to look at it |
| 23:14.51 | troubled | forget what I used to convert it though. I think i just did a CVS dump and sed'd it to the proper format and imported |
| 23:15.23 | troubled | well, my branch had been stable, and its basically a recent trunk plus a few tiny changes awaiting approval |
| 23:15.56 | dondelelcaro | ah |
| 23:16.07 | dondelelcaro | actually, I think I can probably approve changesets |
| 23:16.19 | dondelelcaro | but I've really not been paying enough attention to the codebase resently |
| 23:16.41 | troubled | heh, dont feel bad, I havent done anything to svn in like a year til recently |
| 23:17.18 | troubled | i think my branch is from around r1340'ish. theres about 10 or 20 changes to various modules it seems since |
| 23:17.48 | troubled | mostly though I only added the +s flag to allow a usermask to bypass +silent (new feature by tim in trunk) |
| 23:18.20 | troubled | it works, just not 100% sure if its honouring a valid hosts field from the userdb, or just going by nick only |
| 23:18.44 | dondelelcaro | hrm... I'm so out of date that I don't think I even have the right subversion hostname anymore |
| 23:18.51 | troubled | heh |
| 23:19.05 | troubled | http://blootbot.svn.sourceforge.net/svnroot/blootbot/ |
| 23:19.07 | dondelelcaro | ah yes... it's blootbot.svn now |
| 23:20.16 | dondelelcaro | scary. It looks like I last committed almost exactly a year ago |
| 23:20.20 | troubled | i have a failrly accurate pgsql readme in trunk for pgsql though. basically i think i dont have the setup.pl updated yet, but you just needto precreate the db and user iirc. it should auto create the tables from the schema automatically just fine |
| 23:20.30 | troubled | heh, anniversary :) |
| 23:20.44 | troubled | theres also a +sed bug your missing a patch for too then |
| 23:21.12 | troubled | s/:/:::::::::::::/g would excess flood, but you never used that in debian channel anyways so meh |
| 23:22.02 | troubled | think i just chop'd it down to some fixed value for now until i figured out the proper sub to get the conf value for the max. but thats really from during conect to be accurate, which we dont store per net |
| 23:25.03 | troubled | r1323 seems to be the last commit i had to trunk, from there to r1335 was everything new since few months ago on my branch. looking at the log theres only the +s flag, a chanServCheck and a edit for command hooks (that can be scrapped) that need to go to trunk |
| 23:28.08 | troubled | another issue i still havent really got an answer out of tim for is the #blootbot channel. It seems like the proper official name, and its referenced in the original readme iirc. but he doesnt seem to want to budge on making it #botpark instead *shrug* |
| 23:29.31 | troubled | i have the reg on #blootbot in the meantime, and it just forwards to #botpark for now though until we can all settle it |
| 23:32.07 | troubled | pop up a pgsql bot if you can with a blank db and ill run a few basic tests on it before you import the db in. worse case, toss me a url for the current db and ill get it converted for import for ya |
| 23:34.25 | troubled | also, for pgsql, you just drop a .sql into thr setup/<dbtype>/ dir now and the bot will auto create the tables missing for you. I tested that fairly well, cept on sqlite, thus I keep the old schema files for that instead of rewriting them like I did for pgsql |
| 23:39.34 | troubled | hmm, looking at the max fields on the hostname fields, the max should be around 94. iirc, its approx: <16>!<12>@<63>, so 93 by my calc's based on freenode's maximums. iirc your db was still using older (smaller) sized fields which cause me an import issue when i tried it directly |
| 23:40.16 | troubled | actually, ident is 8+2 so 10, so make that about 91 (say 92 for roundness :) |
| 23:58.34 | dondelelcaro | probably shouldn't even be limited |
| 23:58.45 | dondelelcaro | just a varchar255 |