| 00:09.57 | *** join/#asterisk-dev outtolunc (n=me@c-67-170-211-86.hsd1.ca.comcast.net) |
| 00:19.44 | *** join/#asterisk-dev IgorG (n=IgorG@host-90-188-188-119.pppoe.omsknet.ru) |
| 00:30.18 | *** join/#asterisk-dev uluatu (n=deg@189.58.8.179.adsl.gvt.net.br) |
| 00:39.49 | *** join/#asterisk-dev moy (n=moyhu@189.169.83.74) |
| 00:50.42 | *** join/#asterisk-dev mvanbaak (n=michiel@vanbaak.xs4all.nl) |
| 01:02.59 | *** join/#asterisk-dev uluatu (n=deg@189.58.8.179.adsl.gvt.net.br) |
| 01:18.55 | *** join/#asterisk-dev moy (n=moyhu@189.169.76.213) |
| 01:33.21 | *** join/#asterisk-dev IgorG (n=IgorG@195.162.49.23) |
| 01:41.55 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177583729.dsl.bell.ca) |
| 01:57.14 | Corydon76-dig | tis quiet |
| 01:57.45 | file | quite |
| 02:13.43 | Juggie | indeed |
| 02:20.33 | snuff-home | debates lookin @ unions on sparc again |
| 02:47.33 | *** join/#asterisk-dev uluatu (n=deg@189.58.8.179.adsl.gvt.net.br) |
| 03:01.57 | *** join/#asterisk-dev moy (n=moyhu@189.169.78.228) |
| 03:35.18 | *** join/#asterisk-dev sruffell (n=sruffell@68.159.134.239) |
| 03:35.18 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 04:03.25 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177583729.dsl.bell.ca) |
| 04:36.52 | *** join/#asterisk-dev denon (n=denon@tooth.decay.org) |
| 05:13.35 | *** part/#asterisk-dev sruffell (n=sruffell@68.159.134.239) |
| 05:51.06 | *** join/#asterisk-dev steliosk (n=Stelios@85.75.210.59) |
| 06:05.51 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 06:14.52 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 06:35.25 | *** join/#asterisk-dev obnauticus (n=obnautic@c-67-160-187-7.hsd1.wa.comcast.net) |
| 06:36.07 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 06:36.07 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:43.38 | awk | [May 16 08:12:25] WARNING[32515]: chan_zap.c:8713 pri_fixup_principle: Call specified, but not found? |
| 06:44.16 | awk | hmm I thought this was fixed ages ago, and can't believe it happens so often and is reponded as: <Most likely a simultaneous disconnect at both ends. No worries. |
| 06:50.44 | oej | Morning |
| 06:51.27 | awk | hey oej :) |
| 06:51.30 | awk | you up early |
| 06:52.18 | awk | oh sweden, not to early |
| 06:52.21 | oej | It's not that early here in Sweden |
| 06:52.23 | oej | :-) |
| 06:52.48 | awk | same time as south africa: 8:52? |
| 06:55.09 | oej | yep |
| 06:55.35 | oej | A tiny bit north of South Africa, but in the same time zone :-) |
| 06:56.09 | jmls_net | hey, only an hour ahead of ys |
| 06:56.13 | jmls_net | (us) |
| 06:56.22 | jmls_net | awk, where is SA ? |
| 06:56.46 | jmls_net | oh, thats us as in "us" not "USA" |
| 07:01.56 | awk | jmls_net yup :) |
| 07:04.39 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 07:04.39 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:06.18 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 07:06.18 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:07.56 | awk | anyone have a later version of this patch ? 10815-4.patch |
| 07:08.16 | oej | What's that? |
| 07:15.01 | awk | apply that patch to asterisk-addons and you get app_fax.so function.. as agx-ast doesn't work well on 1.4, everytime a fax comes into the box using app_rxfax it crashes asterisk and gets it to restart.. so I wanted to use app_fax.. but asterisk-addons doesn't compile when i patch it with 10815-4.patch. |
| 07:16.01 | awk | I know app_fax.c is intergrated into 1.6, but still using 1.4 :) |
| 09:01.09 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 09:18.35 | *** join/#asterisk-dev ChanServ (ChanServ@services.) |
| 09:18.35 | *** join/#asterisk-dev IgorG (n=IgorG@195.162.49.23) [NETSPLIT VICTIM] |
| 09:18.35 | *** join/#asterisk-dev _Vile (n=vile@208.100.152.234) [NETSPLIT VICTIM] |
| 09:18.35 | *** join/#asterisk-dev Daviey (n=dave@ubuntu/member/daviey) [NETSPLIT VICTIM] |
| 09:18.35 | *** mode/#asterisk-dev [+o ChanServ] by irc.freenode.net |
| 09:19.59 | *** join/#asterisk-dev ChanServ (ChanServ@services.) |
| 09:19.59 | *** mode/#asterisk-dev [+o ChanServ] by irc.freenode.net |
| 09:20.21 | *** join/#asterisk-dev janinge (i=j@ninge.net) |
| 09:24.06 | *** join/#asterisk-dev qdk (n=qdk@85.235.253.139) |
| 09:28.54 | *** join/#asterisk-dev RoyK (n=roy@fw.fortel.no) |
| 09:47.30 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 10:44.13 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 10:57.58 | *** join/#asterisk-dev IgorG (n=IgorG@195.162.60.35) |
| 11:27.20 | *** join/#asterisk-dev DagMoller (n=aguirre@unaffiliated/dagmoller) |
| 11:43.20 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 11:43.20 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 11:46.22 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 11:46.22 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:51.36 | *** join/#asterisk-dev DagMoller (n=aguirre@unaffiliated/dagmoller) |
| 11:59.11 | *** join/#asterisk-dev _ys (i=yuri@91.151.196.254) |
| 12:26.13 | *** join/#asterisk-dev IgorG (n=IgorG@host-90-188-188-119.pppoe.omsknet.ru) |
| 12:32.07 | _ys | Hello. Can someone answer me: in linux, one rwlock_t can be locked twice by one thread? |
| 12:32.42 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:33.00 | _ys | The results are undefined if the calling thread already holds the lock at |
| 12:33.01 | _ys | <PROTECTED> |
| 12:33.01 | _ys | <PROTECTED> |
| 12:33.18 | _ys | this i found in bsd man page |
| 12:38.27 | _ys | This moment prsent if __ast_context_destroy() lock context, and call to ast_context_remove_extension2() also lock this context. And my box is deadlocked.. |
| 12:55.03 | *** join/#asterisk-dev _Krieger_ (n=krieger@193.39.118.158) |
| 13:07.48 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177583729.dsl.bell.ca) |
| 13:32.21 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 13:42.14 | *** join/#asterisk-dev putnopvut (n=putnopvu@216.207.245.1) |
| 13:42.14 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:11.46 | *** join/#asterisk-dev snuff-home (i=snuff@60-240-117-7-nsw-pppoe.tpgi.com.au) |
| 14:21.39 | *** join/#asterisk-dev sruffell (n=sruffell@216.207.245.1) |
| 14:21.39 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:26.04 | oej | The channel was certainly silent this afternoon |
| 14:26.33 | putnopvut | Hello oej! |
| 14:26.40 | file | waves |
| 14:27.44 | oej | Hello friends! |
| 14:27.52 | oej | Holiday in the US? |
| 14:28.15 | putnopvut | No sir. |
| 14:28.38 | putnopvut | Although we do have one coming up two Mondays from now, I do believe. |
| 14:28.59 | sruffell | but according to google, today is the day of the first laser...so maybe some people are celebrating. |
| 14:29.14 | oej | first laser? |
| 14:29.41 | sruffell | "Invention of the first Laser" graphic on http://www.google.com |
| 14:29.46 | oej | Me and Russell needs to look at that blinking lamps stuff |
| 14:29.59 | sruffell | :) |
| 14:30.17 | oej | That's worth getting drunk for. |
| 14:30.28 | oej | Give me a large laserblaster with an umbrella, please |
| 14:30.46 | file | laserssss |
| 14:31.50 | oej | A lasercelebration muffin for the gentleman in Canada, sir. |
| 14:32.25 | file | lasers make everything better |
| 14:33.37 | oej | Absolutely. I use laser to get sunshine |
| 14:33.38 | oej | And I cut my hair with laser to get it smooth |
| 14:34.21 | putnopvut | I had a friend in college that convinced his dad that all the cool kids said "Laser!" to each other instead of "Later!" when they would part ways. |
| 14:35.02 | sruffell | hehe |
| 14:36.14 | oej | He was future-aware. We will soon all say "laser" instead of "later" |
| 14:37.45 | *** join/#asterisk-dev moy (n=moyhu@189.169.69.205) |
| 14:38.38 | oej | Someone in a company using subversion suggested to me that he should install and use rcs... |
| 14:39.25 | *** join/#asterisk-dev Cresl1n (n=matt@216.207.245.1) |
| 14:39.25 | *** mode/#asterisk-dev [+o Cresl1n] by ChanServ |
| 14:39.35 | file | hugs Cresl1n |
| 14:39.37 | ctooley | oej, I use rcs occasionally instead of SVN when I'm doing several small config to test something out. |
| 14:39.41 | ctooley | it's easier. :) |
| 14:39.52 | ctooley | but, on a broader scale, no way. |
| 14:40.00 | oej | This was on a broader scale... |
| 14:40.10 | oej | Hi Ctooley :-) |
| 14:40.10 | Cresl1n | Mornin file |
| 14:47.43 | *** join/#asterisk-dev uluatu (n=deg@200.195.161.164) |
| 14:50.13 | *** join/#asterisk-dev mog (n=mog@c-68-62-219-86.hsd1.al.comcast.net) |
| 14:50.13 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 14:59.22 | ctooley | Anyone got a link to an ISUP-OLI reference to show which line types are which? |
| 14:59.45 | Cresl1n | for what? |
| 15:00.09 | ctooley | found it: http://www.nanpa.com/number_resource_info/ani_ii_assignments.html |
| 15:00.32 | file | oh, ANI II |
| 15:00.36 | ctooley | Cresl1n, our calls come from a FGD network |
| 15:00.42 | Cresl1n | ah |
| 15:01.28 | ctooley | makes a difference for how we charge calls as we're required to charge for extra things like payphone fees. |
| 15:02.19 | ctooley | Code 25 isn't currently supported correctly in my code and I needed to know what kind of calls get translated to that. |
| 15:10.20 | ctooley | I had another idea about using ANI II for a setting in VoicemailMain(). A config file setting that lets the user turn on or off "quick-voicemail-mobile" for mobile phone calls which turns off things like the envelope playback and other optional prompts which an be retrieved manually in the event that the originating line is detected as a cell phone. |
| 15:11.45 | ctooley | obviously it wouldn't work for every call into the Asterisk for every channel type, but it could prevent minutes of cell phone time from being chewed up when someone calls into the PBX to check their messages. |
| 15:18.10 | Cresl1n | Or maybe you could pass it in as an argument to voicemailmain |
| 15:20.20 | ctooley | pass the ANI II in? |
| 15:21.20 | Cresl1n | well, check in dialplan if the ANI II is for a mobile number, and if so, pass in an argument to VoiceMailMain() (or another application) that would tell it to use the mobile friendly version |
| 15:21.56 | ctooley | So, just provide an option to VoiceMailMain() that if set always causes it to use "short mode" |
| 15:22.44 | Cresl1n | yeah, basically |
| 15:23.02 | Cresl1n | just so that it's not tied to some ANI II field that may or may not be set |
| 15:23.15 | Cresl1n | gives more control in the dialplan |
| 15:23.21 | ctooley | That would probably be more universally useful. Then it could be just a simple note saying that it's a handy thing if you want to check ANI II |
| 15:23.25 | ctooley | right. |
| 15:26.25 | *** join/#asterisk-dev joetester2 (n=joeteste@216.191.34.13) |
| 15:32.20 | *** part/#asterisk-dev joetester2 (n=joeteste@216.191.34.13) |
| 15:32.30 | *** join/#asterisk-dev joetester2 (n=joeteste@216.191.34.13) |
| 15:47.56 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.12.183) |
| 16:10.52 | *** join/#asterisk-dev smurf (n=smurf@debian/developer/smurf) |
| 16:25.24 | oej | have a nice weekend, friends! |
| 16:25.54 | Cresl1n | cya oej |
| 16:25.57 | Cresl1n | happy birthday :-) |
| 16:26.07 | ctooley | oej, happy birthday |
| 16:26.08 | jsmith | oej: It's your birthday? |
| 16:26.17 | Cresl1n | I think yesterday |
| 16:26.20 | jsmith | oej: Have a happy, joyous, (and relaxing) birthday! |
| 16:27.09 | Cresl1n | Grattis på födelsedagen |
| 16:28.26 | oej | Tack! |
| 16:28.31 | oej | Well, it was yesterday! |
| 16:28.52 | jsmith | throws a (virtual) party for oej |
| 16:28.54 | oej | Thanks to all of you! |
| 16:29.09 | oej | leaves for the virtual party in Jsmith's yard. |
| 16:29.23 | ctooley | wishes he had a yard again. :( |
| 16:29.54 | jsmith | oej: I even mowed the lawn, just for your party |
| 16:30.04 | jsmith | oej: I'll break out the hammacks just as soon as you show up |
| 16:30.11 | oej | :-) |
| 16:30.17 | file | oej: happy day of birth! |
| 16:30.18 | oej | By now, gotta eat dinner. |
| 16:30.45 | Cresl1n | swedish fish? |
| 16:30.46 | Cresl1n | <PROTECTED> |
| 16:30.49 | jsmith | oej: Eat and extra piece of cake for me! |
| 16:30.53 | jsmith | s/and/an/ |
| 16:34.31 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.143.86) |
| 16:38.54 | *** join/#asterisk-dev qdk (n=qdk@0x573fe57e.bynqu2.broadband.tele.dk) |
| 16:39.59 | Corydon76-dig | oej: Hippo birdie two ewe |
| 16:40.37 | *** join/#asterisk-dev hugorebelo (n=hugorebe@200-171-132-124.completo.com.br) |
| 16:45.19 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 16:45.19 | *** join/#asterisk-dev km- (n=pgrace@aeneas.fierymoon.com) [NETSPLIT VICTIM] |
| 16:45.19 | *** join/#asterisk-dev pgarcia (n=pedgarci@yoda.kanatek.com) [NETSPLIT VICTIM] |
| 16:45.19 | *** mode/#asterisk-dev [+o oej] by irc.freenode.net |
| 16:53.37 | mvanbaak | oej: happy belated bday ! |
| 16:56.17 | caio1982 | is there a way to detect wether a given channel type is actually registered or not by querying its string name? |
| 16:56.47 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 16:57.02 | Corydon76-dig | caio1982: you can, on its module name |
| 16:57.19 | caio1982 | hmmm |
| 16:57.25 | Corydon76-dig | ast_module("chan_sip.so") will return NULL if the module is not loaded |
| 16:58.20 | Corydon76-dig | or not NULL if it is |
| 16:59.24 | caio1982 | maybe you have a better idea on it, so here is the problem: both chan_console and chan_oss register themselvs as type 'Console', thus they conflict with each other and it's even possible to crash asterisk having both loaded at same time |
| 16:59.24 | caio1982 | Corydon76-dig: that's why i asked :-) |
| 16:59.46 | caio1982 | but i guess looking for the module name would not be the right way, yes? |
| 16:59.55 | Corydon76-dig | No, it wouldn't |
| 17:00.24 | caio1982 | just changing chan_oss type name would be faster :P |
| 17:01.02 | Corydon76-dig | caio1982: there is another way, but it's kind of a hack |
| 17:01.19 | Corydon76-dig | If you create your own ast_channel_tech and attempt to register it |
| 17:01.35 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 17:01.36 | *** join/#asterisk-dev km- (n=pgrace@aeneas.fierymoon.com) [NETSPLIT VICTIM] |
| 17:01.36 | *** join/#asterisk-dev pgarcia (n=pedgarci@yoda.kanatek.com) [NETSPLIT VICTIM] |
| 17:01.36 | *** mode/#asterisk-dev [+o oej] by irc.freenode.net |
| 17:01.36 | Corydon76-dig | it will fail if the channel type already exists |
| 17:01.45 | *** join/#asterisk-dev hugorebelo (n=hugorebe@200-171-132-124.completo.com.br) |
| 17:02.06 | Corydon76-dig | Just be sure to unregister it if it succeeds before proceeding |
| 17:02.36 | jpeeler | oej: ping |
| 17:03.06 | Corydon76-dig | caio1982: oh, wait, here it is: ast_get_channel_tech("Console") |
| 17:03.25 | caio1982 | _get_! yeah |
| 17:03.33 | caio1982 | Corydon76-dig: thanks, gonna try it :) |
| 17:11.00 | seanbright | so is the channels/xpmr code off-limits to mere mortals? |
| 17:11.54 | seanbright | the formatting is god-awful, so i was going to clean it up |
| 17:12.04 | seanbright | but it looks like there is a dedicated maintainer |
| 17:12.15 | Corydon76-dig | seanbright: go for it |
| 17:12.26 | seanbright | m'kay |
| 17:12.46 | Corydon76-dig | seanbright: are you looking for random things to do? |
| 17:12.52 | seanbright | not at the moment, no. |
| 17:13.08 | Corydon76-dig | I'm getting very close to done on a particular branch for realtime |
| 17:13.10 | seanbright | was trying to bring a branch up to snuff and ran into conflicts in those files |
| 17:13.20 | Corydon76-dig | Ah |
| 17:13.55 | Corydon76-dig | Wouldn't it be loverly if you were missing a realtime column, and it just worked without it? |
| 17:14.06 | Corydon76-dig | and/or warned you |
| 17:14.13 | seanbright | that it would |
| 17:14.15 | Corydon76-dig | and/or changed your table to match |
| 17:14.18 | seanbright | ohhh |
| 17:14.37 | Corydon76-dig | The ODBC backend doesn't, but the postgres one will. |
| 17:14.49 | Corydon76-dig | change your table, that is |
| 17:15.10 | seanbright | well you might have a security problem if your reader/writer user had alter privileges |
| 17:15.14 | Corydon76-dig | I'm still working on getting all the warnings done |
| 17:15.35 | Corydon76-dig | seanbright: it's optional, from the config, and it defaults to not do it |
| 17:15.45 | seanbright | Corydon76-dig: gotcha. cool. |
| 17:15.53 | Corydon76-dig | That's one of the backends I have yet to test |
| 17:16.29 | *** join/#asterisk-dev uluatu (n=deg@200.195.161.164) |
| 17:17.44 | seanbright | err, umm... hrmmm |
| 17:18.19 | seanbright | should a module ever call exit()? |
| 17:18.25 | Corydon76-dig | No, never |
| 17:18.35 | seanbright | alrighty. |
| 17:18.44 | Corydon76-dig | Even something which forks, the child should only ever call _exit() |
| 17:41.00 | *** join/#asterisk-dev asteriskmonkey (n=philip@137.122.72.219) |
| 18:15.22 | tzanger | Cresl1n: ping |
| 18:18.08 | *** join/#asterisk-dev joetester2 (n=joeteste@216.191.34.13) |
| 18:21.23 | *** join/#asterisk-dev steliosk (n=Stelios@athedsl-284816.home.otenet.gr) |
| 18:24.44 | file | this internet thing will never catch on |
| 18:25.10 | mvanbaak | internet is overrated |
| 18:26.22 | putnopvut | What is an internet? |
| 18:30.15 | jsmith | putnopvut: It's a tube... you put things like email in it. |
| 18:30.26 | jsmith | putnopvut: But you have to be careful not to plug the tubes. |
| 18:32.06 | *** join/#asterisk-dev shido6 (n=shido6@209.114.208.192) |
| 18:32.25 | shido6 | when forwarding a message I want the person who sent it to me not the original sender, so if Tom sends a message to Jill and Jill forwards the mesage to mike and tommy and bob and prepends the message with, |
| 18:32.36 | shido6 | This guy is a aucking f$$hole" and bob and tommy reply I do not want their reply of , "yeah he is aucking f$$hole" to go to the aucking f$$hole in question, which in this case is Tom. |
| 18:32.43 | shido6 | Make sense? So in app_voicemail.c vm_forwardoptions what should I change? Or am I looking in the wrong spot? |
| 18:33.53 | shido6 | forward_message is where I want to make the change |
| 18:41.53 | shido6 | sender is correct |
| 18:41.57 | shido6 | but i want the immediate sender |
| 18:42.00 | shido6 | not the original sender |
| 18:42.01 | shido6 | ;) |
| 18:44.49 | caio1982 | M12668 |
| 18:44.52 | MuffinMan | [new] [Asterisk] Channels/chan_oss 0012668: [patch] fix module loading of chan_oss when you already got chan_console loaded (channel type conflict) reported by caio1982 (Karma: +31.25) http://bugs.digium.com/view.php?id=12668 |
| 18:45.12 | caio1982 | Corydon76-dig: i found it easier than using ast_get_channel_tech, is that solution okay? |
| 18:52.49 | Corydon76-dig | caio1982: that doesn't make any sense |
| 18:52.56 | caio1982 | ouch |
| 18:52.58 | Corydon76-dig | Why unregister if register failed? |
| 18:53.26 | Corydon76-dig | Your code isn't really checking anything |
| 18:53.52 | Corydon76-dig | You added some unnecessary stuff, but that's it. |
| 18:53.53 | caio1982 | that's what chan_console does when it fails, I assumed it was the right way to go |
| 18:54.16 | Corydon76-dig | Not that way it doesn't |
| 18:55.01 | Corydon76-dig | There should NEVER be an unregistration for the last thing that registers in a module, because the registration never happened |
| 18:55.52 | Corydon76-dig | If you reread the chan_console code, you'll find that if the last register fails, then it unregisters the SECOND-TO-LAST thing (which succeeded) |
| 18:56.03 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 18:56.18 | caio1982 | thinks about it for a moment |
| 18:56.52 | Corydon76-dig | On failure, you only unregister things whose registration succeeded |
| 18:57.50 | Corydon76-dig | And I don't see how your patch adds anything that wasn't already there. In fact, it makes it LESS clean, because you had to use several goto's to accomplish the same thing |
| 18:59.54 | caio1982 | so the only effective change would be or checking it with ast_get_channel_tech(...) or just changing AST_MODULE_LOAD_FAILURE to AST_MODULE_LOAD_DECLINE, the rest being superfluous? |
| 19:00.43 | Corydon76-dig | Correct |
| 19:07.42 | *** join/#asterisk-dev denon (n=denon@tooth.decay.org) |
| 19:07.47 | caio1982 | ok, added a comment to the bug ticket about it |
| 19:08.23 | caio1982 | Corydon76-dig: thanks for the obvious mistake on that patch, i guess i overcorrected it |
| 19:08.33 | caio1982 | i mean, for pointing it out |
| 19:08.34 | caio1982 | :P |
| 19:12.16 | caio1982 | hmmm both svn and bugs server are too slow here |
| 19:13.05 | file | yeah... |
| 19:13.07 | file | working on it |
| 19:15.25 | caio1982 | :) |
| 19:25.32 | file | should be better now |
| 19:26.03 | file | well, as soon as these connections drop... |
| 19:33.42 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 19:33.42 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 19:34.02 | Corydon76-dig | tackles russellb |
| 19:34.52 | russellb | Corydon76-dig: !!! |
| 19:35.03 | Corydon76-dig | How was training? |
| 19:35.08 | russellb | still in training |
| 19:35.09 | russellb | on break |
| 19:35.14 | Corydon76-dig | Ah |
| 19:35.24 | russellb | trying to think of what to give my next 10 minute presentation on |
| 19:35.45 | Corydon76-dig | oooo, interactive training |
| 19:35.51 | russellb | maybe I'll explain ... DUNDi in 10 minutes ... on the spot |
| 19:37.23 | putnopvut | Does it have to be Asterisk-related? |
| 19:37.30 | russellb | supposed to be work related, yeah |
| 19:37.48 | putnopvut | oh :( |
| 19:38.19 | russellb | how goes asterisk-dev land |
| 19:38.37 | putnopvut | Good. I'm wrapping my head around the intricacies of chan_sip's weird flags. |
| 19:38.57 | russellb | sounds ..... exciting |
| 19:39.31 | Corydon76-dig | adaptive_realtime is getting close to merge time |
| 19:39.36 | putnopvut | yay! |
| 19:39.54 | russellb | uh oh, the time is near |
| 19:39.57 | Corydon76-dig | with 2 supported backends |
| 19:40.08 | Corydon76-dig | Maybe 3, if I do addons |
| 19:40.40 | putnopvut | Which backends are supported currently? |
| 19:40.55 | Corydon76-dig | odbc and postgres |
| 19:41.05 | Corydon76-dig | odbc is tested. postgres is still in the process |
| 19:41.44 | Corydon76-dig | and postgres is one that will alter tables, if you let it |
| 19:42.10 | Corydon76-dig | exciting, eh? |
| 19:42.20 | putnopvut | It is, actually. |
| 19:42.35 | putnopvut | What third backend were you contemplating? mysql? sqlite? |
| 19:42.50 | Corydon76-dig | mysql, since I know it pretty well |
| 19:43.21 | Corydon76-dig | While monkeying with postgres, I've come to realize just how good the odbc backend is compared to the native drivers |
| 19:43.38 | russellb | any bugs getting fixed? :) |
| 19:44.08 | seanbright | bugs? fixed? that's crazy talk. |
| 19:44.11 | Corydon76-dig | In release or in my testing? |
| 19:44.21 | Corydon76-dig | In my testing, yes, found a bunch |
| 19:44.35 | Corydon76-dig | s/testing/branch/ |
| 19:46.05 | file | waves to russellb |
| 19:46.37 | russellb | hides |
| 19:47.54 | *** join/#asterisk-dev jtodd (n=jtodd@blob.fox-den.com) |
| 19:55.12 | *** join/#asterisk-dev shido6 (n=shido6@209.114.208.192) |
| 19:56.37 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 20:01.32 | *** join/#asterisk-dev uluatu (n=deg@mail.ondacorp.com.br) |
| 20:10.04 | *** part/#asterisk-dev jmls_net (n=asterisk@host217-36-208-155.in-addr.btopenworld.com) |
| 20:10.50 | *** join/#asterisk-dev jmls_net (n=asterisk@host217-36-208-155.in-addr.btopenworld.com) |
| 20:15.59 | *** join/#asterisk-dev outtolunc (n=me@c-67-170-211-86.hsd1.ca.comcast.net) |
| 20:25.44 | *** part/#asterisk-dev pgarcia (n=pedgarci@yoda.kanatek.com) |
| 20:31.03 | ctooley | kpfleming, you around? |
| 20:31.26 | ctooley | We discussed this a while back so I'm just trying to confirm that I'm correct in the understanding. |
| 20:31.27 | kpfleming | no, i am not here :-) |
| 20:31.36 | kpfleming | or maybe i am, hard to tell |
| 20:31.44 | file | don't believe him |
| 20:31.54 | Corydon76-dig | Schroedinger's Kevin |
| 20:31.59 | ctooley | In the effort to eliminate the need for a DeadExternalIVR I need to be able to pass in an option to ExternalIVR to tell it not to answer a call. |
| 20:32.26 | Corydon76-dig | 'n'! |
| 20:32.41 | ctooley | I seem to remember that we decided to use a ^ to denote that we're passing in ExternalIVR() options and not arguments the command ExternalIVR is executing. |
| 20:33.25 | ctooley | Corydon76-dig, That's not the issue. ExternalIVR(/usr/bin/foo,arg1,arg2) means that we need to execute "/usr/bin/foo arg1 arg1" |
| 20:33.26 | kpfleming | yeah, because it has to be different somehow |
| 20:33.42 | kpfleming | unfortunately this would be backwards of other applications that already do it |
| 20:34.18 | kpfleming | but yes, putting options as the first argument, separated by ^ from the command to run, should work |
| 20:34.25 | ctooley | kpfleming, and unfortunately I didn't get it done in time for 1.6.0 so breaking backwards compatibility would be bad. |
| 20:34.40 | kpfleming | yep |
| 20:34.47 | ctooley | first or optionally at the end? |
| 20:34.48 | Corydon76-dig | There is another option... |
| 20:34.57 | kpfleming | i would place it first, to be honest |
| 20:35.06 | kpfleming | since the app already takes a variable number of arguments |
| 20:35.11 | Corydon76-dig | ExternalIVR(^<options>,app,arg1,arg2...) |
| 20:35.38 | Corydon76-dig | like that? |
| 20:35.57 | ctooley | ([^<options>,]app,arg1,arg2) |
| 20:36.00 | kpfleming | no |
| 20:36.17 | kpfleming | ExternalIVR([options^]app,arg1,arg2) |
| 20:36.27 | ctooley | I like kpfleming's better |
| 20:36.29 | ctooley | :) |
| 20:36.53 | Corydon76-dig | I was thinking about it from the parsing side ;-) |
| 20:37.04 | ctooley | and if app or an arg has a ^... well.... that seems broken to begin with. :) |
| 20:37.06 | Corydon76-dig | but whatever |
| 20:37.52 | ctooley | buries his head in 1.6's chan_sip. |
| 20:37.52 | Corydon76-dig | Instead of searching within, you just say "If the first argument starts with a '^', then it contains options. |
| 20:38.15 | Corydon76-dig | since commands can't start with a ^ |
| 20:38.17 | ctooley | hmmm it would be simpler. |
| 20:38.31 | kpfleming | slightly more efficient, but seems a little counterintuitive syntax-wise |
| 20:38.53 | Corydon76-dig | Alternatively, ExternalIVR2(...) |
| 20:39.10 | ctooley | Corydon76-dig, that was another option. :) |
| 20:39.20 | Corydon76-dig | and ask people to please transition to whatever syntax that is more obvious |
| 20:39.26 | ctooley | but, it seems less elegant |
| 20:39.56 | Corydon76-dig | I have a dislike of anything that uses alternative argument separators |
| 20:40.06 | Corydon76-dig | because that bites you later |
| 20:40.44 | ctooley | ExternalIVR2(app^arg1^arg2[,options])? |
| 20:40.51 | Corydon76-dig | but I'm just giving an opinion, since all things are equally horrible |
| 20:41.00 | ctooley | or the opposite? |
| 20:41.03 | Corydon76-dig | Ewww |
| 20:41.33 | Corydon76-dig | Actually, what I would do is ExternalIVR2(app(arg1,arg2,...),options) |
| 20:41.46 | Corydon76-dig | kind of like how app_exec works in 1.6 |
| 20:41.59 | ctooley | hmmm ok |
| 20:42.27 | Corydon76-dig | gives great grouping, not ambiguous at all, and follows the convention of having options last |
| 20:42.33 | ctooley | feels the de ja vu of this discussion having happened months ago. :) |
| 20:43.48 | kpfleming | yes |
| 20:43.57 | ctooley | kpfleming, ExternalIVR2(app(arg1,arg2,...),options) or ExternalIVR([options^]app,arg1,arg2)? |
| 20:44.02 | kpfleming | we like to talk about it, then not implement it, then talk about it again :-) |
| 20:44.24 | kpfleming | umm... do we have a parser that handles style #1 all by itself? |
| 20:44.46 | ctooley | sorry, I've gotten permission to get back to the task. At least the last time I was able to submit so patches, hopefully this time will complete the job. |
| 20:45.49 | Corydon76-dig | kpfleming: not yet, I don't think |
| 20:45.57 | ctooley | app_exec uses that format? |
| 20:46.07 | Corydon76-dig | ctooley: in 1.6, yes |
| 20:46.15 | Corydon76-dig | and trunk, for that matter |
| 20:46.17 | kpfleming | how does it parse that then? look for the last comma? |
| 20:46.40 | file | January 24th. |
| 20:46.45 | Corydon76-dig | kpfleming: anything within parentheses is considered to be part of a single argument |
| 20:46.57 | kpfleming | by what? |
| 20:47.03 | kpfleming | file: eh? |
| 20:47.07 | *** join/#asterisk-dev uluatu (n=deg@mail.ondacorp.com.br) |
| 20:47.16 | file | that was the day you talked about it. |
| 20:47.18 | Corydon76-dig | So the standard parser handles the separation of the app from options, but you need to parse the app from the arguments separately |
| 20:47.47 | Corydon76-dig | i.e. there's nothing that removes the parentheses right now |
| 20:48.00 | kpfleming | ahh, i didn't realize it treated parentheses pairs in argument specially |
| 20:48.15 | file | Corydon76-dig: nifty |
| 20:48.19 | Corydon76-dig | Yes, it even handles embedded parentheses correctly |
| 20:48.39 | Corydon76-dig | as long as the embedded ones are balanced, that is |
| 20:49.00 | jsmith | ExternalIVR(one(two),three(four(five)),^six) |
| 20:49.19 | jsmith | adds fuel to the fire |
| 20:49.23 | ctooley | Corydon76-dig, So, I could strip the parens and run it through ast_parse_args_standard again and get the argument list? |
| 20:49.30 | kpfleming | right |
| 20:49.37 | jsmith | ctooley: Exactly |
| 20:49.42 | Corydon76-dig | ctooley: yes, but use the AST_STANDARD_APP_ARGS() macro, please |
| 20:50.08 | kpfleming | which would be backwards compatible, since a bare command name could never contain parenthesis |
| 20:50.12 | ctooley | sure, I didn't remember which it was but I'd have used it. |
| 20:51.06 | Corydon76-dig | kpfleming: you're right, we could handle that in a backwards compatible way... |
| 20:51.14 | ctooley | uhhh? |
| 20:51.53 | Corydon76-dig | i.e. if we use parentheses in the app argument, then the arguments are contained there, and the options are afterwards, otherwise the arguments are afterwards, and there are no options |
| 20:52.09 | ctooley | oh, duh. |
| 20:52.22 | Corydon76-dig | Awesome. |
| 20:52.22 | ctooley | that makes sense |
| 20:52.32 | ctooley | Ok, so no need for ExternalIVR2 |
| 20:52.37 | Corydon76-dig | Right |
| 20:52.51 | ctooley | OK, just to make sure (because obviously I'm an idiot): |
| 20:53.10 | Corydon76-dig | I love it when a plan comes together. |
| 20:53.22 | ctooley | ExternalIVR(arg1,arg2,arg3,...) means arg1 is the app and the rest are arguments to the app |
| 20:54.11 | ctooley | ExternalIVR(arg1(arg2,arg3,...),argX) means arg1 is the app, everything in the () are arguments to the app, and argX are options to ExternalIVR() |
| 20:54.43 | Corydon76-dig | Right |
| 20:55.54 | ctooley | OK then. |
| 20:56.23 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 20:57.16 | kpfleming | file: you and your crash avoidance techniques |
| 20:59.21 | file | adds Europe avoidance techniques |
| 20:59.26 | file | now you can't go! |
| 21:08.36 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.139) |
| 21:15.24 | ctooley | It's kinda funny, my 1.4 version of ExternalIVR diff's a lot cleaner against trunk than it does against 1.4.19.1 |
| 21:32.18 | jsmith | ctooley: That's a good thing! |
| 21:32.33 | jsmith | prepares to sign off for the day and play "Mr. Mechanic" |
| 21:33.56 | ctooley | jsmith, yeah, it means some of this stuff has been somewhat tested. :) |
| 21:34.37 | jsmith | ctooley: Testing is always good. |
| 21:34.52 | jsmith | wishes he could spend the weekend coding instead of trying to fix a car |
| 21:38.43 | snuff-home | mm anyone noticed when u select 'all projects' in mantis the formatting changes (table for list of bugs is fatter) vs when just selecting 'asterisk'? |
| 21:38.43 | ctooley | gets to spend the weekend shoveling rock and dirt into a hole in the yard because the loader broke down. |
| 21:41.11 | snuff-home | ah ha.. i figured it out.. silly me forgot that a 'tag' is added to the category bit.. |
| 21:42.10 | jpeeler | is there a way to somehow use gdb to see how much stack space is available? |
| 21:43.10 | Corydon76-dig | I don't believe so, no |
| 21:43.39 | jpeeler | hmm, any way to check if stack space is causing a bug? |
| 21:44.00 | Corydon76-dig | How many stack frames is it using? |
| 21:44.19 | Corydon76-dig | What bug number is this? |
| 21:44.47 | jpeeler | 10 i believe, but it is using LOW_MEMORY |
| 21:45.05 | jpeeler | M11594 |
| 21:45.08 | MuffinMan | [assigned] [Asterisk] Channels/chan_zap 0011594: Asterisk dies on chan_zap reload reported by yem (Karma: neutral) http://bugs.digium.com/view.php?id=11594 |
| 21:45.29 | jpeeler | i've found the exact point the code crashes and it doesn't make any sense |
| 21:45.49 | Corydon76-dig | Right, so 48k stack, instead of 240k stack |
| 21:46.12 | Corydon76-dig | or wait, that's only for background threads |
| 21:47.17 | jpeeler | it's crashing here: sprintf(linestr, "%d", line); this is from 1.4.19.2 in logger.c:ast_log |
| 21:47.41 | jpeeler | works fine without LOW_MEMORY |
| 21:48.03 | Corydon76-dig | What thread is running? |
| 21:49.08 | Corydon76-dig | i.e. where is it being called from? |
| 21:49.28 | jpeeler | how far up do you want? |
| 21:49.39 | Corydon76-dig | just below the _clone |
| 21:49.50 | Corydon76-dig | or above, really |
| 21:50.11 | Corydon76-dig | or pastebin it |
| 21:50.13 | jpeeler | well i've been confused about that |
| 21:50.28 | jpeeler | let me get it to right before the crash |
| 21:51.48 | jpeeler | how do i make it not expand all the structs in the bt? |
| 21:52.05 | Corydon76-dig | Just 'bt', not 'bt full' |
| 21:52.14 | jpeeler | i am doing just bt |
| 21:52.27 | Corydon76-dig | Show me |
| 21:52.28 | jpeeler | i'll just paste the whole thing |
| 21:54.13 | jpeeler | http://pastebin.com/d3a108298 |
| 21:56.06 | Corydon76-dig | Hah! A 64-bit machine using LOW_MEMORY? |
| 21:56.20 | Corydon76-dig | I'd wager that's why |
| 21:56.50 | Corydon76-dig | Every pointer on the stack is double in size, and we probably haven't tested that |
| 21:58.17 | jpeeler | so is it just unsupported for 64-bit? |
| 21:58.36 | jsmith | 64-bit machine using LOW_MEMORY... wow... |
| 21:58.48 | jsmith | Obviously not used by too many people |
| 21:59.00 | Corydon76-dig | We could probably detect that and give it more stack space |
| 21:59.44 | Corydon76-dig | jpeeler: in utils.h, change the definition of AST_BACKGROUND_STACKSIZE from "48..." to "80..." and try again |
| 21:59.52 | jpeeler | i have to use LOW_MEMORY for this bug, although it does like they were on a 32-bit platform |
| 22:00.08 | Corydon76-dig | If the crash goes away, that's the problem |
| 22:00.14 | putnopvut | Wow...why is the entire struct being passed in those function calls? |
| 22:00.28 | Corydon76-dig | putnopvut: it's not... |
| 22:00.38 | putnopvut | Okay, a copy of the struct. |
| 22:00.55 | putnopvut | I think a pointer should be used instead. |
| 22:01.27 | putnopvut | I mean, just look a that backtrace. |
| 22:01.47 | *** join/#asterisk-dev RoyK (n=roy@ti0034a380-3704.bb.online.no) |
| 22:02.07 | jsmith | putnopvut: Yeah... nobody ever heard of call by reference? |
| 22:02.10 | jpeeler | yay chan_zap |
| 22:02.39 | Corydon76-dig | putnopvut: that's a very good question, actually |
| 22:02.43 | putnopvut | jsmith: yeah, that's what I'm thinking. And if it's just an input param, make it const. |
| 22:03.02 | jsmith | putnopvut: Well, I obviously don't know the API, but it stood out at me |
| 22:03.07 | Corydon76-dig | putnopvut: it's being altered within |
| 22:03.21 | jsmith | putnopvut: (That being said, I was too timid to say anything myself, as I didn't wanna sound stupid) |
| 22:03.22 | putnopvut | Okay, then a non-const pointer should do the job just fine. |
| 22:04.08 | Corydon76-dig | We need to ask someone who knows chan_zap better (like the other Mark) |
| 22:04.25 | jsmith | Or sruffell, or Cresl1n |
| 22:04.36 | jpeeler | Corydon76-dig: that does solve the problem, which in this case make me sad as i thought i had reproduced the bug |
| 22:04.49 | putnopvut | jpeeler: you very well might have. |
| 22:05.14 | jpeeler | is LOW_MEMORY used commonly on 32-bit? |
| 22:06.02 | putnopvut | jpeeler: I can't answer that accurately. |
| 22:06.05 | file | not... really |
| 22:06.47 | Corydon76-dig | the AA50? |
| 22:06.52 | jpeeler | do i need to create a 32-bit virtual machine and test? |
| 22:07.02 | Corydon76-dig | I think you do |
| 22:07.09 | putnopvut | jpeeler: I have a 32-bit machine you can try using. |
| 22:07.19 | jpeeler | yay for less work |
| 22:07.30 | putnopvut | But it has no OS on it so it would probably be just as much time to put one on there than to create a VM. |
| 22:07.42 | Corydon76-dig | jpeeler: just download a 32-bit VM from the vmware site |
| 22:07.43 | putnopvut | But feel free to use it if you'd like. |
| 22:08.00 | jpeeler | oh |
| 22:08.11 | jpeeler | well i do have an iso sitting right here, wonder how long the download would take... |
| 22:08.17 | file | hopefully not long |
| 22:08.17 | jpeeler | of the vm i mean |
| 22:08.44 | jpeeler | Corydon76-dig: so does that change just prove that LOW_MEMORY needs more testing or should that be added for 64-bit? |
| 22:08.51 | Corydon76-dig | If there's already one on cork, you could just copy the files |
| 22:09.26 | Corydon76-dig | jpeeler: an excellent question |
| 22:10.56 | Corydon76-dig | jpeeler: I think it shows that LOW_MEMORY has only ever been considered for 32-bit machines, and I don't know if we should even fix it for 64-bit until we have a case for that |
| 22:11.40 | Corydon76-dig | because it's just a stab in the dark, until we know for what sized memory we're trying to make thread stack fit |
| 22:12.08 | jpeeler | what exactly does LOW_MEMORY do? |
| 22:12.22 | Corydon76-dig | It causes the background threads to take less space |
| 22:12.39 | Corydon76-dig | and various other things that reduce memory usage |
| 22:13.11 | Corydon76-dig | Generally, we use memory to make the process fast, but on certain platforms, we don't have gobs of memory, which is the reason for that parameter |
| 22:13.35 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 22:13.35 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 22:14.02 | Corydon76-dig | Note that the -O parameter for gcc, the higher the number of optimization, the bigger the executable, because the compiler optimizes for execution time |
| 22:14.06 | jpeeler | how does one determine the optimum memory constraint? |
| 22:14.30 | Corydon76-dig | which expands certain things, by creating tables where we don't need to do recalculations |
| 22:14.58 | Corydon76-dig | jpeeler: trial and error, really |
| 22:15.37 | Corydon76-dig | I'm sure whoever settled on 48k tried 32k and ran out of stack on certain tasks |
| 22:16.00 | jpeeler | there must be some "official" way of calculating it |
| 22:16.32 | Corydon76-dig | Honestly, there are so many code paths, that it's actually faster to do trial-and-error |
| 22:17.30 | Corydon76-dig | You're basically just looking for a standard code path that takes the most memory |
| 22:17.40 | Corydon76-dig | err, most stack memory |
| 22:18.12 | Corydon76-dig | Once you find that, you trial-and-error with various stack sizes |
| 22:18.42 | Corydon76-dig | The problem with adding up expected sizes is that the compiler sometimes expands and contracts how much it actually uses for optimal performance |
| 22:19.13 | jpeeler | i see |
| 22:19.32 | Corydon76-dig | So sometimes something may wind up in a register instead of on the stack, and sometimes the compiler pads each parameter to be at a word boundary |
| 22:19.56 | jpeeler | well if things aren't predictable, that makes predictions hard |
| 22:20.01 | jpeeler | (obviously) |
| 22:20.08 | Corydon76-dig | and what's even more fun, the word boundaries differ on some platforms |
| 22:20.23 | snuff-home | go sparc |
| 22:20.48 | snuff-home | thou shalt not do unaligned memory accesses |
| 22:20.57 | Corydon76-dig | Right, sparc is the most germane example, although powerpc does that, too |
| 22:22.29 | Corydon76-dig | jpeeler: rehashing stuff you learned in sophomore year? ;-) |
| 22:22.55 | jpeeler | heh, that would be CS people's sophomore year, we learned about circuits |
| 22:23.05 | Corydon76-dig | Ah, heh |
| 22:23.16 | jpeeler | although i guess there was some assembly |
| 22:23.25 | Corydon76-dig | Didn't realize you were Comp Eng, not CS |
| 22:27.29 | jpeeler | yep :) for better or for worse |
| 22:35.22 | *** join/#asterisk-dev RoyK (n=roy@ip-122-19-149-91.dialup.ice.no) |
| 22:50.23 | seanbright | Corydon76-dig: i'm getting reimbursed the full cost of my transmission repair :) |
| 22:55.40 | Corydon76-dig | Oh? |
| 22:57.41 | seanbright | yup |
| 22:59.37 | *** part/#asterisk-dev mog (n=mog@c-68-62-219-86.hsd1.al.comcast.net) |
| 23:28.00 | jpeeler | Corydon76-dig: still around? |
| 23:33.41 | jpeeler | i'm hoping that running a 32-bit OS on a 64-bit machine will suffice... |
| 23:37.09 | *** join/#asterisk-dev uluatu (n=deg@189.58.6.78.adsl.gvt.net.br) |
| 23:42.37 | *** join/#asterisk-dev anthm (n=anthm@mbc0736d0.tmodns.net) |