| 02:23.23 | *** join/#asterisk-dev eliel (n=Eliel@151-202-114-200.fibertel.com.ar) |
| 02:23.23 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 02:28.15 | *** join/#asterisk-dev obnauticus (n=lol@about/windows/regular/obnauticus) |
| 02:53.52 | *** join/#asterisk-dev obnauticus (n=lol@about/windows/regular/obnauticus) |
| 04:48.42 | *** join/#asterisk-dev JunK-Y (n=junky@modemcable156.137-20-96.mc.videotron.ca) |
| 05:09.10 | *** join/#asterisk-dev xpot (n=xpot@cpe-66-69-157-86.sw.res.rr.com) |
| 05:49.03 | JunK-Y | never heard about g711.1 before |
| 05:49.03 | JunK-Y | http://tools.ietf.org/html/rfc5391 |
| 06:08.31 | *** join/#asterisk-dev silentaudience (i=psybnc@194.105.146.253) |
| 06:51.51 | *** join/#asterisk-dev silentaudience (i=psybnc@194.105.146.253) |
| 06:54.42 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 06:54.42 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:01.53 | *** join/#asterisk-dev silentaudience (i=psybnc@194.105.146.253) |
| 07:27.39 | *** join/#asterisk-dev file (n=file@asterisk/developer-and-muffin-lover/file) |
| 07:27.39 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 07:50.53 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@local.xorcom.com) |
| 07:50.53 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 08:22.08 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 08:22.08 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:49.32 | *** join/#asterisk-dev obnauticus (n=lol@about/windows/regular/obnauticus) |
| 09:19.13 | *** join/#asterisk-dev mosty (n=mosty@130.41.233.220.exetel.com.au) |
| 09:21.39 | *** join/#asterisk-dev silentaudience (i=psybnc@194.105.146.253) |
| 10:00.31 | *** join/#asterisk-dev qdk (n=qdk@212.27.18.148.bredband.3.dk) |
| 10:44.49 | *** join/#asterisk-dev write_erase (n=Olivier@217.108.144.241) |
| 10:45.37 | write_erase | Hi... I'm trying to install latest dahdi driver (SVN) , but It seems there's abug in dahdi_genconf: |
| 10:45.41 | write_erase | dahdi_genconf |
| 10:45.42 | write_erase | unknown default dahdi signalling for chan 1 type BRI at /usr/sbin/dahdi_genconf line 186. |
| 10:59.56 | tzafrir_laptop | write_erase, what card do you have? |
| 11:00.14 | write_erase | b410p |
| 11:00.39 | tzafrir_laptop | Let me see |
| 11:00.47 | write_erase | I run this release: ""http://svn.digium.com/svn/dahdi/linux-complete/tags/2.1.0-rc3+2.1.0-rc3" |
| 11:01.43 | write_erase | I found an article here : http://www.venturevoip.com/news.php?rssid=2079 requesting people for tests |
| 11:01.44 | tzafrir_laptop | that release or SVN? |
| 11:02.09 | tzafrir_laptop | I think that there were some major fixes for wcb4xxp after that RC |
| 11:02.41 | write_erase | oh... I thought it was a special branch... Should I try with trunk ? |
| 11:09.26 | *** join/#asterisk-dev Marquis42 (n=bfhbmw0@65-127-126-34.dia.static.qwest.net) |
| 11:13.05 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 11:14.53 | tzafrir_laptop | write_erase, yes, please use the trunk |
| 11:24.08 | write_erase | http://svn.digium.com/svn/dahdi/tools/trunk/xpp/dahdi_genconf : unknown default dahdi signalling for chan 1 type BRI at ./xpp/dahdi_genconf line 189. |
| 11:24.55 | write_erase | tzafrir_laptop, seems dahdi_genconf don't support b410p... strange |
| 11:25.36 | tzafrir_laptop | write_erase, IIRC the type change to something different anyway in newer versions. Which is why I asked you what version you use |
| 11:26.21 | write_erase | now I use dahdi-tools and dahdi-linux from trunk svn . |
| 11:29.16 | mosty | anyone interested in looking over my GotoIfTime timezone patch? :) |
| 11:33.22 | tzafrir_laptop | write_erase, hmm.. the card is not considered "digital' now why is that? looking further |
| 11:38.42 | tzafrir_laptop | write_erase, what is the first line in /proc/dahdi/1 ? |
| 11:41.01 | write_erase | Span 1: B4/0/1 "B4XXP (PCI) Card 0 Span 1" (MASTER) \n 1 B4/0/1/1 \n2 B4/0/1/2 \n3 B4/0/1/3 |
| 11:41.50 | write_erase | tzafrir_laptop, http://pastebin.com/m18a3cb14 That's cleaner |
| 11:47.06 | tzafrir_laptop | write_erase, try the following patch: http://paste.debian.net/23126/ |
| 11:55.00 | write_erase | tzafrir_laptop, http://paste.debian.net/23128/ (There was some minor typo on your patcj) |
| 11:55.05 | write_erase | And the result is : |
| 11:55.28 | write_erase | <PROTECTED> |
| 11:55.29 | write_erase | /usr/sbin/dahdi_genconf: No framing information for span #1 |
| 12:55.55 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.130.105) |
| 13:12.59 | write_erase | tzafrir_laptop, any idea ? |
| 13:13.23 | tzafrir_laptop | write_erase, hmm... a similar change a bit below... |
| 13:13.57 | write_erase | Any idea why the code is not up to date ? is B410p support too recent ? |
| 13:14.55 | tzafrir_laptop | write_erase, I guess nobody reported that before |
| 13:17.43 | tzafrir_laptop | write_erase, the last hunk in http://paste.debian.net/23130/ |
| 13:19.10 | tzafrir_laptop | What was the typo in my patch? |
| 13:28.14 | write_erase | comma at a bad location . should be between 'HFC-S PCI A ISDN.* \[(NT|TE)\] ' and '(B4XXP) \(PCI\) Card', |
| 13:29.25 | *** join/#asterisk-dev Dynamicdude (n=3a1ba688@67.159.35.76) |
| 13:34.04 | *** join/#asterisk-dev Dynamicdude (n=3a1ba688@67.159.35.76) |
| 13:34.10 | Dynamicdude | hello |
| 13:34.18 | Dynamicdude | anybode there |
| 13:34.52 | Dynamicdude | Hey developers |
| 13:35.37 | Dynamicdude | ? |
| 13:35.38 | Dynamicdude | ? |
| 13:37.23 | Dynamicdude | hello |
| 13:38.56 | *** join/#asterisk-dev kamanashisroy (n=kamanash@119.30.34.10) |
| 13:40.01 | *** join/#asterisk-dev Dynamicdude (n=3a1ba688@67.159.35.76) |
| 13:42.08 | *** join/#asterisk-dev Dynamicdude (n=3a1ba688@67.159.35.76) |
| 13:43.49 | *** join/#asterisk-dev Dynamicdude (n=3a1ba688@67.159.35.76) |
| 13:45.13 | *** join/#asterisk-dev Dynamicdude (n=3a1ba688@67.159.35.76) |
| 13:50.42 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:50.42 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 13:52.11 | write_erase | tzafrir_laptop, Ok ... next error is : "/usr/sbin/dahdi_genconf: missing default group (termtype=B4XXP)" |
| 13:55.44 | tzafrir_laptop | write_erase, right. Really smart of me to change only one instance of $1: http://paste.debian.net/23132/ |
| 13:56.46 | write_erase | tzafrir_laptop, sorry for not doing the changes myself, but I don't know the hardware part & configuration . |
| 14:00.04 | write_erase | tzafrir_laptop, I have a nice "/etc/asterisk/dahdi-channels.conf" now ..... I'll try to make this all work. |
| 14:00.14 | write_erase | tzafrir_laptop, could you commit the changes ? thx ? |
| 14:00.19 | tzafrir_laptop | write_erase, thanks for testing! |
| 14:01.40 | *** join/#asterisk-dev eliel (n=eliel@151-202-114-200.fibertel.com.ar) |
| 14:01.40 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 14:02.36 | tzafrir_laptop | write_erase, commited :-) |
| 14:11.13 | write_erase | tzafrir_laptop, thx... II'll try to run this configuration. |
| 14:11.27 | write_erase | Here is the generated configuration file http://paste.debian.net/23133/ |
| 14:12.46 | write_erase | tzafrir_laptop, channels numbers mapping has holes : 1-2 , then 4-5 ... Any idea ? |
| 14:13.05 | tzafrir_laptop | 3, 6, 9 and 12 are the D-channels |
| 14:13.09 | tzafrir_laptop | see lszaptel |
| 14:13.16 | tzafrir_laptop | lsdahdi, that is |
| 14:23.03 | *** part/#asterisk-dev russellb (n=russellb@asterisk/digium-open-source-team-lead/russellb) |
| 14:23.20 | *** join/#asterisk-dev russellb (n=russellb@asterisk/digium-open-source-team-lead/russellb) |
| 14:23.20 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 14:35.15 | write_erase | tzafrir_laptop, sounds nice : |
| 14:35.17 | write_erase | *CLI> dahdi show status |
| 14:35.17 | write_erase | Description Alarms IRQ bpviol CRC4 Fra Codi Options LBO |
| 14:35.18 | write_erase | B4XXP (PCI) Card 0 Span 1 OK 0 0 0 CCS AMI YEL 0 db (CSU)/0-133 feet (DSX-1) |
| 14:50.33 | *** join/#asterisk-dev moy (n=moy@189.169.89.20) |
| 14:58.45 | *** join/#asterisk-dev putnopvut (n=putnopvu@nat/digium/x-4cf565d62820c36b) |
| 14:58.45 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:03.12 | *** join/#asterisk-dev awk_r (n=rawk@nat/digium/x-ec4950ec3883ec5b) |
| 15:08.39 | seanbright | russellb: i can backport it as well, if necessary. |
| 15:10.15 | russellb | no big deal |
| 15:10.18 | russellb | it's small |
| 15:10.24 | russellb | it'll only take a minute |
| 15:10.27 | seanbright | alrighty |
| 15:10.36 | seanbright | well you know where i is |
| 15:10.41 | russellb | and someone will have to look at it regardless to get it committed |
| 15:10.43 | russellb | indeed |
| 15:10.45 | russellb | thanks for the offer |
| 15:10.48 | seanbright | nods |
| 15:26.15 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 15:26.29 | *** join/#asterisk-dev corramor (n=corramor@nat/digium/x-ec518f54005500b9) |
| 15:35.36 | *** join/#asterisk-dev Deeewayne (n=Deeewayn@nat/digium/x-82895dc55c74b3b7) |
| 15:35.36 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 15:36.51 | *** join/#asterisk-dev angler (n=angler@pdpc/sponsor/digium/angler) |
| 15:40.02 | *** join/#asterisk-dev sruffell (n=sruffell@nat/digium/x-ad1f9cfddfc6e236) |
| 15:40.03 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:52.55 | *** join/#asterisk-dev schmooze (n=schmooze@h69-129-142-83.mdsnwi.tisp.static.tds.net) |
| 16:01.33 | lmadsen | eliel: ping? |
| 16:01.46 | eliel | lmadsen: here |
| 16:03.43 | lmadsen | ummm... let me see if I can figure this out real quick, and if not, then I'll ask :) |
| 16:04.42 | eliel | lmadsen: ask, maybe i can help you |
| 16:05.29 | lmadsen | well, I'm trying to compile asterisk-trunk, but I'm getting an error about missing libxml2-devel, but I have it installed, so I'm wondering what other pkg I'm missing |
| 16:07.01 | russellb | re-run configure |
| 16:07.04 | lmadsen | I did |
| 16:07.05 | lmadsen | of course |
| 16:07.07 | russellb | oic. |
| 16:07.23 | eliel | search for libxml/tree.h |
| 16:07.25 | lmadsen | I'm looking at the config.log to see what it could be, but its not immediately obvious |
| 16:07.34 | eliel | and libxml/parser.h |
| 16:08.18 | russellb | the configure script runs xml2-config to get the right compiler options |
| 16:08.24 | russellb | do you have the "xml2-config" application? |
| 16:08.41 | lmadsen | yes |
| 16:09.21 | russellb | oic. |
| 16:09.32 | lmadsen | /usr/include/libxml2/libxml/tree.h |
| 16:09.39 | russellb | can you post config.log somewhere? |
| 16:09.48 | russellb | i bet the package is broken and didn't make you install something else it needs |
| 16:10.02 | lmadsen | maybe |
| 16:10.05 | lmadsen | let me see |
| 16:11.56 | *** join/#asterisk-dev steliosk (n=Stelios@ipa107.2.tellas.gr) |
| 16:12.09 | eliel | lmadsen: can you run: xml2-config --cflags |
| 16:12.20 | eliel | to check if it is returning the right path. |
| 16:12.34 | lmadsen | -I/usr/include/libxml2 |
| 16:12.46 | eliel | thats ok |
| 16:13.10 | russellb | xml2-config --libs |
| 16:13.47 | lmadsen | russellb: http://leifmadsen.com/config.log |
| 16:14.10 | lmadsen | -lxml2 -lz -lm |
| 16:14.12 | seanbright | /usr/bin/ld: cannot find -lz |
| 16:14.20 | lmadsen | what is -lz ? |
| 16:14.23 | russellb | curses your distro |
| 16:14.24 | seanbright | zlib |
| 16:14.26 | russellb | it's a compression lib |
| 16:14.33 | lmadsen | russellb: sorry, CentOS 5.2. Quite common. |
| 16:14.38 | russellb | nods |
| 16:14.40 | seanbright | yum install zlib? |
| 16:14.41 | russellb | centos is teh suck |
| 16:14.46 | lmadsen | seanbright: gah... I saw it install it, but not the -devel I guess |
| 16:14.54 | lmadsen | russellb: still common and works quite well for many people |
| 16:15.00 | seanbright | runs it |
| 16:15.02 | lmadsen | de-trolls asterisk |
| 16:15.06 | seanbright | lmadsen: 64 bit? |
| 16:15.07 | russellb | it found it, but claims it's incompatible ... |
| 16:15.08 | lmadsen | s/asterisk/russellb |
| 16:15.19 | lmadsen | seanbright: ya |
| 16:15.21 | seanbright | nooooooooooooooooooooooo! |
| 16:15.22 | lmadsen | no -devel installed |
| 16:15.27 | seanbright | ok... first thing |
| 16:15.36 | seanbright | yum remove *.i386 |
| 16:15.40 | seanbright | heh |
| 16:15.56 | seanbright | then, when you specify packages to install, fully qualify them |
| 16:16.04 | seanbright | yum install libxml2-devel.x86_64 |
| 16:16.24 | seanbright | 32bit packages satisfy 64bit dependencies on centos 5.2 |
| 16:16.27 | lmadsen | ya, well just a test machine for now, so was just trying to find all the pkgs I needed, but that libxml2 msg was confusing me |
| 16:16.39 | seanbright | gotcha |
| 16:16.55 | lmadsen | luckily I'm writing documentation about this and will post a blog entry somewhere |
| 16:17.06 | seanbright | well, you'd be better off removing non-64 bit packages |
| 16:17.22 | lmadsen | ./configure successful now |
| 16:17.28 | seanbright | and making sure that when you install you specify the arch at the end of the package name (i.e. foo-devel.x86_64) |
| 16:17.31 | seanbright | awesome |
| 16:18.16 | lmadsen | yep, will probably get moved into the book at some point, but for now, I think we need some docs to help people build 1.6 and trunk |
| 16:18.56 | lmadsen | luckily, on a CentOS 5.2 minimal install, you only need to install 10 pkgs (and their deps which is done for you automatically) to get libpri, dadhi, and asterisk built |
| 16:18.59 | lmadsen | (minimally built) |
| 16:19.16 | seanbright | it's the automatically part that is going to end up screwing you |
| 16:19.39 | seanbright | (i run centos 5.2, so i'm not trolling) |
| 16:19.40 | lmadsen | ya... oh well, yum remove *.i386 works fine |
| 16:19.45 | seanbright | indeed |
| 16:19.53 | lmadsen | I'll just make it a 'cleanup' step at the end |
| 16:20.01 | lmadsen | most people won't have this issue when I'm telling them exactly what to run |
| 16:20.15 | seanbright | or like i said, just qualify the package names during install 'yum install something.x86_64' |
| 16:20.28 | seanbright | that will only install 64bit depends |
| 16:20.50 | lmadsen | yep, I can do that too, but does that make it smart enough to only install the .x86_64 deps as well? |
| 16:20.56 | seanbright | correct |
| 16:21.42 | *** join/#asterisk-dev angler (n=angler@pdpc/sponsor/digium/angler) |
| 16:21.43 | lmadsen | coolio, I will be sure to mention that in the docs |
| 16:21.56 | lmadsen | I'm kinda happy and surprised you only need a list of 10 pkgs :) |
| 16:21.56 | seanbright | credit goes to Qwell for that gem |
| 16:22.07 | Qwell | huh? |
| 16:22.10 | Qwell | oh |
| 16:22.12 | seanbright | all the centos madness |
| 16:22.15 | Qwell | meh |
| 16:22.16 | lmadsen | it is documented that Qwell is not a newb |
| 16:22.26 | lmadsen | thus it must be true |
| 16:22.30 | Qwell | must be |
| 16:22.37 | seanbright | you can go back to bed now |
| 16:22.38 | seanbright | heh |
| 16:22.48 | lmadsen | isqwellanewb.com --> NO! |
| 16:22.55 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 16:23.09 | putnopvut | isqwellabanana.com --> MAYBE! |
| 16:23.28 | seanbright | Qwell is a great source of pottasium |
| 16:23.35 | jsmith | letmegooglethatforyou.com/?q=qwell+newb |
| 16:23.38 | lmadsen | speaking of which, I need a snack |
| 16:23.38 | Qwell | that's what they say... |
| 16:23.48 | seanbright | jbot: search google for Qwell |
| 16:23.51 | Qwell | jsmith: I love that site |
| 16:23.56 | seanbright | jbot: you suck |
| 16:23.56 | jbot | and very well I might add |
| 16:24.01 | seanbright | touche |
| 16:24.08 | putnopvut | I realized shortly after typing what I did that "banana" is actually a racial insult and that I wanted to clarify that I meant the fruit. |
| 16:24.18 | Qwell | putnopvut: O.o |
| 16:24.19 | seanbright | banana is a racial slur? |
| 16:24.25 | seanbright | since when? |
| 16:24.32 | putnopvut | since at least when I was in high school. |
| 16:24.46 | putnopvut | I had a Korean friend that would call other Koreans who "acted white" bananas. |
| 16:24.49 | lmadsen | I must be too far north |
| 16:24.52 | putnopvut | Yellow on the outside, white on the inside. |
| 16:24.55 | lmadsen | lol |
| 16:25.01 | putnopvut | But I digress. |
| 16:25.22 | seanbright | when a korean calls another korean a banana, i'm not convinced that qualifies as racist. |
| 16:25.33 | seanbright | but i too digress. |
| 16:25.47 | seanbright | and i now smoke. |
| 16:26.12 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 16:26.12 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 16:36.42 | *** join/#asterisk-dev DarkRift (n=dark@65.92.167.39) |
| 16:39.35 | *** join/#asterisk-dev Corydon76-lap (n=Corydon7@pdpc/supporter/bronze/Corydon76-home) |
| 16:39.35 | *** mode/#asterisk-dev [+o Corydon76-lap] by ChanServ |
| 16:40.32 | eliel | there is a review request for making every app/fun parameter separator backward compatible (support pipe as the parameter separator), this is just a reminder ... thanks |
| 16:44.27 | russellb | I had a thought about it .. |
| 16:44.33 | russellb | it's not so much a backwards compat option |
| 16:44.39 | russellb | because previous versions actually accepted both |
| 16:44.49 | russellb | it's more of an option that lets you pick, i guess |
| 16:44.54 | russellb | but anyway, that's just semantics :) |
| 16:45.13 | eliel | yes, you are right |
| 16:46.00 | kpfleming | personally i am not in favor of maintaining that compatibility |
| 16:46.23 | kpfleming | look at all the places that had to be touched because they generate argument lists in code... all of those places now have to do the 'right thing' based on that option |
| 16:46.40 | russellb | that's true ... that would be quite a pain to find them all again |
| 16:46.51 | putnopvut | Yes, in fact I fixed one such case last week. |
| 16:46.52 | russellb | seems like we're still finding them, too |
| 16:46.52 | kpfleming | and it puts a burden on future development |
| 16:47.13 | kpfleming | so the question is, what is driving the desire for the backwards compat option? |
| 16:47.32 | russellb | just making it easier for people to upgrade without changing config, i guess |
| 16:48.00 | russellb | but since it doesn't really provide the old behavior (which was supporting both), i don't know if the effort is worth it |
| 16:48.15 | kpfleming | exactly... if they had mixed usage before, it will still be broken |
| 16:48.16 | russellb | i was on the fence about it, and now that I think about it more, I'm leaning toward thinking we should just go without it |
| 16:48.33 | mnicholson | perhaps we could make an "arg_list_builder" api that will build arg lists using the selected separator |
| 16:48.43 | jets | A lot of users have to hack the config because of new variables anyways. |
| 16:48.55 | Corydon76-lap | s/hack/change/ |
| 16:49.06 | Juggie | jets! |
| 16:49.12 | jets | Corydon76-lap: precisely. :) |
| 16:49.23 | eliel | russellb: at least, if you look at the code, there is no place defining the default arg separator, everyone is using a hardcoded ',' i think that should be changed |
| 16:49.41 | jets | Juggie! |
| 16:49.45 | Corydon76-lap | eliel: I'm fine with that part |
| 16:50.16 | Corydon76-lap | eliel: but I don't think you should be changing strchr to strstr |
| 16:50.24 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.10.119) |
| 16:51.22 | Corydon76-lap | There's a risk that somebody might look at that and figure they can change the delimiter to a multi-character |
| 16:51.44 | Corydon76-lap | and that would be a VERY bad assumption |
| 16:51.55 | jets | eee |
| 16:52.01 | eliel | Corydon76-lap: what do you suggest? |
| 16:52.05 | Corydon76-lap | given that sometimes we use strsep and sometimes we use strstr |
| 16:52.48 | jets | I can already see a properietary AEL obfuscation application for people to "encode" their dialplan *twitches in his skin* |
| 16:52.53 | Corydon76-lap | eliel: I would suggest that if you're doing that, you should use AST_STANDARD_APP_DELIM_CHAR, which is simply defined as AST_STANDARD_APP_DELIM[0] |
| 16:53.03 | jets | s/properietary/proprietary |
| 16:53.24 | eliel | Corydon76-lap: ok, thats fine |
| 16:55.41 | Corydon76-lap | Uh, ast_application_syntax should return a const char * |
| 16:57.13 | eliel | sure? it is a dynamic allocated string... |
| 16:58.36 | eliel | didn't learned when to use 'const'... |
| 16:59.18 | Corydon76-lap | Even so, it shouldn't be altered |
| 17:00.25 | eliel | but i think i will need to cast the ast_free(). |
| 17:01.10 | Corydon76-lap | I'm submitting a review, hang on |
| 17:07.56 | Corydon76-lap | Okay, review submitted |
| 17:08.40 | eliel | thanks |
| 17:09.12 | eliel | I will also remove the code that adds the app_delim compat option based on russellb and kpfleming comments |
| 17:28.14 | *** join/#asterisk-dev ctooley (n=ctooley@doc-24-32-196-69.concordia.ks.cebridge.net) |
| 17:28.14 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 17:38.35 | eliel | Corydon76-lap: you are working on extending the ast_str API to avoid accessing the ast_str structure directly? |
| 17:42.40 | Corydon76-lap | eliel: yes |
| 17:43.08 | eliel | Corydon76-lap: Add S_OR support to your list |
| 17:43.30 | Corydon76-lap | Eh? |
| 17:43.49 | seanbright | S_OR for ast_str |
| 17:44.15 | Corydon76-lap | You'd just use ast_str_buffer(foo) |
| 17:44.45 | kpfleming | does ast_str need a 'const char*' cast operator? :-) |
| 17:44.50 | Corydon76-lap | S_OR(ast_str_buffer(foo), "something else") |
| 17:45.16 | eliel | ohh, didn't knew about ast_str_buffer() |
| 17:45.22 | russellb | kpfleming: yep :) |
| 17:45.46 | Corydon76-lap | That was the point of the opacity... hide the internals, so they could be changed at a future point in time |
| 17:46.14 | russellb | Corydon76-lap: thanks for working on that ... i know it was a pain |
| 17:46.29 | Corydon76-lap | eliel: it's still in a branch and I'm working on converting everything |
| 17:46.46 | Corydon76-lap | russellb: well, in the meantime, I found some show stopping bugs in chan_sip |
| 17:47.04 | eliel | Corydon76-lap: those strange sizeof()s ?? |
| 17:47.18 | russellb | Corydon76-lap: ah yes ... |
| 17:47.26 | russellb | I'd be ok with leaving that one unconverted for now |
| 17:47.27 | Corydon76-lap | because someone was using memory pointers insde of an ast_str, then calling ast_str_append... |
| 17:47.32 | russellb | that's going to take some work |
| 17:47.35 | russellb | yeah that is very bad |
| 17:47.44 | seanbright | hopes it wasn't him |
| 17:47.52 | russellb | may have been me |
| 17:47.56 | seanbright | sweet |
| 17:47.57 | russellb | I committed the first version of that patch |
| 17:48.14 | russellb | didn't write it ... just did a poor review i guess |
| 17:48.29 | seanbright | what patch are we talking about? |
| 17:48.32 | Corydon76-lap | russellb: actually, it's the first module that I found that was kind of...bad... |
| 17:48.55 | russellb | seanbright: it made chan_sip able to handle packets larger than 4096 bytes |
| 17:49.00 | seanbright | ohhhh |
| 17:49.00 | russellb | by using a dynamic buffer |
| 17:49.07 | seanbright | right. |
| 17:49.11 | kpfleming | hang on |
| 17:49.29 | kpfleming | that code is actually safe |
| 17:49.45 | russellb | pointers inside a buffer that might get reallocd? |
| 17:49.49 | Qwell | stupid question... how many samples are in a text frame? O.o |
| 17:49.59 | russellb | Qwell: that makes zero sense, sir. |
| 17:50.00 | kpfleming | only because it knows how to allocate the proper sized buffer ahead of time |
| 17:50.05 | Qwell | russellb: yeah... |
| 17:50.11 | file | he is talking T.140 |
| 17:50.16 | Qwell | file: mmhmm |
| 17:50.24 | russellb | check the spec |
| 17:50.46 | russellb | kpfleming: ok, then yeah, if that's the case then we're ok |
| 17:50.56 | russellb | as long as there isn't a chance that it's going to get realloc'd on the append() call |
| 17:51.11 | kpfleming | it's still ugly and wrong, but doesn't need to be changed right now |
| 17:51.16 | seanbright | just pass 0 to append |
| 17:51.24 | russellb | kpfleming: agreed |
| 17:51.32 | russellb | seanbright: 0 means unlimited |
| 17:51.32 | kpfleming | eventually those structures should be changed to use offsets into the string instead of pointers |
| 17:51.35 | seanbright | -1 then |
| 17:51.41 | seanbright | whichever means "only the space i already have" |
| 17:51.45 | russellb | you _could_ however pass an arg of the current buffer size |
| 17:51.54 | russellb | that would do it |
| 17:52.17 | seanbright | 0 means unlimited, -1 means "at most the available space" |
| 17:52.22 | seanbright | from strings.h |
| 17:52.22 | russellb | orly? |
| 17:52.28 | russellb | forgot about that, then |
| 17:52.34 | russellb | guess rizzo added it |
| 17:52.59 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 17:54.23 | seanbright | 'twould appear so |
| 18:01.02 | codefreeze-lap | jets... into morse code? |
| 18:01.13 | mnicholson | so, i have been thinking about automating asterisk testing, and I had some ideas I wanted to bounce off you guys |
| 18:02.11 | Corydon76-lap | is made of rubber, you're made of glue... |
| 18:02.29 | Corydon76-lap | wait... |
| 18:03.01 | mnicholson | the core of my idea was to build a chan_test module, that can be scripted (via lua of course), and use that to place calls into the dialplan and playback files and generate dtmf tones and such. This would be the core of a larger test framework, that would allow you to start up asterisk instances with different config files and such. |
| 18:03.08 | mnicholson | that's the basic idea thus far |
| 18:03.20 | seanbright | ship it! |
| 18:03.22 | file | mnicholson: I have had the same idea |
| 18:03.29 | russellb | has had thoughts of a chan_test as well |
| 18:03.47 | putnopvut | I have never had such an idea. |
| 18:03.51 | putnopvut | But I like the concept. |
| 18:03.51 | russellb | I think you're on the right track from a high level |
| 18:05.12 | Corydon76-lap | Just for testing dialplan and other core objects, right? |
| 18:05.17 | mnicholson | this would work for testing dialplan apps and functions, and could be used for some limited channel driver testing |
| 18:05.42 | mnicholson | but the important thing is, it would all be automated and we could use it to do regression testing |
| 18:06.29 | lmadsen | funny how I was thinking about trying to come up with some test plans the other day |
| 18:06.42 | lmadsen | I made a small wiki entry that had some bullet points of things that might be interesting to test |
| 18:06.51 | Corydon76-lap | I've considered that before, but the project is truly massive to consider |
| 18:07.05 | russellb | don't think about how big it is |
| 18:07.05 | lmadsen | gotta start somewhere |
| 18:07.09 | mnicholson | Corydon76-lap, it's not that massive |
| 18:07.09 | russellb | if you do, it'll never start :) |
| 18:07.35 | Corydon76-lap | russellb: That's actually precisely why it's never been started |
| 18:07.43 | russellb | nods |
| 18:07.43 | mnicholson | basically you implement the absolute minimum channel driver you can fathom, and then stick a lua instance in it |
| 18:08.19 | Corydon76-lap | mnicholson: and basically watch audio flows? |
| 18:08.28 | mnicholson | no, not yet :) |
| 18:08.37 | russellb | start with signaling |
| 18:09.04 | mnicholson | audio should not be too difficult, though |
| 18:09.28 | Corydon76-lap | mnicholson: as long as it doesn't involve transcoding, it shouldn't be too difficult |
| 18:09.44 | mnicholson | Corydon76-lap, why would transcoding make it complicated? |
| 18:09.54 | mnicholson | i might be missing something |
| 18:10.16 | Corydon76-lap | Once you pass ulaw through g729 and back, the state of the ulaw is not the same, so you need to do audio analysis to check validity |
| 18:10.39 | mnicholson | Corydon76-lap, well, that's only if you are performing tests on the actual audio stream |
| 18:10.48 | file | just have to go at it bit by bit... |
| 18:10.50 | file | byte by byte |
| 18:10.56 | russellb | word by word |
| 18:11.04 | Corydon76-lap | nibble by nibble |
| 18:11.10 | eliel | page by page |
| 18:11.15 | mnicholson | terabyte by terabyte |
| 18:11.34 | Corydon76-lap | block by block |
| 18:12.22 | mnicholson | so, about what percentage of our bugs could be caught by a basic regression testing facility like this? |
| 18:12.25 | Corydon76-lap | segment by segment |
| 18:12.39 | eliel | quantum by quantum |
| 18:12.57 | Corydon76-lap | eliel: by what computing measure is a quantum? |
| 18:13.45 | file | mnicholson: basic? meh |
| 18:13.47 | Corydon76-lap | mnicholson: of the bugs we've fixed already or the bugs we haven't found yet? |
| 18:14.19 | mnicholson | of the bugs that have existed in the bug tracker, fixed or not |
| 18:14.19 | Corydon76-lap | mnicholson: I think it's likely to find a good number of bugs of types we haven't even considered yet |
| 18:14.40 | eliel | qubits by qubits :-) |
| 18:14.42 | file | if it gets into advanced scenarios I agree |
| 18:14.47 | Corydon76-lap | The ones that are hard to catch because the system doesn't always misbehave |
| 18:15.35 | Corydon76-lap | We are totally all about repeatable cases, and something like this would create a case history for something that may not always happen |
| 18:15.59 | Corydon76-lap | Perfect storm, so to speak |
| 18:16.10 | mnicholson | i guess I should have said: in your experience, from the bugs that you have seen in your time as an asterisk developer, what estimated percentage could have been discovered via the automated testing facility described above (given sufficient test coverage) |
| 18:16.36 | Corydon76-lap | Maybe 40%? |
| 18:16.49 | mnicholson | really? that many? |
| 18:17.05 | Corydon76-lap | When you're talking about regressions, yes |
| 18:17.22 | mnicholson | hmm... |
| 18:17.33 | Corydon76-lap | Sometimes we catch them in testing, so it's not always something that hits commit stage |
| 18:18.09 | Corydon76-lap | but having an automated tool would free us up from everybody having to develop their own test cases |
| 18:18.35 | Corydon76-lap | Well, having to repeatedly develop the same test cases, rather |
| 18:18.51 | mnicholson | hmm... ok |
| 18:19.02 | eliel | what about using a unit testing framework ? |
| 18:19.07 | Corydon76-lap | You should see the dialplan on my development machine... every dialplan test I've ever formulated is still in there |
| 18:19.18 | mnicholson | Corydon76-lap, yuck |
| 18:19.30 | Corydon76-lap | minus the ones I've done on other development machines |
| 18:19.49 | Corydon76-lap | mnicholson: no, it's helpful when I need to go back and check something |
| 18:20.21 | Corydon76-lap | but yeah, an automated test framework, where we can each develop tests and add them to regression testing... totally helpful |
| 18:20.34 | mnicholson | Corydon76-lap, ok |
| 18:21.18 | mnicholson | eliel, unit testing would be useful as well for testing things like ast_obj2 and the string stuff, and individual api functions |
| 18:22.22 | eliel | mnicholson: the only problem i see, is that no one will code those tests... |
| 18:22.36 | seanbright | murf will |
| 18:22.51 | mnicholson | if they are simple to build, people will code them |
| 18:23.04 | russellb | indeed, and if we went that route, we would require it for new code |
| 18:23.06 | russellb | so that would help |
| 18:23.25 | mnicholson | right |
| 18:23.26 | russellb | at some point, I'd like to get where we don't commit stuff without a way to test it |
| 18:23.30 | russellb | but we're so far away from that ... |
| 18:23.41 | mnicholson | russellb, the monotone project does it that way |
| 18:23.50 | russellb | test driven development |
| 18:23.56 | russellb | it's somewhat common |
| 18:24.05 | eliel | russellb: yes, that will be nice |
| 18:24.15 | mnicholson | well, no not quite test driven development, but they require tests for the code before it is included |
| 18:24.24 | eliel | but it is hard to change developers mind for using tdd |
| 18:24.32 | russellb | mnicholson: ok, yeah, that's basically what I would want |
| 18:24.45 | mnicholson | russellb, yeah me too, i'm not down with the tdd stuff |
| 18:25.19 | codefreeze-lap | mnicholson: sometimes a good test program requires more effort than the code its testing! |
| 18:25.20 | mnicholson | also, when a bug was fixed, a test could be required to demonstrate that it was fixed |
| 18:25.38 | mnicholson | codefreeze-lap, yeah :) |
| 18:26.29 | codefreeze-lap | mnicholson: AND, some tests require quite a bit of setup, a specialized dialplan, a set of phones, etc. etc. |
| 18:29.08 | file | has "API Test Module" on his whiteboard for bridging |
| 18:32.35 | mnicholson | codefreeze-lap, so my idea for that is to build a test driver (where tests are written in lua as well). The test driver will have utility functions built that make it easy to load only the modules you need and to build custom config files and such, then it would most likely start asterisk and do an originate from chan_test, at which point your chan_test config (which could in theory be written by the test driver), would take ov |
| 18:32.35 | mnicholson | er that portion of the test |
| 18:33.27 | mnicholson | that would not handle setting up phones and such, but even without phones there is a lot of testing you can do |
| 18:34.26 | mnicholson | and in theory you could use the test driver to spawn multiple instances of asterisk, to pass calls between them |
| 18:37.42 | eliel | an allocated threadstorage is freed when ... |
| 18:38.06 | eliel | thread is finished running? |
| 18:41.04 | russellb | correct |
| 18:41.21 | russellb | when the thread exits, it runs a destructor for the thread specific data |
| 18:41.27 | russellb | which in the common case, is just free() |
| 18:41.35 | russellb | but can be a custom function, as well |
| 18:42.03 | codefreeze-lap | mnicholson: sounds cool, it will all help, but most of my tests so far, with stuff like xfers, etc, is stuff like 'flash hook, verify two-way audio between A,B,and C, which I mostly do by scratching the mikes of the various phone handesets laying around, etc. I keep wondering how that might be automated... |
| 18:42.15 | *** join/#asterisk-dev sysreq (n=sysreq@unaffiliated/sysreq) |
| 18:43.51 | Corydon76-lap | codefreeze-lap: the driver could itself queue up tt-weasels, then detect that audio on another instance |
| 18:44.33 | Corydon76-lap | thus demonstrating (or not) the intended flow of audio |
| 18:44.40 | eliel | russellb: is there a cache or something? I am running |
| 18:44.54 | eliel | threadstorage show summary and the mmemory is not being released... |
| 18:45.19 | russellb | even after the thread exits? |
| 18:45.26 | codefreeze-lap | Corydon76-lap: just being difficult here, but it would need to be able to detect, maybe, the diff between MOH and monkeys screaming... Maybe just a DTMF sent/detected between chans might do... |
| 18:45.34 | russellb | could be a bug in the debugging code, too ... |
| 18:45.46 | Corydon76-lap | codefreeze-lap: but DTMF is not always audio |
| 18:46.08 | codefreeze-lap | Corydon76-lap: true... |
| 18:46.19 | Corydon76-lap | codefreeze-lap: for that matter, it could be a specific control frame, if only to test that |
| 18:46.30 | Corydon76-lap | codefreeze-lap: but the intent is to send something unique |
| 18:46.33 | mnicholson | codefreeze-lap, the test driver could have functions to detect specific audio (which would work in the absence of trans coding) |
| 18:47.21 | eliel | I am calling the threadstorage_get inside an api in pbx.c, that api is being called by func_realtime.c when an error occurs... When calling func_realtime.c from the dialplan tu generate that error, i see in the summary that the memory is being allocated, but never freed... |
| 18:48.21 | eliel | is this an architecture misunderstanding? |
| 18:48.49 | codefreeze-lap | mnicholson: yeah, maybe MOH that consists of DTMF playing "Mary had a little lamb" over and over... |
| 18:51.32 | codefreeze-lap | mnicholson: yes, I can picture several asterisks running, acting as extremely intelligent phones, running test dialplans... stuff along that line... to do xfers, verify linkups, teardowns, parks, holds, dialing, etc. |
| 18:51.40 | codefreeze-lap | I picture a lot of work... |
| 18:52.16 | Corydon76-lap | I picture a green house with a white picket fence... |
| 18:52.23 | mnicholson | the whole idea is to automate it |
| 18:52.40 | mnicholson | non automated testing is not as important to me, although "chan_test" could be used with that too |
| 18:52.54 | codefreeze-lap | ... reminds me of 'expect' scripts |
| 18:53.53 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@bzq-179-75-202.static.bezeqint.net) |
| 18:53.53 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 19:01.18 | eliel | threadstorage not working as i expect ... maybe i am wrong..: http://pastebin.com/m75c3679c |
| 19:24.09 | *** join/#asterisk-dev DarkRift (n=dark@65.92.167.39) |
| 19:59.55 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 19:59.55 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:00.09 | eliel | uh, pastebin is not working... |
| 20:00.16 | eliel | at least for me.. |
| 20:06.25 | Corydon76-lap | which pastebin? |
| 20:07.00 | Corydon76-lap | There's like 30 different implementations |
| 20:07.15 | Corydon76-lap | pastebin.ca was one written by an Asterisk user |
| 20:09.09 | eliel | pastebin.com |
| 20:09.30 | eliel | http://pastebin.com/m75c3679c |
| 20:16.16 | Corydon76-lap | 14028 proposes adding a timezone to GotoIfTime/ExecIfTime/IFTIME(). I'm not wild about the syntax |
| 20:17.20 | Corydon76-lap | I'm even less wild about the implementation, but the syntax seems... hackish... |
| 20:17.33 | lmadsen | M14028 |
| 20:17.34 | MuffinMan | [new] [Asterisk] Applications/NewFeature 0014028: [patch] allow multi-timezone GotoIfTime & ExecIfTime reported by mostyn (Karma: +7.00) http://bugs.digium.com/view.php?id=14028 |
| 20:18.04 | Corydon76-lap | The reporter suggests [timezone,]<time>,<weekdays>,<monthdays>,<months> |
| 20:18.16 | lmadsen | ya.... that'll break a lot of dialplans |
| 20:18.20 | lmadsen | first, it needs to go at the end |
| 20:18.40 | Corydon76-lap | Well, I was thinking two alternative syntaxes |
| 20:18.58 | eliel | second it needs to update xml docs |
| 20:19.03 | putnopvut | Speaking of time applications, Corydon76-lap, did you have plans on following up on the comments I made on your reviewboard post? |
| 20:19.29 | Corydon76-lap | either <time>[ <zone>],<weekdays>,<monthdays>,<months> |
| 20:19.47 | Corydon76-lap | or use a dialplan function to set the timezone and store it in a datastore |
| 20:20.44 | lmadsen | I'd prefer the first method |
| 20:20.54 | Corydon76-lap | I like the second option best, as it allows us to do all sorts of other things, basically making it so that the everything the channel does is local to the timezone, instead of specifying it every time |
| 20:21.01 | lmadsen | although the 2nd makes sense if you had multiple things that could use the TZ setting |
| 20:21.12 | lmadsen | aye |
| 20:21.24 | Corydon76-lap | lmadsen: we do have multiple things already that use timezone settings |
| 20:21.25 | lmadsen | leans toward option 2 |
| 20:21.42 | lmadsen | ok, then how about a TZ setting in the CHANNEL() function? |
| 20:22.20 | Corydon76-lap | and a bunch of places where we just pass NULL, meaning machine timezone |
| 20:24.42 | eliel | if we use a variable to pass the timezone instead of CHANNEL we will be able to use __ to make it inherited, isnt it? |
| 20:25.43 | Corydon76-lap | Dialplan functions don't work that way |
| 20:26.43 | Corydon76-lap | although datastores are certainly inheritable |
| 20:27.24 | eliel | but, we will need to pass another parameter to channel to specify if it must be inheritable or not |
| 20:28.10 | Corydon76-lap | I think timezone is one that could be inheritable for all cases |
| 20:29.21 | Corydon76-lap | eliel: Here's an awesome thing for someone to write: a channel datastore, that when inherited, sets a bunch of dialplan functions... inheritable CDR variables, for one |
| 20:30.13 | Corydon76-lap | Something like Set(INHERIT(CDR(foo))=bar) |
| 20:30.46 | Corydon76-lap | Whaddya think? |
| 20:31.46 | eliel | +1 |
| 20:31.54 | putnopvut | Corydon76-lap: heh, I already am writing an inheritable-audiohook function just like that. |
| 20:32.17 | putnopvut | http://svn.digium.com/svn/asterisk/team/mmichelson/issue13538 |
| 20:33.02 | Corydon76-lap | putnopvut: genericize it? |
| 20:33.40 | russellb | Corydon76-lap: nice idea |
| 20:33.43 | putnopvut | Corydon76-lap: hmmmmm....interesting. |
| 20:34.41 | mosty | lmadsen, why does it matter where the timezone is specified? i just count how many fields there are since all the other fields are required |
| 20:35.28 | lmadsen | mosty: because other people are going to have their dialplans assuming that field does not exist. If it is an optional field, and you put it at the end, then you preserve backward compatibilitiy |
| 20:35.31 | Corydon76-lap | mosty: because if you specify one, you may have to specify it multiple times |
| 20:35.53 | lmadsen | otherwise, you need to put GotoIfTime(,....) instead of just GotoIfTime(...) |
| 20:35.57 | Corydon76-lap | mosty: and I like reducing the amount of typing one has to do |
| 20:36.24 | Corydon76-lap | mosty: that's why I'd like a use case |
| 20:36.45 | putnopvut | Genericizing the audiohook inheritance could be tricky. |
| 20:36.49 | Corydon76-lap | I think I understand one use, but I need to know if it's yours |
| 20:37.16 | Corydon76-lap | putnopvut: not if all you're doing is specifying a dialplan function to set upon inheritance |
| 20:37.34 | Corydon76-lap | putnopvut: do you even have such a dialplan function? |
| 20:37.53 | putnopvut | Corydon76-lap: Not exactly. |
| 20:38.00 | Corydon76-lap | Set(AUDIOHOOK(foo)=bar) ? |
| 20:38.09 | putnopvut | No, nothing like that. |
| 20:38.18 | Corydon76-lap | Set(INHERIT(AUDIOHOOK(foo))=bar) |
| 20:38.25 | putnopvut | This is more like Set(AUDIOHOOK_INHERITANCE(MixMonitor)=enable) |
| 20:38.29 | mosty | Corydon76-lap, i'm working on a test case that isn't time dependent ;) |
| 20:38.44 | putnopvut | That makes it so that the channel will pass its MixMonitor audiohook to whatever it masquerades into. |
| 20:39.19 | Corydon76-lap | mosty: is the idea basically that you're sending a call from a place that has DST to a place that DOESN'T have DST (or vice versa)? |
| 20:40.23 | Corydon76-lap | because this would be wonderful to decide when to send the call, if the destination's times vary a certain amount from the source's times during certain dates |
| 20:40.38 | mosty | Corydon76-lap, DST is the reason why it's a pain to hard-code the offsets manually |
| 20:40.46 | Corydon76-lap | mosty: aha |
| 20:40.47 | *** join/#asterisk-dev qdk (n=qdk@94.191.252.30.bredband.3.dk) |
| 20:41.10 | mosty | Corydon76-lap, but it also makes it easier to do multi-timezone dialplans generally |
| 20:41.20 | Corydon76-lap | mosty: okay, so I think <time>[ <zone],... would be a better syntax... |
| 20:41.44 | Corydon76-lap | I really hate optional prefixes |
| 20:42.16 | Corydon76-lap | I know I've written a few, but that's only because I haven't been able to come up with better syntax |
| 20:42.22 | mosty | it's no big problem to change the syntax |
| 20:43.02 | mosty | it just feels simpler to put the only optional item either at the very start or the very end, personally |
| 20:43.10 | Corydon76-lap | mosty: also, your use of ast_strlen_zero isn't correct |
| 20:43.41 | Corydon76-lap | You're using it in a place where strlen() is obviously the correct usage |
| 20:43.58 | eliel | and also xml docs!! don't forget the xml docs :-) |
| 20:44.06 | eliel | he |
| 20:44.07 | Corydon76-lap | eliel: later |
| 20:44.22 | Corydon76-lap | Syntax first, then code, then documentation |
| 20:44.26 | mosty | Corydon76-lap, ok |
| 20:45.00 | Corydon76-lap | mosty: there's also a few places where you aren't using braces {}. Those are now mandatory under the coding guidelines |
| 20:45.26 | Corydon76-lap | mosty: but make those changes and resubmit, and I'll take another look. |
| 20:46.10 | Corydon76-lap | mosty: (and the xml, too) |
| 20:47.25 | mosty | ok. i wasn't aware of the xml docs, i'll look into that too |
| 20:50.44 | eliel | mosty: ask for help if you don't know how to setup that new optional argument |
| 20:51.38 | eliel | in the xmldoc |
| 20:54.14 | mosty | sure |
| 21:02.57 | eliel | Corydon76-lap: I started using threadstorage for the application_syntax() and custom_function_syntax() to avoid freing the results of this functions but it is not getting freed: http://pastebin.com/m75c3679c |
| 21:03.58 | *** join/#asterisk-dev gambler1 (n=mene_sun@dragan.eunet.yu) |
| 21:04.56 | russellb | eliel: has that call hung up at this point? |
| 21:05.29 | mosty | Corydon76-lap, how about this syntax: GotoIfTime(<times>|<weekdays>|<mdays>|<months>[|<timezone>]?[[context|]exten|]priority) |
| 21:07.27 | eliel | russellb: http://pastebin.com/d1d2175d4 |
| 21:07.41 | jsmith | mosty: (don't forget that you also can have [:[[context,],exten,]priority] on the end, for the false case) |
| 21:07.45 | eliel | this is funcs_realtime.c calling ast_custom_function_syntax(); |
| 21:08.04 | russellb | I mean the call |
| 21:08.09 | russellb | the channel that executed this |
| 21:08.11 | russellb | is the channel thread gone |
| 21:08.15 | seanbright | the "phone" call |
| 21:08.20 | russellb | right |
| 21:08.25 | eliel | russellb: yes |
| 21:08.52 | eliel | russellb: I have attached to the process and didn't see the channel locked |
| 21:09.08 | russellb | so it is no longer in *CLI> core show channels |
| 21:09.08 | russellb | heh |
| 21:09.09 | eliel | also show channels shows that it is not there |
| 21:09.13 | russellb | ok. |
| 21:09.29 | russellb | is this code in trunk already? |
| 21:09.38 | eliel | no |
| 21:09.46 | russellb | can I see your patch? |
| 21:09.47 | Corydon76-lap | mosty: other than using commas instead of pipes, that looks fine |
| 21:10.22 | mosty | ok (i copied that format from a 1.4 install i have handy, that's all) |
| 21:10.39 | eliel | http://pastebin.com/d7c148092 |
| 21:10.48 | Corydon76-lap | mosty: don't forget to do the same thing to the IFTIME() function |
| 21:11.05 | mosty | yes of course |
| 21:11.16 | Corydon76-lap | Technically, timed includes, too, but I'm not really sure if anybody uses those anymore |
| 21:11.34 | seanbright | it's a bug report waiting to happen if we don't update them as well |
| 21:11.54 | eliel | russellb: sorry for uploading the patch there, but for some reason I can't access reviewboard/bugs/svn.digium.com (the problem is my provider). |
| 21:12.31 | *** join/#asterisk-dev snuff-work (n=jsewell@203.19.141.34) |
| 21:12.31 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 21:14.27 | russellb | well, you're using it properly. |
| 21:14.40 | russellb | i don't know ... might be broken debugging code |
| 21:14.46 | russellb | if that code leaks, then we have a much bigger problem |
| 21:14.54 | russellb | because that same stuff is used in a number of places |
| 21:15.18 | snuff-work | wonders if anyone has taken a look at my reviewboard post.. |
| 21:16.02 | eliel | russellb: ok, i will suppose it is working, and when finish working on this, i will review the threadstorage debugging. |
| 21:18.33 | gambler1 | Hi, sorry for interupt with this non-devel question, but I realy can not imagine the reason behind, to not have a static and dynamic realtime at the same time for example sip.conf? What's the solution if we want more * servers in a cluster? :( |
| 21:23.04 | Corydon76-lap | gambler1: I wasn't aware that you couldn't have both at the same time |
| 21:23.23 | Corydon76-lap | gambler1: who told you you couldn't have both? |
| 21:23.39 | snuff-work | at last place of work used both.. |
| 21:23.58 | snuff-work | same with dialplans |
| 21:24.01 | gambler1 | Corydon76-lap: I found that info on voip-info.org but I also tried to usein my config |
| 21:24.12 | gambler1 | Corydon76-lap with the same problem |
| 21:24.22 | Corydon76-lap | Now if you specify hosts in both, I can see that as a problem |
| 21:24.46 | Corydon76-lap | but you could specify the [general] section in static realtime, then specify hosts in dynamic realtime |
| 21:24.57 | Corydon76-lap | Seems logical enough to me |
| 21:25.39 | gambler1 | Corydon76-lap: it seams logical to me but a friend tried and gave me link http://www.voip-info.org/wiki/view/Asterisk+RealTime+Static |
| 21:25.44 | *** join/#asterisk-dev Marquis42 (n=bfhbmw0@65-127-126-34.dia.static.qwest.net) |
| 21:26.25 | lmadsen | pretty sure I've used both... |
| 21:27.05 | Corydon76-lap | gambler1: I think it means that you can't use both a static realtime file AND use a file in the directory at the same time |
| 21:27.26 | Corydon76-lap | but there shouldn't be any bar to using static realtime and dynamic realtime at the same time |
| 21:27.47 | kpfleming | just complexity of understanding the resulting configuration |
| 21:27.59 | gambler1 | hmmmm then I must be doing something wrong, I have a plain extconfig.conf with two lines |
| 21:28.03 | gambler1 | sip.conf => odbc,asterisk,ast_config |
| 21:28.05 | gambler1 | sippeers => odbc,asterisk,sippeers |
| 21:28.42 | gambler1 | and * does not read rtcachefriends=yes thats stored in general section of sip.conf in static realtime |
| 21:30.03 | gambler1 | for me it's enought info from you that's possible, I think I will find that way to do it. |
| 21:30.56 | Corydon76-lap | gambler1: do you have an /etc/asterisk/sip.conf ? |
| 21:31.10 | gambler1 | nope, I have removed sip.conf |
| 21:31.20 | Corydon76-lap | Then I don't see why it shouldn't work |
| 21:33.42 | gambler1 | I don't know, I will figure out, thank you for you help (this is the second time you helped me) :) |
| 21:33.58 | *** join/#asterisk-dev snuff-work (n=jsewell@203.19.141.34) |
| 21:33.59 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 21:35.05 | seanbright | snuff-work: i haven't seen an e-mail about your reviewboard post |
| 21:39.04 | snuff-work | mm i dont know why it wouldn't send one.. i added the asterisk-dev group to it.. |
| 21:39.31 | snuff-work | but yes.. i noticed when i added it to review board i only got a personal email |
| 21:41.45 | seanbright | snuff-work: 'asterisk' not 'asterisk-dev' |
| 21:42.15 | snuff-work | mm.. i don't rmemeber which i put.. would have to check reviewboard myself |
| 21:42.23 | seanbright | you put asterisk-dev |
| 21:42.52 | snuff-work | it was a dropdown list i thnk.. and i just chose dev |
| 21:42.58 | snuff-work | ahh well :) |
| 21:43.10 | seanbright | drop down? really? nifty |
| 21:44.47 | seanbright | snuff-work: i might be wrong. other reviews say 'asterisk-dev' |
| 21:45.16 | kpfleming | do we have an API call in asterisk already to the do equivalent of 'mkdir -p'? |
| 21:45.26 | Corydon76-lap | Yes, ast_mkdir |
| 21:45.31 | kpfleming | thanks |
| 21:45.47 | snuff-work | seanbright: i didn't set reviewers.. which is probably what i needed to do ;) |
| 21:45.56 | snuff-work | i mean ppl |
| 21:46.10 | snuff-work | who knows i dont know how to work it properly :) |
| 21:46.48 | mosty | Corydon76-lap, i have added a note with newly proposed syntax and a small use case |
| 21:47.01 | Corydon76-lap | kpfleming: returns 0 on success or errno if any part of the path failed |
| 21:47.26 | Corydon76-lap | (other than EEXIST) |
| 21:48.45 | Corydon76-lap | mosty: I'm good with that |
| 21:49.31 | Corydon76-lap | mosty: if you want to parse and store the timezone into the timespec, I'd be good with that, as well |
| 21:50.59 | Corydon76-lap | because there's currently only a single routine that parses the timespec, and if you change that one routine, then you fix the syntax everywhere it's used |
| 21:51.34 | mosty | Corydon76-lap, i will look into it |
| 21:53.42 | kpfleming | Corydon76-dig: thanks, got it |
| 22:18.45 | *** join/#asterisk-dev stephank (n=urk@2002:52c5:cf78:0:21c:c4ff:fece:ea94) |
| 22:26.05 | *** join/#asterisk-dev korihor (n=korihor@200-71-162-1.genericrev.telcel.net.ve) |
| 22:27.53 | stephank | I'm confused. Something betwen 1.4.21.2 and 1.4.22 is causing my billing to fail. Basically, our billing is a custom app, that executes Dial. Right now, with 1.4.22, chan->cdr->disposition is always set to unanswered after the Dial. |
| 22:28.08 | *** join/#asterisk-dev Deeewayne (n=Deeewayn@nat/digium/x-3c4fb93ef867b637) |
| 22:28.08 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 22:29.07 | stephank | I went through the changelog, glanced over the CDR related stuff, which all seems to be related to transfers. But I'm also wondering, if asterisk doesn't store it there at that point in time, where does it store it? The CDR itself, in my database, does show the correct hangup cause. |
| 22:31.56 | codefreeze-lap | stephank: if you want to know where CDR's are stored, it's attached to channel structure. If you want to know where it's sent to the database/backend, it's done via the "cdr_post" routine in main/cdr.c. |
| 22:33.31 | stephank | Sorry, maybe I should've phrased a question. So my chan->cdr->disposition is always no answer after a Dial. Is this now intended behavior in 1.4.22? |
| 22:43.33 | stephank | Or if that is difficult to answer, perhaps I should ask: is it at all supported to call into Asterisk API after a Dial has been executed, within a single application? |
| 22:52.35 | stephank | considers reverting CDR related patches until his problem is magically solved. :/ |
| 22:53.45 | codefreeze-lap | stephank: if that doesn't work so well, you might try checking out 1.4 svn, and see if it's solved; if not, tell me what the prob is, ... I might be able to help... |
| 22:54.15 | codefreeze-lap | oh, wait, stephank |
| 22:54.42 | codefreeze-lap | I'm reading back... ok, yes, try the latest 1.4, I committed a fix for that sort of thing. |
| 22:55.29 | *** join/#asterisk-dev sysreq (n=sysreq@unaffiliated/sysreq) |
| 22:56.18 | codefreeze-lap | There was a prob with NO_ANSWER Cdrs not getting output, not having the right disposition; see if it's better now. |
| 22:56.23 | stephank | codefreeze-lap: I'll cherry pick the changes. Murf is your username? |
| 22:56.30 | codefreeze-lap | yep |
| 23:09.53 | stephank | pfff, screw that. I'll just go with svn. :B |
| 23:12.40 | *** join/#asterisk-dev silentaudience (i=psybnc@194.105.146.253) |
| 23:41.43 | stephank | Hmmm.. 1.4 svn hangs up my call directly after I answer, with no explanation. |
| 23:49.43 | seanbright | stephank: svn merge -C -156386 http://svn.digium.com/svn/asterisk/branches/1.4 |
| 23:49.53 | seanbright | err |
| 23:49.58 | seanbright | stephank: svn merge -c -156386 http://svn.digium.com/svn/asterisk/branches/1.4 |
| 23:50.02 | seanbright | (lowercase c) |
| 23:50.29 | *** join/#asterisk-dev obnauticus (n=lol@about/windows/regular/obnauticus) |
| 23:56.56 | stephank | seanbright: wow, thanks. Is that a problem on my side or a bug? |
| 23:58.22 | stephank | besides that, I still see disposition set to unanswered, codefreeze-lap. :/ |