| 00:10.25 | *** join/#asterisk-dev qdk (n=qdk@0x573d8dd1.bynqu2.dynamic.dsl.tele.dk) |
| 00:18.09 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 00:18.09 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 00:32.57 | *** join/#asterisk-dev Flare_123 (n=flare@189.101.252.221) |
| 01:01.11 | *** join/#asterisk-dev DarkRift (n=dark@65.92.249.176) |
| 01:09.28 | *** join/#asterisk-dev Octothorpe (n=Octothor@pdpc/supporter/professional/octothorpe) |
| 01:13.09 | *** join/#asterisk-dev friendly12345 (n=friendly@ppp118-208-145-44.lns10.mel4.internode.on.net) |
| 01:34.39 | tzanger | sruffell: pingaroo |
| 01:38.04 | sruffell | hello |
| 01:38.17 | sruffell | or should I say pongerroo |
| 01:40.05 | tzanger | heh |
| 01:40.11 | tzanger | you guys don't know about the pokearoo |
| 01:40.28 | mvanbaak | time to git some sleep |
| 01:40.28 | sruffell | hmm..I don't know if I like where this is going. |
| 01:40.32 | mvanbaak | Mon Mar 9 02:40:23 CET 2009 |
| 01:40.49 | mvanbaak | 6:00 is wakeup time |
| 01:41.05 | sruffell | yikes...'git stash' tonight and 'git stash apply' tomorrow. |
| 01:41.11 | tzanger | haha no it's not bad |
| 01:41.15 | tzanger | http://en.wikipedia.org/wiki/Polka_Dot_Door |
| 01:41.39 | sruffell | tzanger: even worse. |
| 01:41.50 | mvanbaak | latero all |
| 01:41.50 | tzanger | :-) |
| 01:54.49 | *** join/#asterisk-dev denon (i=denon@synapse.subneural.net) |
| 01:55.57 | *** join/#asterisk-dev ZX81 (n=matt@202.49.106.158) |
| 01:56.43 | ZX81 | hey all, anyone know if there is a bug open discussing file descriptor leaks? We're getting too many open files on a system with about 5 concurrent calls - 3 crashes in last week |
| 02:02.26 | file | that question is silly, such an issue would be in Mantis which you can search ^_^ |
| 02:07.51 | Corydon76-dig | nominates file for silly of the year |
| 02:08.17 | tzanger | he was silly last year, he can't always win! |
| 02:08.26 | file | sure can |
| 02:08.49 | Corydon76-dig | seanbright might be in the running this year, though |
| 02:11.13 | file | Gregor Samsa awoke one morning to discover that he had been transformed into a giant cockroach. |
| 02:13.18 | ZX81 | file: yeah |
| 02:13.32 | ZX81 | looks like the voicemail issue |
| 02:13.40 | ZX81 | but that is titled imap |
| 02:13.44 | ZX81 | and we don't use imap |
| 02:13.46 | ZX81 | but |
| 02:14.00 | ZX81 | lsof -p ASTERISKPID shows voicemail files remaining open |
| 02:14.23 | ZX81 | Fix by tilgman was "Fix up potential crashes, by reducing the sharing between interactive and non-interactive threads." |
| 02:14.24 | Corydon76-dig | Which voicemail files? |
| 02:14.34 | ZX81 | asterisk 1169 root 39r REG 9,0 4389 9536389 /var/lib/asterisk/sounds/vm-undelete.gsm |
| 02:14.35 | ZX81 | asterisk 1169 root 40r REG 9,0 3894 9536353 /var/lib/asterisk/sounds/vm-prev.gsm |
| 02:14.35 | ZX81 | asterisk 1169 root 41r REG 9,0 1551 9536331 /var/lib/asterisk/sounds/vm-messages.gsm |
| 02:14.35 | ZX81 | asterisk 1169 root 65r REG 9,0 11385 9536349 /var/lib/asterisk/sounds/vm-opts.gsm |
| 02:14.35 | ZX81 | asterisk 1169 root 73r REG 9,0 726 9535980 /var/lib/asterisk/sounds/beep.gsm |
| 02:14.35 | ZX81 | asterisk 1169 root 86r REG 9,0 1353 9536050 /var/lib/asterisk/sounds/digits/0.gsm |
| 02:14.37 | ZX81 | asterisk 1169 root 87r REG 9,0 1254 9536046 /var/lib/asterisk/sounds/digits/9.gsm |
| 02:14.39 | ZX81 | asterisk 1169 root 88r REG 9,0 1254 9536046 /var/lib/asterisk/sounds/digits/9.gsm |
| 02:14.41 | ZX81 | asterisk 1169 root 95r REG 9,0 1254 9536046 /var/lib/asterisk/sounds/digits/9.gsm |
| 02:14.49 | ZX81 | just crashed recently |
| 02:14.52 | ZX81 | so restarted |
| 02:14.59 | Corydon76-dig | What version are you using? |
| 02:15.13 | ZX81 | 1.4 r168546 |
| 02:16.01 | ZX81 | System uptime: 1 hour, 2 minutes, 57 seconds |
| 02:17.24 | ZX81 | yep, another just got added to list |
| 02:18.08 | ZX81 | for the moment will do a nightly restart with increased ulimit |
| 02:20.52 | Corydon76-dig | ZX81: please update to current SVN. Something got fixed within the last week on that |
| 02:21.04 | ZX81 | ok cool will have a squiz |
| 02:21.06 | ZX81 | ty |
| 02:22.23 | Corydon76-dig | Ooo, time flies. It was actually 4 weeks, 4 days ago |
| 02:22.32 | Corydon76-dig | revision 173354 |
| 02:22.47 | Corydon76-dig | http://svn.digium.com/view/asterisk?view=revision&revision=173354 |
| 02:24.30 | ZX81 | :D |
| 02:24.36 | ZX81 | awesome - cheers man |
| 03:07.32 | *** join/#asterisk-dev denon (i=denon@synapse.subneural.net) |
| 03:18.34 | *** join/#asterisk-dev denon (i=denon@synapse.subneural.net) |
| 03:29.50 | *** join/#asterisk-dev denon (i=denon@synapse.subneural.net) |
| 03:35.17 | *** join/#asterisk-dev Mw3 (n=mw3@ip59934bd1.rubicom.hu) |
| 03:43.43 | *** join/#asterisk-dev CunningPike (n=arodgers@S01060014bf81366b.vc.shawcable.net) |
| 04:45.32 | *** join/#asterisk-dev denon (i=denon@synapse.subneural.net) |
| 04:59.43 | *** join/#asterisk-dev denon (i=denon@synapse.subneural.net) |
| 05:42.03 | *** join/#asterisk-dev denon (i=denon@synapse.subneural.net) |
| 05:57.22 | *** join/#asterisk-dev Octothorpe (n=Octothor@pdpc/supporter/professional/octothorpe) |
| 06:13.26 | *** join/#asterisk-dev Octothorpe (n=Octothor@pdpc/supporter/professional/octothorpe) |
| 06:14.24 | *** join/#asterisk-dev denon (i=denon@synapse.subneural.net) |
| 06:28.41 | *** join/#asterisk-dev denon (i=denon@synapse.subneural.net) |
| 06:42.54 | *** join/#asterisk-dev denon (i=denon@synapse.subneural.net) |
| 06:49.17 | *** join/#asterisk-dev fiddur (i=fiddur@c042.rit.se) |
| 06:56.12 | *** join/#asterisk-dev denon (i=denon@synapse.subneural.net) |
| 07:03.25 | *** join/#asterisk-dev bobsaccamano (n=ymax@203.126.136.142) |
| 07:03.34 | bobsaccamano | are config queries entertained here? |
| 07:03.56 | tzanger | not unless they are displaying a bug in the configuration parser |
| 07:04.33 | tzanger | and generally speaking, if you have found such a thing, you wouldn't be asking if it was alright to ask here. :-) |
| 07:14.47 | bobsaccamano | hmm..the other sip channels are completely passive.. |
| 07:31.31 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@local.xorcom.com) |
| 07:31.31 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 07:33.19 | *** join/#asterisk-dev schmooze_tony (n=schmooze@rrcs-67-52-212-6.west.biz.rr.com) |
| 07:44.22 | *** join/#asterisk-dev mosty (n=mosty@213-66-224-163-no22.tbcn.telia.com) |
| 08:34.20 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@local.xorcom.com) |
| 08:34.20 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 08:36.14 | *** join/#asterisk-dev tamiel (n=tamiel@213.30.183.226) |
| 08:51.46 | *** join/#asterisk-dev Pazzo (n=ugelt@reserved-225136.rol.raiffeisen.net) |
| 09:02.27 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@local.xorcom.com) |
| 09:02.27 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 09:14.57 | *** join/#asterisk-dev denon (i=denon@synapse.subneural.net) |
| 09:25.38 | *** part/#asterisk-dev frawd (n=francois@153.pool85-49-230.dynamic.orange.es) |
| 10:13.35 | *** join/#asterisk-dev mbranca (n=matteo@93-62-230-243.ip24.fastwebnet.it) |
| 10:36.44 | *** join/#asterisk-dev qdk (n=qdk@81.7.168.130) |
| 11:05.33 | festr_ | russellb: hi, are you? |
| 11:06.59 | festr_ | russellb: two weeks ago I was talking about CPU usage of asterisk. I've buggy htop tool. I'm testing 240 calls and there is no signle thread which is over 2-3% |
| 11:07.13 | festr_ | s/I've/I had/ |
| 11:08.13 | *** join/#asterisk-dev DarkRift (n=dark@bas1-sthubert21-1096590422.dsl.bell.ca) |
| 11:12.15 | *** join/#asterisk-dev eliel (n=eliels@200.61.172.61) |
| 11:12.19 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 11:59.58 | *** join/#asterisk-dev juanjoc (n=juanjoc@200.69.219.113) |
| 12:19.09 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 12:19.09 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:26.25 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:43.45 | *** join/#asterisk-dev Mr_BOnD_007 (i=Mr_BOnD_@119.160.199.6) |
| 12:46.29 | *** join/#asterisk-dev shazaum (n=shazaum@unaffiliated/shazaum) |
| 12:47.28 | *** join/#asterisk-dev jandark (n=milad@unaffiliated/slackark) |
| 12:49.59 | jandark | hi dudes, Free software has a politic borders ? |
| 12:51.17 | russellb | I have no idea what you are asking |
| 12:52.29 | jandark | it's so so nice my license agreement in bug not accept because I am from Iran ! |
| 12:52.45 | jandark | in bugs.digium.com |
| 12:53.04 | russellb | what did the email you received say? |
| 12:53.29 | jandark | http://pastebin.com/m24f26dc1 |
| 12:53.45 | fiddur | :P |
| 12:53.55 | jandark | what ? |
| 12:54.28 | fiddur | That's quite horrific, even though I can understand a legal department's unwillingness to deal with it... |
| 12:55.12 | russellb | I was certainly not aware of that situation. We have a legal department that is in charge of such things. I'm sorry. :-( |
| 12:57.53 | jandark | you mean if I just lie and change my country everything is ok ?! |
| 12:58.14 | russellb | No, lying would not be acceptable. |
| 13:00.49 | jandark | russellb, ok give me a solution ! I do some localization for Farsi language, I should give code to a person out off iran and he send the code |
| 13:00.52 | jandark | ? |
| 13:01.11 | russellb | I'll have to talk to the legal people, I have no solution for you right now |
| 13:10.42 | *** join/#asterisk-dev behdad (n=behdad@CPE001217b19226-CM0012c9c84bc4.cpe.net.cable.rogers.com) |
| 13:10.42 | kpfleming | we'll look into it |
| 13:12.25 | behdad | russellb: can I /msg you? |
| 13:12.48 | russellb | if it's something that can't be discussed in public, sure |
| 13:53.12 | shazaum | is away: Trabalhando - Working... |
| 14:01.01 | *** join/#asterisk-dev putnopvut (n=putnopvu@asterisk/master-of-queues/mmichelson) |
| 14:01.01 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:01.05 | *** join/#asterisk-dev davevg (n=davevg__@74.94.3.214) |
| 14:05.26 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:05.26 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:16.56 | shazaum | is away: Trabalhando - Working... |
| 14:17.12 | shazaum | is back (gone 00:00:00) |
| 14:17.50 | russellb | shazaum: can you take off the messages when you go away/come back? |
| 14:18.32 | putnopvut | I learn something new every day. I just learned that you can reload your configs by sending SIGHUP to Asterisk. I wonder where that's documented. |
| 14:18.50 | russellb | I didn't know that either |
| 14:18.57 | shazaum | russellb, yep |
| 14:19.16 | tzafrir_laptop | putnopvut, now what happens when you run a non-daemonized asterisk in a terminal and you kill the terminal? |
| 14:19.17 | russellb | shazaum: thank you ... sorry to be a pain, but it makes IRC clients show that something was said, when there wasn't |
| 14:19.37 | putnopvut | tzafrir_laptop: I haven't tried that. |
| 14:19.43 | russellb | that's a weird feature ... |
| 14:20.53 | shazaum | russellb, mmm, and I was really working |
| 14:21.14 | tzafrir_laptop | SIGHUP normally reloads configuration |
| 14:21.33 | tzafrir_laptop | (for a daemon) |
| 14:24.53 | russellb | ah |
| 14:28.47 | mvanbaak | yeah, that's pretty common indeed |
| 14:31.03 | putnopvut | I'm glad I bring stuff like that up in here. Now I know why that isn't specifically documented anywhere. That's just a normal feature for daemons. |
| 14:31.41 | file | .clear |
| 14:31.56 | file | I seem to be off today... |
| 14:32.01 | putnopvut | turns file on |
| 14:32.08 | putnopvut | and then immediately regrets that wording |
| 14:32.25 | file | putnopvut: O.O |
| 14:32.31 | Marquis42 | :O |
| 14:33.03 | file | putnopvut: I had no idea you felt that way! |
| 14:33.14 | russellb | I would expect that on a Friday, but Monday morning? |
| 14:33.38 | putnopvut | I guess you could call that sort of a "Friday hangover" |
| 14:34.58 | *** join/#asterisk-dev schmooze (n=schmooze@h69-129-142-83.mdsnwi.tisp.static.tds.net) |
| 14:35.28 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 14:35.28 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 14:39.14 | *** join/#asterisk-dev schmooze (n=schmooze@h69-129-142-83.mdsnwi.tisp.static.tds.net) |
| 14:40.45 | seanbright | if that is a canned response, the legal department should fix the spelling of "any" |
| 14:43.31 | seanbright | and good morning |
| 14:44.46 | mvanbaak | good afternoon |
| 14:45.08 | putnopvut | seanbright: what are you referring to? |
| 14:45.41 | seanbright | the response jandark got about his license |
| 14:45.48 | seanbright | it has "amy" instead of "any" in it |
| 14:45.53 | putnopvut | sighs |
| 14:46.08 | putnopvut | hopefully that was just a one-time typo. |
| 14:46.19 | seanbright | right |
| 14:46.27 | seanbright | which is why i prefaced with: "if that is a canned response" |
| 14:46.30 | seanbright | keep up, man. |
| 14:46.34 | putnopvut | yeah |
| 14:47.15 | seanbright | how was skiing? |
| 14:47.21 | seanbright | wreck yourself? |
| 14:47.38 | putnopvut | I lived! |
| 14:47.43 | putnopvut | And had a great time too |
| 14:47.45 | seanbright | thank jeebus |
| 14:47.48 | seanbright | cool |
| 14:48.18 | seanbright | we were all working hard while you were gone |
| 14:48.32 | jandark | seanbright, fix the spelling of "any" and what ? :D |
| 14:48.42 | jandark | you mean for solving my problem ? |
| 14:48.59 | seanbright | jandark: no, it won't solve your problem. i just noticed that it was misspelled. |
| 14:49.12 | jandark | ohum |
| 14:49.48 | jandark | :( |
| 14:50.10 | seanbright | jandark: there is an easy solution. move to another country :) |
| 14:50.14 | seanbright | is kidding |
| 14:50.37 | jandark | seanbright, long ago mozilla had an issue that the US export regulations forbade is from exporting the code to Iran. Nowadays the US has practicalyl no limitations if the software is free software |
| 14:50.49 | jandark | I think should be update :P |
| 14:51.03 | seanbright | jandark: it's more complicated than that, unfortunately. |
| 14:51.11 | seanbright | it will get looked into. |
| 14:54.30 | russellb | serious responses to the summer of code thread would be appreciated to help ensure that it doesn't get derailed by one bad apple with a case of the Mondays. |
| 14:54.33 | russellb | ;-) |
| 14:54.46 | jandark | tzafrir_laptop, saw some situation like mine and guide me, anyway thanks |
| 14:55.50 | tzafrir_laptop | you're the guy who wrote about the Iranian localization code on the asterisk-dev list? |
| 14:56.44 | jandark | tzafrir_laptop, yup :) |
| 15:04.50 | eliel | russellb: +1 for the google SOC, i would like to be the student :) |
| 15:05.59 | russellb | eliel: sure, be sure to apply! |
| 15:06.23 | eliel | ok, thanks! |
| 15:09.59 | *** join/#asterisk-dev elguero (n=elguero@ns1.nashuacs.com) |
| 15:17.02 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 15:20.47 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 15:20.47 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 15:21.20 | *** part/#asterisk-dev oej (n=olle@ns.webway.se) |
| 15:21.39 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:21.39 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:32.24 | tzanger | hmm |
| 15:33.10 | tzanger | is there a way to retrieve the span number for a span in a multispan card in a system? |
| 15:33.22 | tzanger | i.e. two TE405 cards would be 8 spans total |
| 15:34.02 | tzanger | but is there a way to find out from a dahdi_chan structure which span in the multispan card this channel belongs to? |
| 15:34.13 | kpfleming | not that i know of |
| 15:35.25 | tzanger | dahdi_chan has span, that would point to a dahdi_span but dahdi_span has spanno which owuld be the system-wide span number |
| 15:35.45 | tzanger | bah, callbacks are a bitch :-( |
| 15:36.38 | kpfleming | right... there's just no place in dahdi right now where that information is needed, so it's not there |
| 15:36.56 | kpfleming | i guess it's just assumed that any driver will be able to take its own chan structure and figure out which span on the card it is part of |
| 15:37.33 | tzanger | yeah... I'm using pvt to point to a the driver's internal structure, but that's for the driver's internal structure, not the span within the card's internal structure |
| 15:37.38 | tzanger | I will likely have to refactor that a little |
| 15:39.26 | tzanger | maybe make the channel pvt point to what I want, because I can likely use container_of() to get to the driver-wide struct |
| 15:39.39 | kpfleming | yep, that seems like a good plan |
| 15:39.40 | tzafrir_laptop | yeah. dahdi needs a "hardware device" |
| 15:42.18 | sruffell | I would probably get rid of the pvt members, since the channel array in dahdi is now an array of pointers. Makes using the container_of macro possible for getting device specific information associated with a span or channel. |
| 15:42.29 | *** join/#asterisk-dev djbelieny (n=djbelien@72-48-61-165.dyn.grandenetworks.net) |
| 15:47.43 | *** part/#asterisk-dev djbelieny (n=djbelien@72-48-61-165.dyn.grandenetworks.net) |
| 15:50.22 | sruffell | tzanger: If you have multiple spans on a card, then to use the container_of macro to get the driver wide data, you could need to create another data structure to hold a pointer to the driver wide data structure. Otherwise how would you know which element of the driver wide structure you are to "container_of" on? In that case, you might as well just make pvt point to that new data structure you make. |
| 15:50.46 | tzanger | yeah I'm trying to figure this out as we speak |
| 15:51.12 | tzanger | basically chan->pvt is being initialized to wc->mods[i].bri |
| 15:51.31 | tzanger | I'm going to have to add a "cardno" variable to that bri structure I guess |
| 15:51.47 | tzanger | right now I'm just trying to get it to work, then I will work on making it pretty again :-) |
| 15:53.58 | tzanger | ah, I already ahd that in my struct, nice. :-) |
| 15:58.21 | tzanger | blah |
| 15:58.58 | tzanger | hard_xmit gives me a dahdi_chan. pvt points to the module's struct, which still can't tell me which in-module span the channel belongs to |
| 15:59.05 | tzanger | so I have to back-calculate it from its position in the channel array |
| 16:00.16 | tzanger | eww this is nasty |
| 16:01.01 | sruffell | or you could wrap the dahdi_chan in another structure (my_dahdi_chan, that contains a dahdi_chan, and any other per-channel information you want...then when your making the channels array, point to the address of the chan element of your my_dahdi_chan structure. Then anywhere in your driver you have a channel pointer, you can get to the my_dahdi_chan structure. |
| 16:01.25 | tzanger | that makes it even nastier I think |
| 16:01.30 | tzanger | I'm trying to keep things as pure as possible |
| 16:01.31 | sruffell | really? why? |
| 16:01.52 | sruffell | that is very pure...no looping trying to match addresses, no more pointers to special void* structures, etc... |
| 16:01.58 | tzanger | that would work though, I'm just trying to avoid having all this shit allocated |
| 16:02.05 | tzanger | yeah |
| 16:02.06 | kpfleming | that's exactly the best method, that's the method being used all over kernel code |
| 16:02.19 | tzanger | ok, I will give that a shot |
| 16:02.29 | kpfleming | you don't need to allocate it, it can still be an array |
| 16:02.31 | sruffell | then we can kill the pvt members.... |
| 16:02.32 | tzanger | dammit you two, I just got this not crashing. :-) |
| 16:02.45 | sruffell | only since the channels was made an array of pointers was this possible. |
| 16:02.50 | kpfleming | right |
| 16:02.59 | kpfleming | which wasn't the reason for doing it, but it's a nice side-effect |
| 16:18.00 | *** join/#asterisk-dev shazaum (n=shazaum@unaffiliated/shazaum) |
| 16:19.32 | *** join/#asterisk-dev siera08 (n=chatzill@218.207.141.90) |
| 16:21.02 | *** join/#asterisk-dev Corydon76-lap (n=Corydon7@pdpc/supporter/bronze/Corydon76-home) |
| 16:21.02 | *** mode/#asterisk-dev [+o Corydon76-lap] by ChanServ |
| 16:21.14 | putnopvut | For anyone who wants to see the biggest 'core show locks' output I've ever seen, take a look at this: http://bugs.digium.com/file_download.php?file_id=21880&type=bug |
| 16:24.38 | russellb | that's only like 2 threads |
| 16:24.54 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 16:24.54 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 16:25.47 | putnopvut | russellb: yeah, I know that chan_iax2 makes the output look a lot worse than it really is. But still, that's a pretty impressive size. |
| 16:25.47 | russellb | agreed :-) |
| 16:25.47 | russellb | imagine if every one had a backtrace with it ... |
| 16:25.55 | putnopvut | oh snap |
| 16:26.34 | lmadsen | size? |
| 16:26.42 | lmadsen | I find iax2 debugging very hard to do unfortunately |
| 16:26.49 | *** join/#asterisk-dev caio1982_ (i=caio1982@CAcert-br/caio1982) |
| 16:26.53 | putnopvut | lmadsen: I'm referring to a core show locks upload on an issue. |
| 16:26.58 | lmadsen | gotcha |
| 16:27.06 | lmadsen | I'm just trying to get everyone off topic |
| 16:27.11 | putnopvut | It's cool. |
| 16:27.29 | putnopvut | Just start talking about pop-tarts or ancient egyptian artifacts or something. |
| 16:27.31 | russellb | heh, if you lock something up in chan_iax2, the thread pool will grow until it reaches the max size, as every thread will get stuck |
| 16:27.46 | Corydon76-lap | sneezes |
| 16:27.55 | russellb | gross man, cover your face when you do that |
| 16:29.56 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 16:33.37 | Corydon76-lap | wonders why he must suffer for the sex life of plants. |
| 16:33.52 | russellb | interesting way to put it, heh |
| 16:34.16 | Corydon76-lap | It's a HowardWhitism |
| 16:35.15 | Juggie | lmadsen! |
| 16:35.30 | lmadsen | Juggie! |
| 16:35.46 | *** join/#asterisk-dev Dovid (n=annon@tony09-121-90.inter.net.il) |
| 16:42.09 | *** join/#asterisk-dev eliel (n=eliels@200.61.172.61) |
| 16:42.09 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 16:44.08 | kpfleming | where do we stand on 1.4 branch release status? i want to merge my symbol namespace cleanup branch, but not if the next release is less than 2 weeks away |
| 16:46.12 | lmadsen | kpfleming: 1.4.24-rc1 will be out tomorrow morning |
| 16:46.18 | lmadsen | I've already tagged it |
| 16:46.25 | kpfleming | ok, then i'll wait until it hits 1.4.24 then |
| 16:46.33 | lmadsen | ok, that should be by end of the week I expect |
| 17:16.09 | tzafrir_laptop | wonders if nt ptmp is too much for a google soc project |
| 17:17.20 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 17:17.20 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:19.17 | *** part/#asterisk-dev oej (n=olle@ns.webway.se) |
| 17:21.07 | *** join/#asterisk-dev shazaum (n=shazaum@unaffiliated/shazaum) |
| 17:22.53 | tzafrir_laptop | Corydon76-dig, "most people don't enable verbose in production" is a slight optimistic point of view that ignores Trixbox :-) |
| 17:23.10 | kpfleming | verbose going to a log file, he meant |
| 17:23.31 | tzafrir_laptop | they default to only log "full" |
| 17:23.50 | tzafrir_laptop | Unless this has changed recently |
| 17:24.50 | Qwell | tzafrir_laptop: it has not... |
| 17:24.57 | Qwell | and it's a FreePBX default |
| 17:25.19 | Qwell | console logging is just...flag out disabled. |
| 17:25.24 | Qwell | flat* |
| 17:34.08 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.10.119) |
| 17:35.31 | Corydon76-lap | tzafrir_laptop: we generally ignore trixbox, though |
| 17:36.26 | Corydon76-lap | freepbx is a bit different, now |
| 18:03.09 | tzanger | hmm |
| 18:03.19 | tzanger | is the chanconfig() callback called before or after the spanconfig() one? |
| 18:03.21 | tzanger | I think it's after |
| 18:04.29 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 18:14.32 | *** join/#asterisk-dev dwayne (n=dwayne@c-76-29-245-9.hsd1.al.comcast.net) |
| 18:16.36 | tzanger | hmm |
| 18:17.09 | tzanger | is the chan_dahdi.span pointer filled in by dahdi when the span is registered, or should I be initializing that myself? (i.e. can I sneak a pointer in there to a span) |
| 18:19.05 | *** join/#asterisk-dev bkw_ (n=brian@freeswitch/developer/bkw) |
| 18:26.19 | *** join/#asterisk-dev mosty (n=mosty@213-66-224-163-no22.tbcn.telia.com) |
| 18:29.51 | *** join/#asterisk-dev eliel (n=eliels@200.61.172.61) |
| 18:29.51 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 18:30.47 | *** join/#asterisk-dev Jabka (n=jabka@CBL217-132-73-4.bb.netvision.net.il) |
| 18:38.26 | eliel | Corydon76-lap: http://svn.digium.com/view/asterisk/trunk/main/xml.c?r1=153365&r2=173130 |
| 18:39.22 | eliel | I think you need to check for #ifndef _POSIX_C_SOURCE .. #endif before defining it. |
| 19:25.01 | *** join/#asterisk-dev snuff-home (n=snuffy@203-219-29-182-bri-ts6-2600.tpgi.com.au) |
| 19:25.01 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 19:34.59 | russellb | R190 |
| 19:35.01 | MuffinMan | [R190] Doxygen API Changes for 1.6.0 -> 1.6.1 [Pending] Submitted by jpeeler => http://reviewboard.digium.com/r/190/ |
| 19:35.03 | russellb | jpeeler: i posted some comments |
| 19:38.52 | jpeeler | thanks |
| 19:39.03 | jpeeler | is it clear that \since means that function existed since that version? |
| 19:40.10 | russellb | yeah, but for stuff that actually is not new in 1.6.1 ... |
| 19:40.13 | russellb | that seems kind of weird |
| 19:40.27 | jpeeler | it is new, or they appeared to be to me |
| 19:40.34 | russellb | orly. |
| 19:40.35 | jpeeler | those are newly added API calls |
| 19:40.40 | russellb | ORLY. |
| 19:40.43 | russellb | let me look again. |
| 19:41.26 | jpeeler | it even double checked to make sure that they hadn't just moved locations, which occurred a few times |
| 19:41.41 | jpeeler | and by it, i mean i |
| 19:42.41 | russellb | ok, then i totally take back that comment |
| 19:42.48 | russellb | i did not look close enough |
| 19:42.50 | jpeeler | cool, i kind of liked it |
| 19:42.54 | russellb | oh, absolutely |
| 19:43.00 | russellb | i just misunderstood the changes that were made ... |
| 19:44.17 | russellb | gives jpeeler a "Ship It!" |
| 19:45.01 | Corydon76-lap | pokes russellb with the str_substitution stick |
| 19:45.07 | russellb | eeeeeep |
| 19:45.16 | russellb | we can schedule that patch for 1.6.3 |
| 19:45.30 | russellb | btw, Corydon76-dig ... it would make me happy to see a test module for that, hint hint! |
| 19:45.31 | russellb | :-) |
| 19:46.18 | Corydon76-lap | Um, I dunno how that would work |
| 19:47.18 | russellb | create a dummy channel, put some vars on it, and call the substitution API call |
| 19:47.22 | russellb | then make sure you get the result you expect |
| 19:47.25 | russellb | something alone those lines |
| 19:47.29 | russellb | along* |
| 19:47.38 | Corydon76-lap | No, I understand that part |
| 19:47.42 | russellb | ok? |
| 19:47.54 | russellb | a CLI command that runs it |
| 19:48.09 | Corydon76-lap | The issue is that with the number of modules I'm touching, the number of tests is obscene |
| 19:48.10 | russellb | and at some point, we'll have to come up with a way for tests to be registered as a "test" instead of a normal CLI command |
| 19:48.28 | russellb | well, i don't think full coverage is a requirement at this point |
| 19:48.39 | russellb | just something that uses the core API call |
| 19:48.45 | russellb | not necessary testing every place you modified to use it |
| 19:48.47 | Corydon76-lap | Full coverage isn't the point? |
| 19:48.58 | russellb | I think that's a lot to ask. |
| 19:49.16 | Corydon76-lap | Actually, I just thought of a good way to do it |
| 19:49.19 | russellb | ok :-) |
| 19:49.27 | Corydon76-lap | Run both APIs and compare results |
| 19:49.35 | russellb | interesting idea |
| 19:49.41 | russellb | well, whatever you think .. |
| 19:49.51 | russellb | I just like the idea of starting to collect API test code |
| 19:51.20 | Corydon76-lap | Whatever I think? |
| 19:51.30 | Corydon76-lap | I think orange would be a great color for the sky |
| 19:51.42 | russellb | agreed! |
| 19:51.44 | russellb | make it so! |
| 19:53.50 | *** join/#asterisk-dev Flare_123 (n=flare@189.101.252.221) |
| 19:59.24 | *** join/#asterisk-dev Jabka (n=jabka@CBL217-132-73-4.bb.netvision.net.il) |
| 20:03.01 | tzanger | what the blue expletive |
| 20:03.03 | tzanger | [ 211.988488] i=0, i & 0x03=0, &b4->spans[0]=f76b8054 |
| 20:03.03 | tzanger | [ 211.988567] i=1, i & 0x03=1, &b4->spans[1]=000000b0 |
| 20:03.03 | tzanger | [ 211.988639] i=2, i & 0x03=2, &b4->spans[2]=0000010c |
| 20:03.03 | tzanger | [ 211.988717] i=3, i & 0x03=3, &b4->spans[3]=00000168 |
| 20:03.45 | tzanger | struct ooga_span spans[SPANS_PER_MODULE];/* Individual spans */ |
| 20:04.02 | tzanger | how the hell do I get the first address looking normal and the others not from a freakin array?? |
| 20:04.25 | tzanger | SPANS_PER_MODULE is 4 |
| 20:05.50 | kpfleming | i don't understand |
| 20:05.55 | kpfleming | what is 'normal' |
| 20:06.18 | tzanger | &b4->spans[0] is good |
| 20:06.27 | kpfleming | ok |
| 20:06.42 | tzanger | &b4->spans[1] should be sizeof(struct ooga_span) bytes "farther down" |
| 20:06.47 | kpfleming | right |
| 20:06.49 | tzanger | &b4->spans[2] should be 2*that down |
| 20:06.51 | tzanger | etc |
| 20:07.03 | kpfleming | plus maybe some alignment pading between, yes |
| 20:07.03 | tzanger | so how in the hell is a statically defined array giving me such weird addresses? |
| 20:07.07 | tzanger | right |
| 20:07.16 | tzanger | I am pretty sure I'm not overflowing a 32-bit pointer though with padding :-) |
| 20:07.17 | kpfleming | well, it's not 'static', but anyway |
| 20:07.35 | putnopvut | I think he means statically sized. |
| 20:07.39 | kpfleming | yes |
| 20:07.45 | kpfleming | is thinking |
| 20:07.48 | tzanger | you know what I'm trying to say... much like my english, I know what it is I am doing, but I can't seem to locate the right word to describe it |
| 20:07.56 | kpfleming | try &(b4->spans[1]) |
| 20:07.59 | kpfleming | just for kicks |
| 20:08.20 | tzanger | I can tell you when a sentence is wrong, and how to fix it, but I can't tell you that the error is a split infinitive or a gerund reverse preposition transposal or someshit :-) |
| 20:08.22 | kpfleming | if that works, i won't be able to explain why |
| 20:08.27 | tzanger | haha :-) |
| 20:10.50 | kpfleming | how soon will somebody be able to give me a link to a prebuilt version of the doxygen docs with jpeeler's changes in them? i'm lazy |
| 20:11.32 | tzanger | tsk tsk, our fearless leader shouldn't display laziness, the rest of us will set the bar 10% lower :-) |
| 20:11.35 | jpeeler | ha |
| 20:12.19 | kpfleming | what i really mean is that i'm knee deep in importing an ugly Windows code base into Subversion, dealing with mixed line endings and other such fun |
| 20:13.06 | tzanger | kpfleming: better. |
| 20:13.06 | file | clones kpfleming in SVN |
| 20:13.10 | tzanger | but your suggestion didn't change anything |
| 20:13.27 | kpfleming | ok, i expected that |
| 20:13.35 | kpfleming | that's pretty bizarre |
| 20:13.37 | tzanger | me too |
| 20:14.02 | kpfleming | wait... how is 'b4' defined in this case? |
| 20:14.15 | tzanger | struct mystruct *b4 |
| 20:14.23 | tzanger | and then |
| 20:14.29 | tzanger | b4 = wc->mods[i].bri; |
| 20:14.36 | tzanger | (.bri is a void *) |
| 20:14.56 | kpfleming | and the spans array is inside that struct? |
| 20:15.17 | tzanger | yes, spans is defined inside b4, like this |
| 20:15.48 | tzanger | struct mystruct { ... struct ooga_span spans[A_DEFINE_SET_TO_4]; ... }; |
| 20:16.44 | Corydon76-lap | #define A_DEFINE_SET_TO_4 173 |
| 20:17.49 | kpfleming | something is wrong with your output |
| 20:18.06 | kpfleming | if i add 0x5c to the first address, i get the same address with the last two digits 'b0' |
| 20:18.16 | kpfleming | and then adding 0x5c again results in the correct last two digitis |
| 20:18.24 | tzanger | it's just a printk(%p) |
| 20:18.28 | kpfleming | or three, even |
| 20:18.39 | tzanger | and when it crashes, the CPU definitely is trying to access 000000b0 |
| 20:18.48 | kpfleming | which would likely fail :-) |
| 20:19.06 | tzanger | yes, I haven't managed to merge the JUST_ACCESS_IT_DAMMIT patch :-( |
| 20:19.54 | kpfleming | did you store that computed address into a variable, or is the expressed passed to printk() that actual expression? |
| 20:20.32 | tzanger | well I was trying to set the span->pvt pointer to &b4->spans[i], which is how I got to this |
| 20:20.32 | tzanger | I've done this kind of thing dozens of times before |
| 20:20.47 | tzanger | right now I'm just displaying my math, so to speak |
| 20:21.04 | kpfleming | but what is in your printk() call, the span->pvt variable or the actual address expression? |
| 20:21.43 | kpfleming | i agree, this should be working, and it's making any sense |
| 20:22.00 | tzanger | oh the actual address expression |
| 20:22.04 | kpfleming | ok |
| 20:22.25 | tzanger | wow pastebin's slow |
| 20:22.31 | tzanger | slow as mole's asses in january :-) |
| 20:22.42 | tzanger | gonna have to watch the mvoie again |
| 20:24.20 | tzanger | http://pastebin.com/d4b3d7bf5 |
| 20:24.22 | tzanger | that's the code fragment |
| 20:24.28 | tzanger | (pastebin.ca sucks today) |
| 20:26.29 | kpfleming | well, yeah..... that looks perfectly normal |
| 20:26.42 | tzanger | ok, I'm not on crack |
| 20:26.57 | file | tzanger: maybe you aren't. |
| 20:27.17 | tzanger | haha |
| 20:28.30 | Corydon76-lap | but you're still crazy |
| 20:28.38 | kpfleming | it can't be coincidence that the first 5 digits are all zero... something is doing that |
| 20:28.42 | tzanger | yes |
| 20:28.49 | tzanger | that was my thought as well |
| 20:28.49 | kpfleming | the structs are 0x5c in size, not 0xb0 |
| 20:29.00 | kpfleming | so the spans[1] is not the offset from spans[0] |
| 20:29.46 | *** join/#asterisk-dev Jabka (n=jabka@89-139-77-49.bb.netvision.net.il) |
| 20:31.33 | putnopvut | tzanger: I think I see the problem. |
| 20:31.39 | putnopvut | b4 isn't the same variable every time. |
| 20:32.06 | putnopvut | each time that i is different, b4 is set to something completely different to begin with. |
| 20:32.31 | kpfleming | right |
| 20:32.34 | tzanger | yes... but it should be. because each mods[] is a different instance of that structure |
| 20:32.40 | tzanger | although technically in this |
| 20:32.42 | tzanger | nevermind |
| 20:32.43 | tzanger | I think that's it |
| 20:32.46 | kpfleming | you aren't asking for the address of each span in a single b4 |
| 20:32.47 | tzanger | hang on let me check something |
| 20:32.56 | kpfleming | you are asking for the n'th span in b4 number n |
| 20:33.31 | tzanger | yes that is it |
| 20:33.44 | tzanger | I don't init mods[].bri every time |
| 20:33.48 | kpfleming | kudos to putnopvut |
| 20:33.58 | putnopvut | w00t |
| 20:33.58 | tzanger | one chip handles 4 "modules" |
| 20:34.12 | kpfleming | so each module should have the same bri pointer |
| 20:34.14 | tzanger | so I only do a throrough init on the 1st of the 4 |
| 20:34.14 | tzanger | wow |
| 20:34.18 | tzanger | excellent catch, putnopvut |
| 20:34.26 | file | putnopvut is like that. |
| 20:34.40 | tzanger | kpfleming: yes, I need to make sure that is handled in the partial init as well |
| 20:34.49 | kpfleming | so the random data in the other bri pointers just happened to be the right amount to offset your calculated address |
| 20:34.54 | Corydon76-lap | tosses a granola bar dipped in chocolate at putnopvut |
| 20:34.57 | kpfleming | that is freaky |
| 20:35.03 | putnopvut | Corydon76-lap: do you actually have those? |
| 20:35.15 | Corydon76-lap | putnopvut: A Kudos bar? No. |
| 20:35.19 | tzanger | basically when (i & 0x03) == 0, I do a full probe and init. when it isn't, I just check to see if mods[i & 0xfc] was found and if so, do a quickie init |
| 20:35.28 | putnopvut | Corydon76-lap: ah, can't believe I missed the reference. |
| 20:35.44 | tzanger | kpfleming: well I bet bri is 0x00000000 |
| 20:35.47 | russellb | This just in from The_Boy_Wonder ... it is not a good idea to try to fill in fields of an IAX frame after the data has already been encrypted. that is all. |
| 20:35.50 | tzanger | so it's just indexing past that, plus the offset |
| 20:35.57 | putnopvut | russellb: noted |
| 20:36.00 | russellb | :-) |
| 20:36.06 | russellb | silly code alert! |
| 20:36.06 | tzanger | putnopvut: thank you, amazing detective work |
| 20:36.15 | Corydon76-lap | I don't even know if they make Kudos bars anymore |
| 20:36.16 | file | drinks for all! |
| 20:36.23 | putnopvut | tzanger: thanks! |
| 20:36.42 | Corydon76-lap | Make mine Sarsaparilla |
| 20:37.08 | putnopvut | Corydon76-lap: I think quaker (and probably other brands) make granola bars dipped in chocolate, though. |
| 20:37.36 | file | they do. |
| 20:38.10 | tzanger | that's the only other variable that needed to be inited. :-) |
| 20:39.06 | kpfleming | yay |
| 20:40.37 | tzanger | man what is it with me leaving off semicolons these past few days |
| 20:41.01 | tzanger | "hey homer! I can see your doodle!" |
| 20:43.10 | tzanger | awesome, now it's crashing somewhere else. :-) |
| 20:44.07 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@bzq-179-75-202.static.bezeqint.net) |
| 20:44.07 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 20:44.36 | Corydon76-lap | file: I'm showing that Kudos aren't available in this area |
| 20:45.13 | Corydon76-lap | Springfield, IL is the closest |
| 20:47.05 | *** join/#asterisk-dev ajohnson (n=ajohnson@63.147.46.186) |
| 20:51.41 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 20:51.41 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 21:15.01 | *** part/#asterisk-dev Jabka (n=jabka@89-139-77-49.bb.netvision.net.il) |
| 21:27.29 | *** join/#asterisk-dev pmhaddad (n=Phil@71.238.235.47) |
| 21:28.49 | putnopvut | aw man, those doxygen caused conflicts all over the issue8824 branch. |
| 21:28.56 | putnopvut | s/doxygen/doxygen changes/ |
| 21:29.06 | file | putnopvut: ;( |
| 21:29.17 | putnopvut | A winking sad face. |
| 21:33.10 | kpfleming | hopefully they'll be easy to correct |
| 21:35.36 | putnopvut | kpfleming: so far so good. |
| 21:59.49 | putnopvut | Well, that was a waste of time. I decided to run the LLVM CLANG static analyzer on Asterisk and it generated no reports. Apparently our code is perfect by that static analyzer. |
| 22:12.34 | Corydon76-lap | putnopvut: good news! |
| 22:13.54 | kpfleming | or the tool is terrible :-) |
| 22:14.41 | putnopvut | kpfleming: I think that is more likely. |
| 22:15.08 | Corydon76-lap | Cynics, all of you |
| 22:16.29 | *** join/#asterisk-dev qdk (n=qdk@0x573d8dd1.bynqu2.dynamic.dsl.tele.dk) |
| 22:17.21 | kpfleming | jpeeler: is your C++/MALLOC_DEBUG stuff in a branch somewhere? |
| 22:17.51 | jpeeler | it is not, i can put it in one now |
| 22:18.10 | kpfleming | you should... any time you have more than an hour or two in something it should be backed up in subversion :-) |
| 22:18.24 | kpfleming | i think i can handle the ast_free() stuff pretty quickly |
| 22:18.34 | jpeeler | i know... i should improve that |
| 22:18.44 | kpfleming | i just need to build chan_h323 with MALLOC_DEBUG enabled to reproduce the problem, right? |
| 22:19.26 | jpeeler | pretty much |
| 22:22.09 | *** join/#asterisk-dev eliel (n=eliels@151-202-114-200.fibertel.com.ar) |
| 22:22.09 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 22:25.13 | jpeeler | kpfleming: https://origsvn.digium.com/svn/asterisk/team/jpeeler/bug13593-2 |
| 22:26.00 | *** join/#asterisk-dev djbelieny (n=djbelien@72-48-61-165.dyn.grandenetworks.net) |
| 22:26.05 | *** part/#asterisk-dev djbelieny (n=djbelien@72-48-61-165.dyn.grandenetworks.net) |
| 22:28.30 | *** join/#asterisk-dev mib_5ozpug (i=d936d556@gateway/web/ajax/mibbit.com/x-eea7e9caaea58c3a) |
| 22:29.30 | *** part/#asterisk-dev mib_5ozpug (i=d936d556@gateway/web/ajax/mibbit.com/x-eea7e9caaea58c3a) |
| 22:39.33 | *** join/#asterisk-dev snuff-work (n=aaa@203.19.141.34) |
| 22:39.33 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 22:40.28 | putnopvut | stupid time change. |
| 22:40.34 | putnopvut | Gotta go. |
| 22:43.34 | kpfleming | jpeeler: thanks |
| 22:43.48 | jpeeler | kpfleming: no thank you! |
| 22:44.08 | jpeeler | the branch isn't in a good state, i haven't really done anything with it since last week |
| 22:44.21 | *** join/#asterisk-dev bird_of_Luck (n=melifaro@secured.by.ipfw.ru) |
| 22:44.37 | kpfleming | alright |
| 22:44.42 | kpfleming | i'll play around a bit |
| 22:46.15 | seanbright | anyone know lisp in here? |
| 22:46.56 | seanbright | i want to convert asterisk to lisp and want to know if there is any interest |
| 22:46.59 | seanbright | (kidding) |
| 22:47.08 | kpfleming | i used to... worked in LISP for many years |
| 22:47.50 | seanbright | mind taking a gander at a little snippit and tell me if there are ways to improve it? |
| 22:47.59 | kpfleming | heh... i doubt i can, but i can try |
| 22:48.13 | seanbright | it's like 12 lines |
| 22:48.14 | seanbright | http://pastie.org/private/bhypqqdtcyieyhmzyjpag |
| 22:48.19 | kpfleming | it's been 25 years or so |
| 22:48.25 | seanbright | i'm trying to learn this stuff... |
| 22:48.29 | seanbright | for whatever reason. |
| 22:49.09 | seanbright | i still need to read up on the "right" way to indent this stuff |
| 22:49.48 | kpfleming | put it all on one line:-) |
| 22:50.14 | seanbright | heh |
| 22:50.21 | seanbright | for serious? |
| 22:50.23 | kpfleming | no |
| 22:50.27 | seanbright | phew |
| 22:50.32 | kpfleming | well, based on my 25-year old memory, that looks sane |
| 22:50.39 | seanbright | excellent. |
| 22:51.06 | seanbright | i mean, it definitely works, but i'm sure some lisp guru could write it in like 4 lines and it would be faster |
| 22:53.41 | Corydon76-lap | kpfleming: your memory is younger than you are? |
| 22:53.51 | kpfleming | my lisp memory, yes |
| 22:55.24 | *** join/#asterisk-dev schmooze (n=schmooze@rrcs-67-52-212-6.west.biz.rr.com) |
| 23:04.59 | Dovid | hi. anyone know of issues with refer on asterisk 1.4.23.1 ? |
| 23:07.15 | *** join/#asterisk-dev moy (n=chatzill@74.12.124.89) |
| 23:14.02 | *** join/#asterisk-dev shazaum (n=shazaum@unaffiliated/shazaum) |
| 23:19.41 | *** join/#asterisk-dev blitzrage (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 23:19.41 | *** mode/#asterisk-dev [+o blitzrage] by ChanServ |
| 23:25.14 | shazaum | tinezinha |
| 23:33.16 | *** join/#asterisk-dev eliel (n=eliels@151-202-114-200.fibertel.com.ar) |
| 23:33.16 | *** mode/#asterisk-dev [+o eliel] by ChanServ |