| 00:18.04 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-21-152.hsd1.sc.comcast.net) |
| 00:18.04 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 00:58.06 | *** join/#asterisk-dev Deeewayne (n=dwayne@76.29.245.9) |
| 00:58.06 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 01:07.30 | *** join/#asterisk-dev leif[mobile] (n=leifmads@asterisk/documenteur-extraordinaire/blitzrage) |
| 01:07.30 | *** mode/#asterisk-dev [+o leif[mobile]] by ChanServ |
| 01:20.51 | *** join/#asterisk-dev securevoip (n=securevo@c-76-123-20-170.hsd1.va.comcast.net) |
| 01:24.58 | *** join/#asterisk-dev schmooze (n=schmooze@h69-129-142-83.mdsnwi.tisp.static.tds.net) |
| 01:56.38 | *** join/#asterisk-dev classicmac (n=michaelm@udp223660uds.hawaiiantel.net) |
| 02:14.11 | *** join/#asterisk-dev moy (n=moy@CPE001cdfec4cee-CM00080dab8485.cpe.net.cable.rogers.com) |
| 02:48.51 | *** part/#asterisk-dev securevoip (n=securevo@c-76-123-20-170.hsd1.va.comcast.net) |
| 03:02.29 | *** join/#asterisk-dev securevoip (n=securevo@c-76-123-20-170.hsd1.va.comcast.net) |
| 03:17.58 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-21-152.hsd1.sc.comcast.net) |
| 03:17.58 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 03:45.35 | seanbright | so b |
| 03:45.37 | seanbright | grr |
| 03:46.18 | seanbright | so ast_rwlock_wrlock is blocking but it doesn't look like any other threads own the lock |
| 03:59.19 | seanbright | nevermind. i'm just not smart. |
| 04:22.34 | *** join/#asterisk-dev CunningPike (n=CunningP@S01060014bf81366b.vc.shawcable.net) |
| 04:23.12 | snuff-work | seanbright: ur not smart.. it took me 30 minutes to work out again how ast_list worked on the train.. i think that makes me worse :) |
| 04:39.57 | *** join/#asterisk-dev qdk (n=qdk@0x573d8dd1.bynqu1.dynamic.dsl.tele.dk) [NETSPLIT VICTIM] |
| 05:34.22 | *** join/#asterisk-dev {Repelex} (n=STRESSAD@201.86.177.249.dynamic.adsl.gvt.net.br) |
| 05:51.13 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 05:51.13 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:12.55 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 06:19.31 | tzafrir_laptop | the simplest rate limiting is with a static variable |
| 06:44.25 | snuff-work | mm.. i thought someone fixed the cli colours issue with xml doc? |
| 07:17.17 | mvanbaak | snuff-work: I've seen a commit about that yeah |
| 07:18.08 | snuff-work | well still didn't help on my run before.. |
| 07:40.11 | snuff-work | how's mvanbaak going anyway? |
| 07:41.02 | mvanbaak | too busy to feel wonderfull |
| 07:43.05 | mvanbaak | and you ? |
| 07:46.41 | snuff-work | mm quiet.. just doing online tests for work etc |
| 07:46.59 | snuff-work | did get myself a new toy recently.. |
| 07:47.25 | snuff-work | http://www.laptopmag.com/review/laptops/samsung-n-110.aspx |
| 07:59.29 | mvanbaak | nice |
| 07:59.35 | mvanbaak | I had a netbook as well |
| 07:59.44 | mvanbaak | but it's now sitting idle on a shelf |
| 07:59.53 | mvanbaak | I'm not using it at all |
| 08:01.38 | snuff-work | mm u got one from ur internet provider right? |
| 08:03.01 | mvanbaak | yup |
| 08:04.09 | snuff-work | see i have a use for mine.. i travel 1 3/4 hrs each way on a train.. hate to lug my full work laptop around at 3kg and only 1 hr batt life |
| 08:06.10 | mvanbaak | ah, that makes sense |
| 08:06.32 | mvanbaak | for that reason I bought a thinkpad T61 with the extra battery you put where the dvd-burner is |
| 08:07.02 | mvanbaak | almost 5 hours of battery time now with bluetooth enabled |
| 08:07.03 | *** join/#asterisk-dev oej (n=olle@213.136.49.145) |
| 08:07.03 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:07.18 | snuff-work | mm.. thing is i dont need all that power.. i just dont re-configure ast and compile from scratch n its fine :) |
| 08:07.22 | mvanbaak | I use it together with my Nokia E71 to have inet access on it while in the train |
| 08:07.51 | snuff-work | well its bout time i got that train home.. |
| 08:08.07 | snuff-work | bb in bout 2 1/2 hrs.. |
| 08:13.34 | mvanbaak | have fun |
| 09:10.08 | *** join/#asterisk-dev dinhtrung (n=dinhtrun@118.71.94.128) |
| 09:14.35 | *** join/#asterisk-dev Pazzo (n=ugelt@reserved-225136.rol.raiffeisen.net) |
| 10:35.59 | *** join/#asterisk-dev uluatu (n=uluatu@189.32.44.21) |
| 11:10.52 | snuff-home | ... |
| 11:11.01 | mvanbaak | welcome home |
| 11:11.14 | snuff-home | been home for a bit.. |
| 11:11.30 | snuff-home | bout 1 hr |
| 11:14.49 | snuff-home | i'm lookin at convertin res_smdi.. some of it back to lists rather than astobj |
| 11:15.22 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 11:16.37 | snuff-home | i think after i've done a bit more of conversion i'll put it up for punishment (reviewboard) ;) |
| 11:16.54 | mvanbaak | ;) |
| 11:45.06 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:45.06 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:47.05 | mvanbaak | mornin Kevin |
| 12:02.15 | kpfleming | howdy |
| 12:08.52 | kpfleming | today, we head for the beach |
| 12:08.58 | kpfleming | sun, sand, waves, seafood... yay |
| 12:14.05 | mvanbaak | yay ! |
| 12:14.07 | mvanbaak | can I come ? |
| 12:15.42 | kpfleming | sure! we leave from the house in two hours, and the condo has a spare bedroom |
| 12:16.35 | mvanbaak | :) will take some time before I'm there. it's going to be a looooooooong walk |
| 12:36.00 | *** join/#asterisk-dev qdk (n=qdk@195.242.194.42) |
| 12:39.58 | *** join/#asterisk-dev eliel (n=eliels@200.61.172.61) |
| 12:39.58 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 12:44.50 | eliel | morning |
| 12:46.26 | eliel | is there a branch where someone is working with chan_agent? |
| 12:50.38 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.23.222.73) |
| 12:51.35 | mvanbaak | eliel: /dev/null |
| 12:51.36 | mvanbaak | ;) |
| 12:52.44 | eliel | there are a lot of dead code i was removing yesterday but i remember a work in progress of an Agent2 |
| 12:53.30 | *** join/#asterisk-dev DarkRift (n=dark@65.92.169.181) |
| 12:57.32 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:57.32 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 13:03.24 | mvanbaak | eliel: I'm not aware of any active development in that area at the moment |
| 13:08.52 | *** join/#asterisk-dev putnopvut (n=putnopvu@asterisk/master-of-queues/mmichelson) |
| 13:08.52 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:09.06 | leifmadsen | mvanbaak: yo! |
| 13:09.11 | leifmadsen | putnopvut: you're in early... |
| 13:09.21 | mvanbaak | ey Leif |
| 13:09.26 | putnopvut | leifmadsen: It's Friday. |
| 13:09.30 | putnopvut | leifmadsen: there are bagels |
| 13:09.32 | putnopvut | nuff said |
| 13:09.46 | leifmadsen | putnopvut: niiiiiiiiiice |
| 13:09.50 | leifmadsen | I wish there were bagels here |
| 13:37.56 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 13:42.12 | *** join/#asterisk-dev malcolmd (n=malcolmd@pdpc/sponsor/digium/malcolmd) |
| 13:42.12 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 13:56.16 | atis_work | hehe, i got bagel with some weird additions in hamburg, when i asked for hamburger :D |
| 13:56.43 | leifmadsen | weird :) |
| 13:56.57 | atis_work | well, i really wanted to try hamburger in hamburg :D |
| 13:57.10 | leifmadsen | lol |
| 13:57.16 | leifmadsen | disappointment abounds |
| 14:09.19 | *** join/#asterisk-dev ctooley (n=ctooley@76.22.158.92) |
| 14:22.03 | *** join/#asterisk-dev Pazzo (n=ugelt@reserved-225136.rol.raiffeisen.net) |
| 14:23.00 | *** join/#asterisk-dev Deeewayne (n=dwayne@75.76.254.162) |
| 14:23.00 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 14:29.09 | *** join/#asterisk-dev davevg-btwtech (n=davevg__@nj-67-76-177-147.sta.embarqhsd.net) |
| 14:35.50 | *** join/#asterisk-dev marv[work] (n=timr@router.asteriasgi.com) |
| 14:40.34 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 14:40.34 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 14:44.11 | seanbright | once a channel variable is set on a channel, the best you can do it set it to empty string, correct? |
| 14:44.20 | seanbright | in other words, you can't remove it completely |
| 14:45.18 | Corydon76-dig | not from the dialplan you can't |
| 14:45.38 | Corydon76-dig | You can remove it completely from C-code, though |
| 14:45.56 | Corydon76-dig | (with API, not just by killing the list item) |
| 14:46.19 | Corydon76-dig | if you set the value to NULL, it removes it completely |
| 14:46.50 | seanbright | gotcha. |
| 14:46.51 | seanbright | thanks. |
| 14:47.57 | *** join/#asterisk-dev moy (n=moy@74.12.123.90) |
| 14:52.04 | leifmadsen | would that be a useful (possible) application or function to be able to remove a channel variable or global variable? |
| 14:53.10 | seanbright | there is probably a reason it hasn't been implemented already |
| 14:53.15 | seanbright | i would think. |
| 14:53.23 | *** join/#asterisk-dev outtolunc (n=me@c-71-198-197-201.hsd1.ca.comcast.net) |
| 14:53.40 | *** join/#asterisk-dev fred-tmft (n=fred-tea@c-69-244-180-112.hsd1.mi.comcast.net) |
| 14:53.53 | *** part/#asterisk-dev fred-tmft (n=fred-tea@c-69-244-180-112.hsd1.mi.comcast.net) |
| 14:54.22 | seanbright | would be trivial to implement though |
| 14:58.03 | atis_work | seanbright: that would be one step forward to real programming |
| 14:58.22 | atis_work | seanbright: there was recently an issue regarding returning NULL values from app_addon_mysql |
| 14:58.55 | russellb | it would be trivial to implement ... you tell me if it's useful :-) |
| 14:59.37 | leifmadsen | well, I've had people ask me how to unload a global variable before, and JunK-Y just came in here asking the same thing the other day -- seems some people want to do it |
| 15:00.14 | atis_work | M15045 |
| 15:00.17 | MuffinMan | [closed] [Asterisk] Addons/app_addon_sql_mysql 0015045: [patch] Fetching a NULL value from database returns "NULL" string reported by chris-mac (Karma: +3.25) https://issues.asterisk.org/view.php?id=15045 |
| 15:00.21 | leifmadsen | also... see #asterisk-bugs for philippel just asking about the functionality :) |
| 15:00.31 | atis_work | see my comments there :) |
| 15:00.49 | seanbright | i'm working on it now |
| 15:00.54 | seanbright | a patch for trunk |
| 15:01.02 | philippel | lol in my case it was for a channel variable, but clearly having that ability for a global would also be valuable |
| 15:01.06 | seanbright | UnSet and MUnSet |
| 15:01.09 | Corydon76-dig | seanbright: It's a REALLY bad idea |
| 15:01.12 | seanbright | heh |
| 15:01.21 | atis_work | basically it's all there, you just need a distinction in dialplan :) |
| 15:01.24 | seanbright | that is why it hasn't been done ^^^^^ |
| 15:04.27 | Corydon76-dig | or rather, it's a really bad idea without changing the implementation of Gosub and local variables |
| 15:05.11 | Corydon76-dig | However, I also believe in giving people enough rope to hang themselves |
| 15:07.16 | seanbright | heh |
| 15:07.49 | seanbright | well will the number of issues on mantis exponentially increase with only a linear increase in flexibility? |
| 15:07.55 | seanbright | that's the litmus test for me. |
| 15:07.57 | Corydon76-dig | All the while warning them, so that when they realize they're choking, we can say "Told you so" |
| 15:11.10 | Juggie | Corydon76-dig, isnt watching the twitching the best part? :) j/k |
| 15:12.53 | Corydon76-dig | twitches |
| 15:15.41 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 15:18.46 | *** join/#asterisk-dev qdk (n=qdk@81.7.168.130) |
| 15:23.35 | *** join/#asterisk-dev JimVanM (n=jimvanm@bas1-toronto63-1096579290.dsl.bell.ca) |
| 15:25.10 | *** part/#asterisk-dev JimVanM (n=jimvanm@bas1-toronto63-1096579290.dsl.bell.ca) |
| 15:31.05 | *** join/#asterisk-dev Octothorpe (n=Octothor@pdpc/supporter/professional/octothorpe) |
| 15:41.17 | *** join/#asterisk-dev jetsnoc (n=brian@root.pmt.org) |
| 15:46.34 | *** join/#asterisk-dev macli (n=macli@nmc.brc.ubc.ca) |
| 15:49.01 | *** join/#asterisk-dev CunningPike (n=CunningP@204.239.10.119) |
| 15:52.56 | *** join/#asterisk-dev jnfuller (n=jnfuller@99.199.170.110) |
| 15:53.19 | jnfuller | are the dahdi-$foo-current.tar.gz on downloads.asterisk.org being refreshed right now? the tarballs seem to be hosed. |
| 15:53.40 | russellb | sruffell is working on fixing those links. |
| 15:54.47 | jnfuller | ah... thanks |
| 16:01.32 | *** join/#asterisk-dev MikeJ (n=MikeJ@freeswitch/developer/mikej) |
| 16:14.11 | *** join/#asterisk-dev mog (n=mog@c-68-62-174-19.hsd1.al.comcast.net) |
| 16:14.11 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 16:43.27 | russellb | Who was asking about setting a timeval to 0 yesterday? jpeeler ? |
| 16:43.38 | jpeeler | um, yes |
| 16:43.48 | russellb | I said something about ast_tvzero(), but that was bogus ... |
| 16:43.50 | jpeeler | you can't do as you proposed |
| 16:43.50 | russellb | sorry. |
| 16:43.52 | jpeeler | right |
| 16:43.55 | russellb | ok, just making sure :-) |
| 16:44.01 | russellb | tv = ast_tv(0, 0); would be it |
| 16:44.43 | russellb | I just tried to do what I proposed in some other code and realized that my suggestion was bogus, sorry, hehe |
| 16:46.05 | jpeeler | it's fine, i ended up just using memset, but will remember ast_tv for later |
| 16:48.54 | russellb | k |
| 16:50.15 | ajohnson | If I submit a new string function, should I supply a diff against SVN trunk, or the 1.6.2 branch? |
| 16:51.17 | jsmith | Against trunk |
| 16:51.34 | ajohnson | thanks |
| 16:59.38 | *** join/#asterisk-dev kamanashisroy (n=kamanash@119.30.36.83) |
| 17:02.18 | Corydon76-dig | jpeeler: also, ast_tvsub(ast_tvnow(), ast_tvnow()) |
| 17:02.37 | jpeeler | heh, ok |
| 17:03.14 | Corydon76-dig | It's how we did it in assembly before we could set a register directly to zero... just subtract it from itself... |
| 17:03.14 | russellb | that's not guaranteed to be 0 :-p |
| 17:03.33 | Corydon76-dig | russellb: close enough. ;-) |
| 17:03.42 | eliel | no, we used xor not sub |
| 17:04.03 | Corydon76-dig | eliel: same result |
| 17:04.10 | russellb | but which is faster? :-) |
| 17:04.43 | Corydon76-dig | Dunno, I've always had immediate mode on my processors |
| 17:05.14 | Corydon76-dig | and immediate mode took 2 cycles, the fastest of any instruction |
| 17:05.32 | Corydon76-dig | Well, except for INC and DEC |
| 17:05.45 | seanbright | ast_tvsub(v = ast_tvnow(), v); |
| 17:05.49 | seanbright | there. |
| 17:05.56 | seanbright | commit. |
| 17:06.12 | Corydon76-dig | seanbright: you'll have to double the parens around the assignment or you'll get a warning |
| 17:06.25 | seanbright | damn... |
| 17:06.35 | seanbright | forgot to compile irssi with --enable-dev-mode |
| 17:07.37 | Corydon76-dig | Is it sicker that seanbright came up with that off the top of his head or that I knew it would produce a warning? |
| 17:08.01 | seanbright | both. |
| 17:08.13 | seanbright | we clearly need to get out more. |
| 17:08.28 | Corydon76-dig | takes seanbright out on a date |
| 17:08.33 | seanbright | heh |
| 17:24.36 | russellb | M14412 |
| 17:24.39 | MuffinMan | [ready for testing] [Asterisk] Resources/General 0014412: [patch] 1.6.1 Choppy sound in Dual Xeon 2.8 GHz reported by dome (Karma: +3.00) https://issues.asterisk.org/view.php?id=14412 |
| 17:24.46 | russellb | putnopvut: I posted a patch there for the timing bug |
| 17:25.26 | russellb | it addresses exactly what we discussed last night. It allows continuous mode and a set rate to coexist peacefully. |
| 17:25.50 | russellb | We're going to have to think about how we want to deal with this in res_timing_timerfd .... |
| 17:28.08 | putnopvut | russellb: cool I'm looking at it now. |
| 17:28.19 | putnopvut | russellb: did you verify that timerfd has the same problem? |
| 17:29.24 | russellb | I haven't tested it yet. I'm assuming that it would have the same issue, just based on how it works, but I guess I shouldn't assume. :-) |
| 17:31.28 | Juggie | assumptions are the mother of all F*$% ups. |
| 17:32.18 | Juggie | L) |
| 17:32.22 | Juggie | er, :) |
| 17:33.10 | seanbright | that's from a segal movie |
| 17:33.14 | seanbright | i just can't remember the name |
| 17:33.18 | Juggie | ummm |
| 17:33.21 | Juggie | under seige i think |
| 17:33.28 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 17:33.31 | seanbright | ah yes |
| 17:33.49 | Juggie | http://www.imdb.com/title/tt0114781/quotes |
| 17:33.57 | seanbright | oh right |
| 17:33.59 | seanbright | the train one |
| 17:34.00 | Juggie | good movie actuallu :) |
| 17:34.04 | Juggie | *actually. |
| 17:34.17 | Juggie | as far as segal movies go |
| 17:35.08 | seanbright | indeed |
| 17:35.15 | seanbright | the eye thing always bothered me |
| 17:35.39 | Juggie | eye thing? |
| 17:35.53 | seanbright | the soldering iron in the eye threat to one of the suits |
| 17:35.59 | Juggie | ah |
| 17:36.00 | seanbright | i can't remember if he actually gets it |
| 17:36.02 | Juggie | indeed :) |
| 17:36.05 | Juggie | i doubt it |
| 17:36.15 | Juggie | if he did it would be off camera |
| 17:36.40 | seanbright | true |
| 17:37.56 | Juggie | another assumptions quote is, assumptions make an *ass* out of *u* and *me*, assume :) |
| 17:39.07 | marv[work] | That one's not i18n safe. |
| 17:39.23 | Juggie | seanbright, do you still work your day job? |
| 17:40.02 | seanbright | i do |
| 17:40.11 | Juggie | sometimes? :) |
| 17:40.15 | seanbright | right now |
| 17:40.21 | seanbright | is working |
| 17:40.49 | eliel | remembers someone working on a new version of chan_agent... but he doesn't remember who... |
| 17:41.48 | russellb | file: |
| 17:42.22 | file | app_agents! |
| 17:48.54 | leifmadsen | oh no you didn't |
| 17:58.04 | eliel | file: chan_agent will be removed? |
| 17:58.57 | eliel | cause i upload a review request of a code cleanup and i will remove it from the review if we will remove it in the future |
| 17:58.57 | seanbright | we don't remove stuff anymore |
| 17:59.10 | file | removing it would make people verrrrrrrrry sad |
| 17:59.25 | seanbright | we are unique... and different from other projects |
| 17:59.29 | seanbright | we have "users" |
| 17:59.35 | seanbright | heh |
| 17:59.57 | seanbright | i can imagine someone posting to the apache dev mailing list: |
| 18:00.07 | eliel | well, we have already removed agentcallbacklogin :P |
| 18:00.07 | seanbright | "i can't believe you guys removed that feature that wasn't working!" |
| 18:00.19 | seanbright | the response: "go fuck yourself." |
| 18:00.20 | seanbright | heh |
| 18:00.25 | seanbright | (it's friday) |
| 18:00.56 | eliel | ok, then i will leave the review where it is.. in the review board, he |
| 18:04.24 | leifmadsen | Marquis42: ping? |
| 18:15.29 | *** join/#asterisk-dev codefreeze-lap (n=murf@72.21.67.40) |
| 18:15.29 | *** mode/#asterisk-dev [+o codefreeze-lap] by ChanServ |
| 18:15.32 | *** join/#asterisk-dev ghenry (n=ghenry@pdpc/supporter/monthlybyte/ghenry) |
| 18:18.46 | *** join/#asterisk-dev JunK-Y (n=junky@modemcable206.69-20-96.mc.videotron.ca) |
| 18:33.08 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 18:37.05 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 18:37.05 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:37.32 | eliel | twilson -> irc nick? |
| 18:39.31 | russellb | otherwiseguy |
| 18:39.50 | eliel | thanks |
| 18:40.20 | *** join/#asterisk-dev otherwiseguy (n=otherwis@75.87.106.119) |
| 18:40.48 | russellb | ta-da! |
| 18:42.01 | eliel | otherwiseguy: hello, it will be nice to have all the libxml2 stuff in the abstraction xml.c we have made to work inside asterisk |
| 18:42.51 | eliel | otherwiseguy: what i couldn't check is if the saxparser is being implemented by other xml implementation |
| 18:44.12 | otherwiseguy | eliel: I will have to take your word for it as I haven't really looked at it--and my xml handling knowledge is fairly limited. For the calendaring stuff I just grabbed what looked prevalent and seemed like it would work. |
| 18:44.38 | otherwiseguy | eliel: let me know if I need to make some changes to calendaring's xml parsing to use internal stuff. |
| 18:45.15 | otherwiseguy | I started the calendaring implementation before there was an xml.c in asterisk. It took a while to get merged. :-) |
| 18:46.25 | eliel | otherwiseguy: yes i know, no problem, i will try to figure out how to modify the xml usage in that api in my free time (free time = ~gsoc and ~work and ~universiry and ~girlfriend) |
| 18:46.43 | russellb | you're not busy at all |
| 18:48.06 | eliel | if i continue like this i will substract(~girlfriend) from the list... i have already substract(~life) |
| 18:55.38 | eliel | R269 |
| 18:55.41 | MuffinMan | [R269] Simplify the Makefile to avoid listing every file inside main/ [Pending] Submitted by eliel => https://reviewboard.asterisk.org/r/269/ |
| 18:56.14 | eliel | two days later... |
| 19:39.36 | Marquis42 | leifmadsen: pong? Just noticed you pinged me... :/ |
| 19:40.04 | leifmadsen | Marquis42: hey! I was going to ask you if you'd used MiniVmMWI at all yet |
| 19:40.16 | Marquis42 | I do, yes. |
| 19:42.06 | Marquis42 | I have an AEL-based voicemail that uses the various MiniVM apps to present both Comedian Mail and Octel-style prompts and menus in production at a small handful of sites now. |
| 19:43.03 | leifmadsen | Marquis42: very cool -- think I could see an exaple of the MWI part? Actually... first question is -- can I use it outside of the minivm.conf file to just provide MWI to a device generally? |
| 19:43.12 | leifmadsen | (or rather, modify the MWI to a device generally) |
| 19:46.34 | Marquis42 | leifmadsen: It does not have any dependency on minivm.conf configs, so for example any peer configured in sip.conf that has a "mailbox=exten@context" line you can send MWI off/on to using it. |
| 19:46.51 | leifmadsen | Marquis42: awesome, that's what i wanted to hear |
| 19:47.10 | leifmadsen | Marquis42: I wonder if that line needs to be associated with an actual voicemail box.... |
| 19:47.25 | leifmadsen | asterisk will probably just complain |
| 19:47.42 | leifmadsen | that gives me enough info to go testing with though! |
| 19:47.44 | leifmadsen | thanks |
| 19:47.45 | Marquis42 | I don't think that it does even that. |
| 19:48.07 | Marquis42 | No problem, I'm glad somebody besides myself finds it potentially useful! |
| 19:50.31 | leifmadsen | Marquis42: so this is what I'm thinking... |
| 19:50.40 | leifmadsen | Marquis42: are you in #asterisk? |
| 19:50.53 | leifmadsen | I'd prefer to talk there |
| 19:50.58 | Marquis42 | I'm not at the moment, but if the forthcoming discussion would be more appropriate I can join. |
| 19:51.01 | Marquis42 | OK, hold on a moment. |
| 19:55.21 | eliel | is there any reason of adding say.o to the OBJS (OBJS+=say.o)?? |
| 19:56.01 | eliel | and not putting it with the rest of the object list? |
| 19:56.50 | ajohnson | Can anyone take a look at this and tell me if this is a bug: http://pastebin.com/d642a6ad0 |
| 19:57.19 | ajohnson | Basically Asterisk is stopping in the middle of a context after a GotoIfTime and is not following either execution path (is. either true or false) |
| 20:18.59 | Corydon76-dig | ajohnson: it was a bug, but it's already been fixed |
| 20:19.43 | leifmadsen | svn co http://svn.asterisk.org/svn/asterisk/branches/1.6.2 :) |
| 20:20.12 | ajohnson | ok |
| 20:20.33 | ajohnson | if I'm going to be this bleading edge, I suppose I should have known better and just used SVN |
| 20:21.34 | Corydon76-dig | commit asterisk 194430 |
| 20:21.40 | MuffinMan | [194430] Committed by tilghman on 2009-05-14T16:22:14.220258Z: If the timing ended on a zero, then we would loop forever. |
| 20:21.40 | MuffinMan | ..(closes issue #14983) |
| 20:21.40 | MuffinMan | .. Reported by: teox |
| 20:21.40 | MuffinMan | .. Patches: |
| 20:21.41 | MuffinMan | .. 20090513__issue14983.diff.txt uploaded by tilghman (license 14) |
| 20:21.44 | MuffinMan | .. Tested by: teox |
| 20:21.46 | MuffinMan | .. |
| 20:21.48 | MuffinMan | .. http://svn.digium.com/view/asterisk?view=rev&revision=194430 |
| 20:22.36 | Corydon76-dig | ajohnson: that one |
| 20:22.41 | ajohnson | well the other part that I should fix is it appears sunday is considered the beginning of the week |
| 20:22.53 | ajohnson | so monday-sunday really isn't very valid |
| 20:23.15 | Corydon76-dig | Sure it is, but it would be better written as '*' |
| 20:23.50 | Corydon76-dig | by design, any day can be the beginning and any day can be the end |
| 20:25.04 | ajohnson | infinite loop would also explain why asterisk was consuming 400% CPU :) |
| 20:25.13 | Corydon76-dig | yah |
| 20:26.51 | eliel | it doesn't make sense to have OJBS+=say.o instead of adding it to the full list of OBJS... |
| 20:33.18 | *** join/#asterisk-dev bbryant1 (n=brett@c-68-59-21-152.hsd1.sc.comcast.net) |
| 20:33.18 | *** mode/#asterisk-dev [+o bbryant1] by ChanServ |
| 20:47.32 | philippel | putnopvut ping |
| 20:47.40 | putnopvut | philippel: pong |
| 20:47.48 | *** join/#asterisk-dev codefreeze-lap (n=murf@72.21.67.40) |
| 20:47.48 | *** mode/#asterisk-dev [+o codefreeze-lap] by ChanServ |
| 20:47.59 | philippel | are u using a device state callback in 1.4 and I just missed it? |
| 20:48.36 | putnopvut | Yes, look at the last statement in load_module before the return. |
| 20:48.42 | putnopvut | ast_devstate_add is the function call. |
| 20:48.45 | philippel | I was going to do the extension state callback but figured since every device was being seen here anyhow, I may as well check it (keep from getting the 'we don't care' debug message |
| 20:48.59 | philippel | ok - well shows how little I know about this code:( |
| 20:49.07 | putnopvut | Hey, you did an excellent job :) |
| 20:49.18 | philippel | since I had mentioned in the ticket using a callback would probably be the way to go... |
| 20:49.56 | philippel | thanks - it seems to work fairly reasonably with the version I have in the patch anyhow |
| 20:51.22 | philippel | now a 1.6 system to test on may delay me a bit, but maybe if I can get the patch changed over to use the callback it will be easy and someone else might be motivated to do the minor tweaks for 1.6 since I assume it will be largely similar |
| 20:53.03 | putnopvut | Yeah, I may (stress the word "may") have time this weekend to get around to it, since I really do think this is a good idea. |
| 20:54.01 | philippel | well I'll take a look at the callback change, not sure if I will be able to do it within the next few days or not, depends on how straight forward it looks liek when I have a peek |
| 20:56.38 | putnopvut | All right. Sorry I didn't get around to reviewing your code sooner. |
| 20:57.15 | philippel | putnopvut from a performance perspective though, if we are getting the callback every single device change already, might it not be more of a burdeon to subsribe to extension state changes as well |
| 20:57.51 | philippel | it's effectively redundant to do that as we will be checking twice each time a device state changes |
| 20:58.20 | philippel | well - actually I forgot, you subscribe on a per extnesion basis, scratch that maybe not a big deal |
| 20:59.02 | philippel | you only subscribe to the extension state for each member that has a hint so if it fires, you know it's for you... |
| 20:59.44 | putnopvut | That makes things a bit trickier, since you'll have to update the extension state subscription whenever the state_interface of a member changes. |
| 20:59.53 | putnopvut | But not too bad, though. |
| 21:02.16 | philippel | putnopvut actually that doesn't work subscribing to the extension_state callback |
| 21:02.59 | putnopvut | It doesn't? |
| 21:03.04 | philippel | here is the issue, if you subscribe to a non-existent hint at the time os subscription, it will fail. However, a subsequent reload of the dialplan may result in the hint being created |
| 21:03.54 | philippel | with the current method, it dynamically checks if there is a hint each time where as the other way, the callback would never have regiestered |
| 21:06.20 | putnopvut | ugh, subscribing to a non-existent hint fails? That sucks. |
| 21:06.42 | putnopvut | That sort of inflexibility is one reason why the event system in Asterisk trunk/1.6 kicks the ass of 1.4 |
| 21:07.13 | philippel | I'll have to take a closer look at it, haven't really looked into it at all on 1.6 |
| 21:07.28 | putnopvut | yeah, on 1.6, there is an ast_event API for subscribing to events. |
| 21:07.46 | philippel | yup - that would do it there for sure |
| 21:07.48 | putnopvut | And it is really flexible and cool. |
| 21:10.03 | JunK-Y | putnopvut: im replying to you now. |
| 21:19.03 | russellb | I wonder if we should have this discussion on the -dev list? |
| 21:19.07 | putnopvut | Proposal for all: Configuring with dev mode enabled should also by default enable DONT_OPTIMIZE, DEBUG_THREADS, and MALLOC_DEBUG. Thoughts? |
| 21:19.10 | russellb | putnopvut could resend his message there, and you could reply there ... |
| 21:19.29 | russellb | i meant to say that in #asterisk-gsoc, but ... |
| 21:19.30 | russellb | yeah. |
| 21:19.40 | russellb | putnopvut: I don't like it. |
| 21:19.47 | russellb | I intentionally have those off most of the time :-) |
| 21:19.56 | putnopvut | Why? |
| 21:20.28 | russellb | MALLOC_DEBUG hides crashes. I only enable it when I have a specific need for it. |
| 21:20.32 | russellb | DONT_OPTIMIZE and DEBUG_THREADS both significantly affect performance, and can change the timing of how things operate. |
| 21:20.39 | russellb | so again, I usually don't enable them unless I need it. |
| 21:22.33 | russellb | Another justification is that it seems like a good idea to do the majority of my testing with the same build options that almost every user would use |
| 21:22.45 | putnopvut | My problem is that I just had a deadlock occur and had no core show locks output available since I did not compile with that. That's what got me thinking, "Dev mode isn't used for performance, so why would a developer NOT want to have that enabled?" |
| 21:22.49 | putnopvut | You raise good points though. |
| 21:22.52 | putnopvut | About the timing of things. |
| 21:23.15 | russellb | I feel your pain ... |
| 21:23.29 | putnopvut | Luckily, I think this one might be easily reproducible. Rare for a deadlock. |
| 21:26.09 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 21:38.58 | jsmith | russellb: On the topic of module loading... |
| 21:39.02 | jsmith | russellb: Would it be worthwhile to set a module loading order in general? |
| 21:39.04 | jsmith | russellb: Something like channel drivers get loaded before applications, etc? |
| 21:39.50 | Qwell | jsmith: it is ordered :D |
| 21:40.05 | jsmith | Qwell: Since when, and how? |
| 21:40.25 | jsmith | Qwell: (and please don't tell me it's alphabetical!) |
| 21:40.38 | mnicholson | a blind transfer in sip is done with a refer correct? |
| 21:41.00 | russellb | with autoload, the order is mostly arbitrary |
| 21:41.05 | russellb | it's whatever readdir() returns to us |
| 21:41.14 | russellb | We move modules that export symbols to the front of the list, but that's it |
| 21:41.29 | russellb | To solve this problem, I really think forcing res modules to the front of the list works just fine |
| 21:41.29 | Qwell | oh, well then |
| 21:42.07 | jsmith | I think it should go something like res_*, chan_*, then everything else... |
| 21:42.39 | jsmith | (app_, func_, codec_, format_, etc.) |
| 21:42.40 | russellb | back in 1.2, it forced res, pbx, chan, everything else |
| 21:42.57 | jsmith | I think that's a valid ordering |
| 21:43.33 | jsmith | My favorite so-called feature is when app_queue gets loaded before chan_sip, so that the call queues list the member status as "unknown" |
| 21:44.15 | russellb | yeah ... |
| 21:44.29 | russellb | I don't like telling people that editing modules.conf is the "solution" to that |
| 21:45.10 | mnicholson | i think we should add dependencies to modules |
| 21:46.26 | russellb | That's an interesting idea. |
| 21:46.38 | Qwell | how would you read the dependency list? |
| 21:46.43 | russellb | We sort of have that information already in the menuselect-tree in XML form |
| 21:47.00 | russellb | However, in some cases, like in the case of this chan_iax2 bug, it's not a specific module, it's a class of modules |
| 21:47.12 | russellb | It's that we want all res_timing_*.so modules loaded first |
| 21:47.20 | russellb | so it gets a bit complicated ... |
| 21:47.24 | mnicholson | Qwell, you load the module, call a get_dependencies function |
| 21:47.30 | jsmith | Would loading res_*, then chan_* be a general enough solution? |
| 21:47.41 | Qwell | mnicholson: once you load the module, it's loaded |
| 21:47.43 | russellb | I mean, if we can solve all known problems, and not create new ones, by doing a trivial sort on the autoload order ... |
| 21:48.03 | russellb | Qwell: well, there are symbol deps, and runtime deps |
| 21:48.03 | jsmith | Or should we add explicit module ordering... where we might not (in theory) be able to order them |
| 21:48.04 | mnicholson | Qwell, i suppose that is true, if you resolve symbols at load time |
| 21:48.16 | russellb | symbol deps are already solved, we force mods that export symbols to load first today |
| 21:48.36 | Qwell | russellb: unless a module depends on another module that exports symbols |
| 21:48.44 | Qwell | 's head explodes |
| 21:48.47 | russellb | heh |
| 21:48.54 | russellb | let's not create imaginary problems to solve |
| 21:49.10 | mnicholson | russellb, does chan_iax2 require all res_timing*.so modules to be loaded? or does it just require a res_timing module? |
| 21:49.35 | russellb | Well ... any of them will do. However, it should be all of them, so that it uses the best one. |
| 21:50.44 | mnicholson | Qwell, the other option is to build a dependency file at build time, but that info would need to be stored some where. It is easier to just pull that info from the modules, and resolve symbols later. That leaves room for missing symbol runtime errors though. Maybe load the module once with out resolving symbols, grab deps, load again and resolve symbols. |
| 21:51.18 | mnicholson | russellb, how do you know when you are finished loading timing modules? you could only know for sure after you loaded every single module |
| 21:51.37 | mnicholson | (assuming a dependency based loading process) |
| 21:51.42 | russellb | or if you ensure all res modules get loaded first :-) |
| 21:51.56 | mnicholson | yeah, but that is so heavy handed... |
| 21:52.09 | russellb | do you have an example of why it's bad? |
| 21:52.33 | russellb | We have so many important things to do, I hate wasting time on over engineered solutions for the sake of theoretical elegance |
| 21:52.42 | russellb | If we have to do it, then I'm fine with it |
| 21:52.46 | russellb | but I want to be sure it's necessary :-) |
| 21:52.48 | mnicholson | no, it's not bad |
| 21:53.05 | mnicholson | it works fine, it's the quick and easy solution |
| 21:53.22 | mnicholson | it does not solve the problem of one res module depending on another though |
| 21:53.36 | mnicholson | I don't even know if that is a problem now though (or will ever be) |
| 21:53.48 | russellb | We don't have any instances of that today, except for something like res_config_odbc depending on res_odbc |
| 21:53.55 | russellb | but those cases have already been taken care of |
| 21:54.05 | mnicholson | how do we handle that today? |
| 21:54.10 | russellb | res_odbc exports symbols, so it gets loaded first |
| 21:54.16 | russellb | res_config_odbc does not |
| 21:55.11 | mnicholson | I agree this is not work spending time working on ATM, though I still think it would be a nice feature to have (to be implemented after all of the other nice features rolling around in my head) |
| 21:55.44 | russellb | I wouldn't turn such a thing down if it showed up :-) |
| 21:57.16 | mnicholson | actually the way it's done now is elegant enough I suppose |
| 21:59.54 | mnicholson | goes back to transfers |
| 22:03.37 | *** join/#asterisk-dev Octothorpe (n=Octothor@pdpc/supporter/professional/octothorpe) |
| 22:03.37 | *** join/#asterisk-dev qdk (n=qdk@81.7.168.130) |
| 22:03.37 | *** join/#asterisk-dev xpot (n=james@70.91.210.233) |
| 22:21.19 | *** join/#asterisk-dev brookshire (i=mbrooks@hijacked.us) |
| 23:05.24 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 23:05.24 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 23:23.19 | *** join/#asterisk-dev Greek-Boy (n=greek@41.222.89.77) |
| 23:24.24 | *** join/#asterisk-dev MikeJ_ (n=MikeJ@freeswitch/developer/mikej) |