| 00:01.01 | jmls | surely this must have caught someones attention ? |
| 00:01.04 | jmls | M10905 |
| 00:01.05 | MuffinMan | [new] [Asterisk] Core-General 0010905: [crash] asterisk segfaults using tab completion reported by jmls http://bugs.digium.com/view.php?id=10905 |
| 00:01.19 | jmls | nice simple bug. easy to fix |
| 00:01.50 | jmls | russellb: it's present in 1.4.12 ... |
| 00:05.29 | jmls | oh. that's right. when the going gets tough .. |
| 00:05.34 | jmls | ;) |
| 00:05.45 | jmls | I'll catch him later .. |
| 00:06.01 | jmls_gotta_sleep | night all |
| 00:06.05 | *** join/#asterisk-dev russellb_ (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 00:06.05 | *** mode/#asterisk-dev [+o russellb_] by ChanServ |
| 00:18.15 | Corydon76-dig | bkruse: pong |
| 00:22.20 | tzafrir_home | gdb question: how do I get gdb to load symbols automatically? I execute asterisk form the build directory but I execute a copy installed to a DESTDIR |
| 00:23.33 | tzafrir_home | Currently my gdbinit is: |
| 00:23.53 | tzafrir_home | set args -C /home/tzafrir/Proj/Asterisk/Svn/asterisk/team/group/zapata_conf/live/etc/asterisk/asterisk.conf -c |
| 00:23.55 | Qwell | tzafrir_home: it should "Just Happen" |
| 00:24.01 | tzafrir_home | What else should I add? |
| 00:24.18 | Qwell | it should pull all the symbols from the modules as it loads them |
| 00:24.24 | Qwell | or something |
| 00:25.52 | bkruse | Corydon76-dig: see the swdev thing about misdn, I had some questions about #include |
| 00:27.01 | Corydon76-dig | ok |
| 00:50.06 | tzafrir_home | the locking in chan_zap is so much fun |
| 00:52.22 | tzafrir_home | do_monitor holds the iflock for the whole long period of the poll . But gives it up in the end of the lop. And then at the beginning of a new loop the lock is taken again. Ad the file descriptors in the result of the poll are assumed to still be valid |
| 00:56.20 | tzafrir_home | but at least gdb is working (symbols indeed do get loaded) |
| 01:14.33 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 01:17.54 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 01:28.53 | *** join/#asterisk-dev snuffy-home (n=snuff-ho@C-59-101-248-206.bur.connect.net.au) |
| 01:55.21 | *** join/#asterisk-dev yannj_fr (n=yannj_fr@tvn95-3-82-237-158-147.fbx.proxad.net) |
| 02:08.19 | *** join/#asterisk-dev mitcheloc (n=mitchel@adsl-68-120-68-89.dsl.irvnca.pacbell.net) |
| 02:52.36 | *** join/#asterisk-dev JackEStorm (n=no@ip68-225-77-136.no.no.cox.net) |
| 03:04.16 | De_Mon | try a different ec algorythem |
| 03:04.35 | De_Mon | algorithm even |
| 03:06.50 | *** join/#asterisk-dev ksteward (n=ksteward@71.174.94.169) |
| 04:22.37 | *** join/#asterisk-dev bkruse_home (n=bkruse@69.73.127.92) |
| 04:29.27 | *** join/#asterisk-dev blitzrage (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 05:48.13 | *** join/#asterisk-dev blitzrage (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 07:34.42 | *** join/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-12-187.bredband.comhem.se) |
| 08:33.46 | *** join/#asterisk-dev tzafrir (n=tzafrir@62.90.10.53) |
| 08:33.46 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 09:34.07 | *** join/#asterisk-dev mvanbaak (n=mafkees@vanbaak.xs4all.nl) |
| 14:44.58 | *** join/#asterisk-dev anonymouz666 (n=anonymou@200.218.193.6) |
| 15:13.48 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 15:27.32 | *** join/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-12-187.bredband.comhem.se) |
| 15:49.16 | *** join/#asterisk-dev blitzrage (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 15:50.07 | *** join/#asterisk-dev russellb_ (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 15:50.10 | *** mode/#asterisk-dev [+o russellb_] by ChanServ |
| 16:13.03 | blitzrage | morning all |
| 16:18.11 | Corydon76-dig | morning |
| 16:49.29 | *** join/#asterisk-dev ssokol (n=ssokol@ip70-189-77-103.ok.ok.cox.net) |
| 17:14.46 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 17:40.20 | *** join/#asterisk-dev CunningPike (n=CunningP@S010600095b33697f.vc.shawcable.net) |
| 18:46.48 | *** join/#asterisk-dev qdk (n=qdk@0x573fe57e.bynqu2.broadband.tele.dk) |
| 19:20.18 | *** join/#asterisk-dev russellb_ (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 19:20.18 | *** mode/#asterisk-dev [+o russellb_] by ChanServ |
| 20:16.30 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 20:36.31 | *** join/#asterisk-dev mitcheloc (n=mitchel@adsl-67-127-235-238.dsl.irvnca.pacbell.net) |
| 21:20.20 | *** part/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-12-187.bredband.comhem.se) |
| 21:25.34 | jmls_gotta_sleep | mmm. there is a crappy problem with queues in 1.4 |
| 21:26.46 | jmls_gotta_sleep | I've just witnessed two calls being put through to the same agent |
| 21:27.48 | jmls_gotta_sleep | man, this sucks |
| 21:28.03 | jmls_gotta_sleep | could autofill cause this problem ? |
| 21:28.57 | jmls_gotta_sleep | I'm using a local channel as the interface. I know that the local/xxx can be called mulitple times, even if it's already on another call |
| 21:31.34 | jmls_gotta_sleep | I was checking the group count before accepting the call, but I suspect that the two calls were within micro seconds of each other, so the group count was zero for both. |
| 21:32.07 | jmls_gotta_sleep | would setting the group count in an exclusive macro prevent this ? |
| 21:54.37 | *** join/#asterisk-dev russellb_ (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 21:54.37 | *** mode/#asterisk-dev [+o russellb_] by ChanServ |
| 22:00.30 | jmls_gotta_sleep | is there any reason why a queue would take more than 2 seconds to find an available member when |
| 22:00.38 | jmls_gotta_sleep | a) there is an available member |
| 22:01.02 | jmls_gotta_sleep | b) the agent automatically accepts a call |
| 22:10.55 | russellb_ | jmls_gotta_sleep: in a perfect world, no |
| 22:11.08 | russellb_ | app_queue is not a perfect world |
| 22:12.02 | jmls_gotta_sleep | autofill=no seems to solve the behaviour |
| 22:12.09 | jmls_gotta_sleep | I'm running a test campaign to see |
| 22:12.55 | jmls_gotta_sleep | it also seems to solve the problem of the same agent being offered two calls from the same queue at the same time |
| 22:28.39 | jmls_gotta_sleep | damn. |
| 22:28.46 | jmls_gotta_sleep | that didn't work either |
| 22:32.43 | wwalker | is there any reason that I can't/shouldn't run multiple asterisk instances on one machine |
| 22:33.53 | wwalker | particularly running them all binding on diufferent ports or different ips |
| 22:34.42 | wwalker | :) |
| 22:40.01 | *** join/#asterisk-dev russellb_ (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 22:40.10 | *** mode/#asterisk-dev [+o russellb_] by ChanServ |
| 23:04.46 | jmls_gotta_sleep | I need to put a call through to a local channel very qucikly and uniquely (each channel must only get called when it's free) |
| 23:05.09 | jmls_gotta_sleep | group_count doesn't work fast enough |
| 23:05.39 | jmls_gotta_sleep | app_queue is _way_ too slow |
| 23:07.04 | jmls_gotta_sleep | all I need is a very simple list ; fifo : get top entry, remove it. Call that entry |
| 23:07.27 | jmls_gotta_sleep | is there a way of implementing a fifo in the dialplan ? |
| 23:11.55 | wwalker | under heavy call volume, will asterisk make use of multiple cores? |
| 23:24.05 | *** join/#asterisk-dev Qwell_ (n=north@pdpc/sponsor/digium/Qwell) |
| 23:24.05 | *** mode/#asterisk-dev [+o Qwell_] by ChanServ |
| 23:26.27 | jmls_gotta_sleep | I thought that macro exclusive, was, well, exclusive ? |
| 23:29.34 | jmls | oh, well, isn't that just peachy. |
| 23:29.57 | jmls | sorry seems like a red herring. problem is with me |
| 23:59.17 | jmls | noob c question: && is "and" right ? |