| 00:02.17 | Corydon76-dig | mvanbaak: Good |
| 00:05.23 | *** join/#asterisk-dev jeffspeff2 (n=jeff@c-98-240-112-228.hsd1.ky.comcast.net) |
| 00:14.33 | *** join/#asterisk-dev jeffspeff2 (n=jeff@c-98-240-112-228.hsd1.ky.comcast.net) |
| 00:18.04 | *** join/#asterisk-dev moy (n=moy@189.169.61.29) |
| 00:21.42 | snuff-work | Corydon76-dig: guess u didn't need his patch to fix ;) |
| 00:22.06 | Corydon76-dig | Description was enough |
| 00:22.32 | Corydon76-dig | Dunno why I didn't get the original notification of assignment |
| 00:23.11 | snuff-work | mm maybe because he assigned it on creation |
| 00:23.23 | Corydon76-dig | Mantis works that way |
| 00:23.41 | Corydon76-dig | I'm auto-assigned to certain issues, depending upon the category |
| 00:23.46 | snuff-work | ah |
| 00:24.13 | Corydon76-dig | It's why I know of falves11 so well... everytime he files a bug against func_odbc, I groan |
| 00:24.27 | snuff-work | hehe |
| 00:24.48 | Corydon76-dig | but it means the bug also gets immediate attention |
| 00:25.14 | snuff-work | mm nice guy has uploaded new multicast paging code |
| 00:26.51 | Corydon76-dig | Ah, multicast... wasn't that supposed to catch on 20 years before IPv6 was supposed to have caught on? |
| 00:27.14 | Corydon76-dig | (and yet still, neither have?) |
| 00:27.27 | snuff-work | multicasting is good for video.. i've used it works pretty well |
| 00:27.43 | snuff-work | http://ipv6experiment.com/ |
| 00:27.49 | Qwell | there are disk image utils that use multicast |
| 00:28.08 | snuff-work | using free porn as an incentive to get ppl to try ipv6 |
| 00:28.14 | Qwell | lol? |
| 00:28.36 | Corydon76-dig | snuff-work: still, you'd think it would be ubiquitous already |
| 00:28.58 | Corydon76-dig | It's all still treated as experimental |
| 00:29.09 | snuff-work | mm tis a shame that multicasting hasn't really got going.. |
| 00:29.33 | snuff-work | as usual its app support that's lacking more than protocol |
| 00:29.37 | Corydon76-dig | Mutlicasting assumes you can get everybody on the same schedule |
| 00:30.05 | Corydon76-dig | That's why people like unicast... they can see when they wanna see |
| 00:30.15 | snuff-work | well if ur watchin a live 'session' of something its useful |
| 00:30.17 | Corydon76-dig | It's why Tivo and MythTV are so popular |
| 00:31.28 | Corydon76-dig | Honestly, how much is live anymore? News, the Superbowl, a few sports? |
| 00:31.48 | snuff-work | mm tis true |
| 00:32.03 | Corydon76-dig | I would have said the Olympics, except that this is the first year in a long time they've been broadcast live |
| 00:32.18 | Corydon76-dig | Even so, much of it is on tape delay |
| 00:35.16 | snuff-work | mm what's the prefrence with inf loops in *.. a for(;;) seems wasteful for a while(1) |
| 00:37.28 | Qwell | 1 has to be evaluated |
| 00:37.34 | Qwell | no, I'm kidding.. I don't know |
| 00:39.38 | seanbright | compiler probably optimizes them both away |
| 00:39.45 | snuff-work | mm |
| 00:40.12 | seanbright | i _may_ be talking out of my ass, though. |
| 00:42.09 | xilun | start_of_the_loop: { body; } goto start_of_the_loop; ;) |
| 00:42.21 | Qwell | +1 |
| 00:42.29 | *** join/#asterisk-dev jeffspeff (n=jeff@c-98-240-112-228.hsd1.ky.comcast.net) |
| 00:44.52 | seanbright | both evaluate to the same asm |
| 00:44.55 | seanbright | errr |
| 00:44.58 | seanbright | compile to the same asm |
| 00:45.38 | seanbright | at least with gcc 4.1.2 |
| 00:45.42 | Qwell | O.o |
| 00:45.59 | snuff-work | mm that was lot of effort to put in seanbright |
| 00:46.08 | Qwell | seanbright: I bet they differ in ildasm |
| 00:46.11 | snuff-work | even with no optimising? |
| 00:46.19 | seanbright | snuff-work: gcc -S inf.c |
| 00:47.35 | seanbright | http://pastebin.ca/1165413 |
| 00:47.35 | seanbright | Qwell: it would have to be while (true) in C# |
| 00:47.35 | Qwell | stupid C# |
| 00:47.40 | seanbright | Qwell: and i'd bet they ended up being the same |
| 00:47.43 | Qwell | you know what my biggest gripe is with it? |
| 00:47.48 | seanbright | whazzat? |
| 00:48.01 | Qwell | switch statements, and the useless fallthrough rules |
| 00:48.06 | seanbright | ah |
| 00:48.17 | seanbright | yeah, i don't like that aspect either |
| 00:48.40 | seanbright | but those situations don't come up too often, thankfully. |
| 00:48.53 | seanbright | the interesting part about that sample paste i just made |
| 00:49.11 | seanbright | if you don't include the conditionals that break from the loops, gcc optimizes the entire second loop out entirely |
| 00:49.17 | seanbright | pretty nifty |
| 00:49.27 | Qwell | eh? |
| 00:49.43 | seanbright | unless i am reading the asm wrong |
| 00:50.07 | seanbright | doing this: for (;;) { printf("hi\n"); } for (;;) { printf("bye\n"); } |
| 00:50.16 | seanbright | gcc optimizes out the second loop |
| 00:50.38 | seanbright | and i'd assume any other statement that came after the first |
| 00:50.57 | xilun | gcc does lot of optimizations |
| 00:51.01 | Qwell | makes sense |
| 00:51.04 | xilun | dead code removal is quite easy |
| 00:51.20 | seanbright | xilun: sweet, how long have you been working on compilers? |
| 00:52.23 | xilun | not long enough, but the basic think for any now trivial compiler is to split the code into linear blocks and graph them |
| 00:52.35 | xilun | so using graph theory if a part is not reached |
| 00:52.42 | xilun | you don't keep it |
| 00:52.47 | seanbright | xilun: cool. do you have any code lying around i could look at? |
| 00:53.18 | xilun | ehm, i just read the dragon book indeed :p |
| 00:53.25 | seanbright | ohhh |
| 00:53.31 | xilun | and remember some things from compiler courses |
| 00:53.36 | seanbright | gotcha |
| 00:56.05 | xilun | but i also now gcc does lot of optimizations, i recently checked the ASM generated for a driver and it even succed in unrooling loops and statically computing its result if the length of the loop is known in advance and you only use const data (and your code is not "too much" complicated) |
| 00:56.40 | xilun | that's non trivial :p |
| 00:58.23 | snuff-work | mm unrolled loops.. possible paralisation :) |
| 02:11.07 | *** join/#asterisk-dev gones (n=gones@203.193.37.251) |
| 02:32.01 | *** join/#asterisk-dev gones (n=gones@203.193.37.251) |
| 03:28.46 | Laureano | Bye guys |
| 04:12.25 | *** join/#asterisk-dev obnauticus (n=obnautic@about/windows/regular/obnauticus) |
| 04:44.50 | *** join/#asterisk-dev CunningPike (n=arodgers@d75-155-184-81.bchsia.telus.net) |
| 05:47.04 | *** join/#asterisk-dev fabled (n=fabled@xdsl-83-150-94-239.nebulazone.fi) |
| 05:54.10 | *** join/#asterisk-dev Dovid (n=Dovid@tony09-118-62.inter.net.il) |
| 06:31.27 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 06:31.27 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:40.38 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@local.xorcom.com) |
| 06:40.38 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 07:13.59 | *** join/#asterisk-dev IgorG (n=IgorG@195.162.49.23) |
| 07:39.01 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 07:39.01 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:50.57 | *** join/#asterisk-dev dominic1 (n=dob@213.221.82.242) |
| 08:10.49 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 08:20.43 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 08:42.12 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 08:42.12 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:45.08 | *** join/#asterisk-dev oej_ (n=olle@ns.webway.se) |
| 08:46.56 | oej_ | Morning |
| 08:47.04 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:20.48 | mvanbaak | hey oej |
| 09:21.15 | oej | Hey - are you still on holiday? |
| 09:23.12 | mvanbaak | nope |
| 09:23.22 | mvanbaak | back to normal life here |
| 09:26.59 | *** join/#asterisk-dev bird_of_Luck (i=melifaro@secured.by.ipfw.ru) |
| 09:28.13 | dominic1 | hey guys, am I right that it's currently not possible to lookup which incoming channel intiated a dial to a internal channel? Tried to look up the channel of the caller while a internal device is ringing... |
| 09:28.20 | dominic1 | via ami |
| 09:32.00 | oej | What's an "internal channel" ? |
| 09:32.41 | oej | I think you can follow the AMI messages and get the proper events to figure out who was the calling part |
| 09:36.42 | dominic1 | I mean my internal sip peer |
| 09:36.51 | dominic1 | SIP/myphone-channelid |
| 09:59.04 | *** join/#asterisk-dev agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 10:10.39 | *** join/#asterisk-dev pabelanger (n=pabelang@OTWAON23-1242541604.sdsl.bell.ca) |
| 10:31.35 | *** join/#asterisk-dev ramonpeek (n=ramonpee@e135042.upc-e.chello.nl) |
| 10:34.24 | ramonpeek | Goodmorning, goodevening, Goodnight,,, oh well whatever your timezone is :-) |
| 10:34.55 | ramonpeek | Anybody there to discuss an issue with Local channels and copying of variables. |
| 10:43.06 | *** join/#asterisk-dev JunK-Y (n=junky@modemcable156.137-20-96.mc.videotron.ca) |
| 10:43.25 | *** part/#asterisk-dev agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 10:46.09 | *** join/#asterisk-dev JoZu (i=asdf@84.120.221.158.dyn.user.ono.com) |
| 10:46.24 | *** part/#asterisk-dev JoZu (i=asdf@84.120.221.158.dyn.user.ono.com) |
| 11:00.29 | *** join/#asterisk-dev _ys (i=yuri@91.151.196.254) |
| 11:14.37 | *** join/#asterisk-dev eliel (n=eliel@200.61.172.61) |
| 11:28.37 | mvanbaak | hey eliel |
| 11:28.46 | eliel | good morning |
| 11:31.06 | eliel | Did you receive the build_syntax patch? |
| 11:31.06 | mvanbaak | I did not have time to look at your patch yet |
| 11:31.15 | eliel | no problem |
| 11:31.23 | eliel | I have a few questions: |
| 11:31.26 | mvanbaak | yup, it's in my mailbox, flagged, and has prio once I'm done here at work |
| 11:32.33 | eliel | 1) Do you think we should continue having one file for each language or a file with all the languages available? |
| 11:33.09 | mvanbaak | 1 file for each language |
| 11:33.10 | eliel | 2) The name of the function could determine also for which version of the application where written, like app_dial/1.4 |
| 11:33.14 | mvanbaak | easier for the translators |
| 11:34.18 | eliel | And check that and produce a warning if asterisk version doesnt match documentation version |
| 11:35.04 | mvanbaak | hhmm |
| 11:35.11 | mvanbaak | maybe we should embed that in the filename |
| 11:35.24 | mvanbaak | instead of in the .c file xml stuff |
| 11:35.38 | mvanbaak | core14-en.xml |
| 11:35.48 | mvanbaak | or |
| 11:35.52 | mvanbaak | core1420-en.xml |
| 11:35.57 | mvanbaak | whatever |
| 11:35.58 | *** join/#asterisk-dev dioedu (n=dioedu@201.7.117.114) |
| 11:36.14 | mvanbaak | that way we dont have to touch all the C files when we make a new release |
| 11:36.48 | eliel | that makes sense |
| 11:37.16 | eliel | and one other thing, 'core' could be named 'documentation' |
| 11:37.23 | eliel | more self explained... |
| 11:38.04 | mvanbaak | we picked core- so we can have out-of-tree documentation files |
| 11:38.09 | mvanbaak | like for the -addons |
| 11:38.24 | mvanbaak | and 3rd party modules |
| 11:40.08 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 11:40.17 | eliel | ok |
| 11:43.24 | tzafrir_laptop | How do you know the version of SVN? |
| 11:43.42 | mvanbaak | svn info |
| 11:43.53 | tzafrir_laptop | but what branch? |
| 11:44.10 | mvanbaak | svn info |
| 11:44.21 | tzafrir_laptop | tricky |
| 11:45.00 | tzafrir_laptop | won't work for me in git |
| 11:45.16 | mvanbaak | have a look at the commitbot |
| 11:45.25 | mvanbaak | there's some shell magic to find the branchname |
| 11:45.58 | *** join/#asterisk-dev shido6 (n=shido6@209.114.208.192) |
| 11:52.45 | eliel | take a look at build_tools/make_version |
| 11:58.18 | mvanbaak | hhmm, your build_syntax is very simular to mine. |
| 11:58.22 | mvanbaak | this is scary |
| 11:58.47 | mvanbaak | btw, nice trick with the GOTONEXT |
| 11:59.04 | mvanbaak | I had it coded inline |
| 11:59.54 | mvanbaak | btw, are you sure you want to print the arguments in the syntax line ? |
| 12:00.09 | mvanbaak | have a look at app_dial.c |
| 12:00.27 | mvanbaak | ah well, I'll have to test this |
| 12:00.59 | mvanbaak | I'll test it when I'm home |
| 12:01.06 | mvanbaak | I really should get some work done here |
| 12:03.34 | eliel | mvanbaak: I don't want to print the arguments in the syntax, I like a cleaner syntax like it is right now |
| 12:08.31 | eliel | mvanbaak: Well having the same code means that probably we have found a soulution that works |
| 12:10.30 | eliel | This is the output of Goto: Goto([[context,]extension,]priority) |
| 12:10.59 | eliel | and this is from Dial: Dial(Technology/Resource[,timeout[,options[,URL]]]) |
| 12:11.13 | *** join/#asterisk-dev russellb (n=russellb@asterisk/developer-and-stable-maintainer/drumkilla) |
| 12:11.13 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 12:12.19 | mvanbaak | eliel: yeah, that's how I like it as well |
| 12:33.48 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:33.48 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 12:38.01 | seanbright | russellb: when you get a chance, can i get an executive decision as to whether 13281 should go into 1.4 (i'm guessing no) |
| 12:38.05 | seanbright | M13281 |
| 12:38.06 | MuffinMan | [assigned] [Asterisk] CDR/cdr_tds 0013281: CDR TDS does notbreport the userfield contents,as cdr_odbc does reported by falves11 (Karma: -3.75) http://bugs.digium.com/view.php?id=13281 |
| 12:38.25 | *** join/#asterisk-dev Pazzo (n=ugelt@reserved-225136.rol.raiffeisen.net) |
| 12:39.08 | seanbright | woops |
| 12:39.20 | seanbright | nevermind, i just realized that although it was assigned to me, snuffy wrote the patch |
| 12:39.29 | seanbright | i'll go ahead and reassign |
| 12:40.10 | snuff-home | heh seanbright only reason i wrote one |
| 12:40.17 | snuff-home | was almost too easy to add ;) |
| 12:40.31 | snuff-home | and i didn't want to look at my non jabber progress |
| 12:41.18 | seanbright | well in the future, if someone takes ownership of an issue, make sure to let them know you are writing a patch so that work is not duplicated |
| 12:43.42 | russellb | why is a decision needed? |
| 12:44.01 | seanbright | shrugs |
| 12:44.08 | russellb | compatibility reasons? |
| 12:44.12 | snuff-home | seanbright: i didn't even realise it had been assigned to u.. until after i posted |
| 12:44.32 | seanbright | well, i wouldn't consider the column's absence in 1.4 to be a bug |
| 12:44.36 | russellb | right. |
| 12:44.41 | snuff-home | i'm guessin it auto assigns for cdr_tds to u? |
| 12:44.49 | russellb | Ok, well how about we add it to trunk and 1.6.0, and update UPGRADE.txt |
| 12:44.51 | seanbright | snuff-home: no, i manually did it and wrote a patch |
| 12:44.58 | seanbright | russellb: alrighty |
| 12:45.00 | snuff-home | bad.. |
| 12:45.44 | seanbright | snuff-home: i'll let you commit and such, make sure to upgrade UPGRADE.txt |
| 12:45.52 | seanbright | err |
| 12:46.00 | seanbright | update UPGRADE.txt, rather. |
| 12:46.05 | russellb | he doesn't have commit yet |
| 12:46.08 | snuff-home | i have no access.. |
| 12:46.09 | seanbright | oh |
| 12:46.20 | seanbright | ok, well then i will use my patch |
| 12:46.28 | snuff-home | u can scrap my thing.. it only took me 5 min |
| 12:46.35 | seanbright | done and done |
| 12:48.54 | *** join/#asterisk-dev DagMoller (n=aguirre@unaffiliated/dagmoller) |
| 13:08.49 | *** join/#asterisk-dev shido6 (n=shido6@209.114.208.192) |
| 13:35.56 | oej | russellb: What the ??? is going on? |
| 13:40.52 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.95.130) |
| 13:51.14 | oej | And suddenly there was silence... Interesting project this. |
| 13:51.26 | oej | At least, it used to be... :-( |
| 13:51.44 | seanbright | i have nothing to contribute to the conversation - i am confused as well. |
| 13:53.06 | oej | Someone doesn't know the basics of communication here. |
| 13:54.12 | ctooley | oej, You expected a response directed at a single person to generate active conversation from everyone? |
| 13:55.00 | snuff-home | mm seanbright with the 'no userfield' for cdr_tds.. all other main cdr engines have userfield.. aside from custom which i will check now |
| 13:59.53 | *** join/#asterisk-dev asteriskmonkey (n=asterisk@69.77.169.14) |
| 14:01.00 | *** join/#asterisk-dev codefreeze-lap (n=murf@216.166.159.235) |
| 14:01.00 | *** mode/#asterisk-dev [+o codefreeze-lap] by ChanServ |
| 14:01.54 | oej | Ctooley: I just got upset and yelled publicly |
| 14:02.24 | lmadsen | oej: perhaps he had to run off to a meeting? |
| 14:02.42 | ctooley | probably |
| 14:02.43 | oej | What do I care. He hasn't responded to my upset e-mail a few days ago. |
| 14:02.48 | oej | He won't respond now either. |
| 14:03.02 | oej | Russell is just forcing me to leave. |
| 14:03.03 | lmadsen | perhaps some sort of a phone call would make more sense then? |
| 14:03.17 | lmadsen | doesn't really know... is simply trying to keep peace |
| 14:11.42 | oej | wish more people had that goal |
| 14:12.13 | oej | I have to reconsider my plans for Astricon... This is serious. |
| 14:12.32 | oej | Anyway, I'm leaving for today. The rain just arrived, so it's time to hit the road :-) |
| 14:12.34 | oej | Later |
| 14:12.41 | lmadsen | perhaps you can speak with John Todd? |
| 14:13.53 | oej | I've tried calling him twice today... |
| 14:13.57 | oej | But thanks, Leif. |
| 14:14.06 | lmadsen | well... it's only 9:13am CST |
| 14:14.34 | lmadsen | and he seems like a late night worker, so he probably doesn't really start until 10am or so would be my guess |
| 14:14.49 | lmadsen | and I think he was in Chicago last week... |
| 14:15.15 | oej | Yes, we've been trying to reach each other for a while. |
| 14:15.37 | lmadsen | I can try and let him know you were looking for him if you wish |
| 14:15.44 | oej | I've been on holiday, so I had problems with being in control of scheduling... Better phrased: I had no control at all over scheduling :-) |
| 14:17.36 | oej | Thanks Leif, But I've left messages all over the place. He can't miss an upset Johansson... |
| 14:18.35 | lmadsen | oej: ahhh... well then you can't really blame John for not being available :) |
| 14:18.54 | oej | No, I don't blame John for everything. |
| 14:18.56 | lmadsen | perhaps timing will work out this time around though |
| 14:19.03 | lmadsen | sorry, I didn't mean to imply that you did |
| 14:19.08 | oej | On the other hand, I wish he had 48 hours a day to do the things I want him to do :-) |
| 14:19.14 | lmadsen | don't we all ;) |
| 14:20.22 | oej | Russellb just committed code, so he's not in a meeting. |
| 14:20.32 | oej | He's just hiding... Poor kid. |
| 14:20.36 | *** part/#asterisk-dev oej (n=olle@ns.webway.se) |
| 14:27.26 | seanbright | is not a fan of this |
| 14:29.25 | lmadsen | no one really is, so lets move on and talk about development! |
| 14:30.10 | seanbright | weee! |
| 14:33.01 | seanbright | snuff-home: done |
| 14:34.10 | seanbright | snuff-home: the only difference in our patches is that i check for the existence of the column and if it exists, i store it. if it doesn't exist, i don't store it. that way we are backwards compatible. |
| 14:34.11 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 14:41.14 | *** join/#asterisk-dev joetester2 (n=chatzill@216.191.34.13) |
| 14:41.37 | seanbright | lmadsen: i think you assigned the wrong bug to me |
| 14:42.32 | seanbright | you mentioned 13187 and then assigned 13279 to me |
| 14:42.38 | lmadsen | really? weird.. |
| 14:42.48 | lmadsen | did I perhaps type the wrong bug number in? most likely :) |
| 14:42.50 | lmadsen | I will resolve, thx! |
| 14:42.57 | seanbright | cool |
| 14:43.00 | lmadsen | I phat fingers the keyboard most likely |
| 14:43.23 | seanbright | ah |
| 14:48.25 | jsmith | lmadsen: "The fingers you have used to dial this number are too fat. To obtain a special dialing wand, mash the keypad now." |
| 14:48.41 | lmadsen | LOL |
| 14:48.45 | lmadsen | nicely done jsmith :) |
| 14:48.56 | lmadsen | I love the simpsons |
| 14:48.59 | jsmith | lmadsen: It wasn't me... it was the Simpsons |
| 14:49.11 | jsmith | But that's one of my favorites... |
| 14:49.14 | lmadsen | but you used the reference.. :) |
| 14:49.17 | lmadsen | oh ya... that's a great one |
| 14:54.33 | ctooley | Yeah! Ralph 2008! |
| 14:54.42 | ctooley | Wiggum that is. :) |
| 14:55.41 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 14:55.41 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 14:57.17 | lmadsen | jpeeler: hail! |
| 14:58.11 | jpeeler | lmadsen: hello! |
| 14:59.42 | *** join/#asterisk-dev Corydon76-lap (n=Corydon7@pdpc/supporter/bronze/Corydon76-home) |
| 14:59.42 | *** mode/#asterisk-dev [+o Corydon76-lap] by ChanServ |
| 15:08.53 | ramonpeek | Anybody here who would like to briefly discuss a possible issue with Local channels and copying of variables? |
| 15:10.31 | lmadsen | ramonpeek: you can probably just start the discussion, and if someone can comment they will. If it is more of an indepth discussion, the appropriate place would be the asterisk-dev mailing list |
| 15:12.05 | ramonpeek | I'll keep it short: When I perform the CLI command "show channel SIP/100-saj22321" I often see duplicate variables being mentioned. |
| 15:12.32 | ramonpeek | I noticed thi happens when a bridge copies the Local channel variables back into the bridged channel |
| 15:12.56 | ramonpeek | however, when requested for a variable in the dialplan you always get the right value. |
| 15:13.10 | ramonpeek | So, it's only a small issue... |
| 15:13.44 | ramonpeek | But the question is, whether is worth creating a bugtracker issue for it? |
| 15:14.36 | ramonpeek | I know of many issue concerning the copying of variables during a bridge, just read the code and you'll find some remarks. |
| 15:15.00 | Corydon76-lap | ramonpeek: are you using Gosub and local variables? |
| 15:15.09 | ramonpeek | So perhaps this is known behaviuor or accepted behaviuor.. |
| 15:15.22 | ramonpeek | No... |
| 15:15.28 | Corydon76-lap | AEL? |
| 15:15.31 | ramonpeek | No.. |
| 15:15.46 | Corydon76-lap | Then it probably shouldn't be happening |
| 15:15.56 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 15:15.58 | ramonpeek | OK |
| 15:16.23 | Corydon76-lap | There are legitimate reasons why you might have duplicated variables like that, but I've just enumerated them |
| 15:16.50 | lmadsen | actually, I've seen that too, but sometimes I get different values, and only the last one in the stack is the value I can get |
| 15:17.11 | Corydon76-lap | It's called pushvar semantics |
| 15:17.14 | lmadsen | ya |
| 15:17.39 | ramonpeek | Not really, they only thing that is special about is that the variables are set like Set(_VARIABLE=bla) |
| 15:17.39 | Corydon76-lap | and it's very helpful for creating local variables |
| 15:18.17 | ramonpeek | So with inheritance... (was looking for that word, but could think of it so soon ;-) |
| 15:19.15 | ramonpeek | It's indeed true that you can only get the last value on the stack. |
| 15:19.18 | Corydon76-lap | On the first end of a Local channel, the variables are simply copied |
| 15:19.44 | Corydon76-lap | This is done so that inheritance works correctly on the second channel |
| 15:20.10 | ramonpeek | The question is whether we should display the other values when soem performs a "show channel" command |
| 15:20.20 | ramonpeek | soem =someone |
| 15:20.39 | lmadsen | Corydon76-lap: is there any check that when a variable is copied across, and an existing variable with the same name exists, to merge the values? |
| 15:20.39 | Corydon76-lap | ramonpeek: I wouldn't mess with it |
| 15:20.56 | Corydon76-lap | lmadsen: nope, just a straight copy |
| 15:21.10 | lmadsen | ok, that would explain why I'm seeing what I'm seeing (and what ramonpeek is seeing) |
| 15:21.12 | Corydon76-lap | lmadsen: should be same order and everything |
| 15:21.20 | lmadsen | yep, that makes sense |
| 15:21.36 | lmadsen | now I understand why I see that in my 1600 line dialplan :) |
| 15:21.50 | ramonpeek | it is indeed the same order, and everything is working fine |
| 15:22.19 | Corydon76-lap | If it ain't broke..... |
| 15:22.23 | lmadsen | :) |
| 15:22.43 | ramonpeek | But when I perform a "show channel" command i often get a "buffer limit exceeded" warning. I wonder if it only affects the CLI command |
| 15:23.06 | ramonpeek | Too many variables.. I know :-) |
| 15:23.41 | Corydon76-lap | setec astronomy |
| 15:25.39 | ramonpeek | So... what shall I do, create a bugtracker issue or not? |
| 15:26.03 | Corydon76-lap | Nah |
| 15:26.26 | Corydon76-lap | btw, the issue of too many variables is fixed in 1.6 |
| 15:26.51 | Corydon76-lap | It'll display all of them, up to available memory |
| 15:27.30 | ramonpeek | OK, I'll keep in mind for in case I might find another issue that might relate to this.... for now I'll leave it as "acceptable behaviour". |
| 15:28.45 | Corydon76-lap | It's not really broken |
| 15:28.52 | Corydon76-lap | AFAICT |
| 15:29.06 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 15:35.35 | *** part/#asterisk-dev ramonpeek (n=ramonpee@e135042.upc-e.chello.nl) |
| 15:51.01 | *** join/#asterisk-dev jameswf-home (n=james@dsl093-157-131.phx1.dsl.speakeasy.net) |
| 15:55.57 | *** join/#asterisk-dev jtodd (i=eur9a0as@ns.fox-den.com) |
| 15:55.57 | *** mode/#asterisk-dev [+o jtodd] by ChanServ |
| 15:58.40 | Corydon76-lap | join #hackerconsortium |
| 15:59.01 | Corydon76-lap | Stupid keyboard |
| 16:11.52 | *** join/#asterisk-dev ctooley_ (n=ctooley@doc-72-47-33-50.maryville.mo.cebridge.net) |
| 16:15.03 | *** join/#asterisk-dev chackal_sjc (n=pet@200-168-20-217.dsl.telesp.net.br) |
| 16:15.07 | chackal_sjc | hey guys |
| 16:15.13 | chackal_sjc | does anyone here use libiax??? |
| 16:15.17 | chackal_sjc | I need some help to compile it |
| 16:15.20 | russellb | that code is unmaintained ... |
| 16:15.26 | russellb | I wouldn't use it |
| 16:15.30 | chackal_sjc | libiax?? |
| 16:15.32 | russellb | I would recommend using iaxclient, instead |
| 16:15.33 | russellb | yes |
| 16:15.42 | chackal_sjc | really, why? |
| 16:15.48 | russellb | shrugs |
| 16:16.02 | chackal_sjc | iaxclient is a lib as well?? |
| 16:16.11 | russellb | yes, iaxclient is an actively developed iax library |
| 16:16.22 | russellb | with a bunch of other stuff, too, it's like ... a softphone minus the interface |
| 16:16.29 | russellb | so, you may only need parts of what they have |
| 16:16.31 | chackal_sjc | do you know where can I download it? |
| 16:16.35 | russellb | but it is what is current |
| 16:16.37 | russellb | google ;) |
| 16:16.41 | Qwell | I think it's on SF |
| 16:16.42 | russellb | iaxclient.sourceforge.net probably |
| 16:16.52 | chackal_sjc | okay |
| 16:17.10 | chackal_sjc | because I'm developing an iax sip software |
| 16:17.21 | seanbright | does.not.compute. |
| 16:17.45 | chackal_sjc | Currently we are using sflphone-iax for IAX and libeXosip2 for SIP |
| 16:18.17 | chackal_sjc | For IAX, we want replace sflphone-iax by using common IAX library libiax |
| 16:18.32 | chackal_sjc | but I will take a look on iaxclient |
| 16:18.36 | russellb | i would go for iaxclient, yep |
| 16:23.35 | chackal_sjc | russellb: wich versino? |
| 16:23.40 | chackal_sjc | the stable or the beta? |
| 16:23.55 | russellb | shrugs |
| 16:23.57 | russellb | whicheve |
| 16:23.59 | chackal_sjc | 2.0.2 or 2.1.beta3 ? |
| 16:23.59 | russellb | whichever* |
| 16:24.08 | russellb | I'm sure the beta is fine |
| 16:24.15 | chackal_sjc | okay, good |
| 16:26.33 | russellb | with the usual "beta" caveats attached |
| 16:39.03 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 16:45.23 | *** join/#asterisk-dev pjezek (n=pj@193.85.164.154) |
| 16:50.47 | pjezek | I would like to ask, if is correct, that asterisk resends SIP/OK w/SDP when call is answered, even if it's correctly ACKed from other party |
| 16:51.13 | *** part/#asterisk-dev korihor (n=korihor@190.78.32.60) |
| 16:57.51 | pjezek | I have suspiction, that multiple SIP/OK resending starts appearing after issue "500ms delay in SIP messages forwarding" was resolved (bugreport 0012708) |
| 17:01.51 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 17:15.33 | *** part/#asterisk-dev DarKnesS_WolF (n=sherif@unaffiliated/sherif) |
| 17:31.09 | *** join/#asterisk-dev Schmooze (n=Schmooze@rrcs-67-53-189-178.west.biz.rr.com) |
| 17:36.44 | *** join/#asterisk-dev chackal_sjc (n=pet@200-168-20-217.dsl.telesp.net.br) |
| 17:37.17 | chackal_sjc | guys |
| 17:37.34 | chackal_sjc | did anyone compile audioport here? |
| 17:37.35 | Qwell | yes? |
| 17:37.47 | Qwell | portaudio? |
| 17:37.52 | chackal_sjc | yes, sorry |
| 17:37.57 | Qwell | yes.. |
| 17:38.04 | chackal_sjc | my configure is ok |
| 17:38.10 | chackal_sjc | but its not compiling |
| 17:38.14 | Qwell | portaudio itself? |
| 17:38.18 | chackal_sjc | collect2: ld returned 1 exit status |
| 17:38.19 | chackal_sjc | yes |
| 17:38.25 | Qwell | have you considered asking them why that might be? |
| 17:38.44 | chackal_sjc | because I need compile portaudio to compile iaxclient |
| 17:38.57 | chackal_sjc | Qwell: ok, where? there is no channel |
| 17:39.03 | Qwell | I don't know |
| 17:39.13 | chackal_sjc | did you compile iaxclient? |
| 17:39.23 | Qwell | no |
| 17:40.34 | chackal_sjc | hmm |
| 17:40.46 | chackal_sjc | how did you compile portaudio?? |
| 17:40.58 | Qwell | I followed the instructions in the README |
| 17:45.05 | *** join/#asterisk-dev ccesario (n=ccesario@linux.unialco.com.br) |
| 17:45.28 | tzafrir_laptop | chackal_sjc, first-off, this is a question more relevant to #asterisk, if at all. and also: |
| 17:45.56 | tzafrir_laptop | if you ask about a problem, give some information to troubleshoot it |
| 17:46.12 | tzafrir_laptop | What operating system (e.g.: linux distribution) do you use? |
| 17:46.30 | tzafrir_laptop | What version of portaudio do you try to build? |
| 17:46.52 | tzafrir_laptop | What error do you get? |
| 17:47.21 | tzafrir_laptop | posting a trace of the error and the warnings before it is a good idea (or maybe of the complete build attempt) |
| 17:48.17 | chackal_sjc | yes |
| 17:48.23 | chackal_sjc | one sec |
| 17:51.34 | chackal_sjc | I'm installing jack |
| 17:51.46 | chackal_sjc | I think it's the problem |
| 17:52.04 | chackal_sjc | I use opensuse11 amd64 by the way |
| 17:56.34 | *** join/#asterisk-dev chackal_sjc (n=pet@200-168-20-217.dsl.telesp.net.br) |
| 18:05.38 | *** join/#asterisk-dev joetester2 (n=chatzill@216.191.34.13) |
| 18:15.55 | *** join/#asterisk-dev DarKnesS_WolF (n=sherif@unaffiliated/sherif) |
| 18:53.05 | *** join/#asterisk-dev korihor (n=korihor@201.211.168.130) |
| 18:54.28 | *** join/#asterisk-dev ariel_ (n=ariel_@74.8.35.6) |
| 19:02.01 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 19:19.05 | *** part/#asterisk-dev chackal_sjc (n=pet@200-168-20-217.dsl.telesp.net.br) |
| 19:31.45 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 19:31.45 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 19:32.08 | *** join/#asterisk-dev sruffell (n=sruffell@conference/asterisk/x-efe0acde5bf0425e) |
| 19:32.08 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 20:01.52 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 20:12.35 | seanbright | wow |
| 20:12.36 | seanbright | ok |
| 20:12.51 | seanbright | apparently assigning bugs means exactly squat |
| 20:13.02 | seanbright | that's 2 for 2 today :) |
| 20:14.48 | seanbright | ah well. |
| 20:14.52 | mvanbaak | eh ? |
| 20:15.31 | *** join/#asterisk-dev shido6 (n=shido6@209.114.208.192) |
| 20:15.54 | jsmith | seanbright: Yeah... it's not ideal, that's for sure. |
| 20:16.04 | jsmith | seanbright: Feel free to assign bugs to me -- you know I'll never resolve them! |
| 20:19.28 | seanbright | Corydon76-dig: in your patch to vmail.cgi, you didn't add a call to check_login_users |
| 20:19.35 | seanbright | just fyi |
| 20:19.55 | mvanbaak | eliel: your patch is in |
| 20:20.37 | Corydon76-lap | seanbright: ah |
| 20:31.21 | mvanbaak | IAXVAR() is only for variables presented by the remote end correct ? |
| 20:32.10 | mvanbaak | you can read stuff from the remote end, and write stuff locally that the remote end can read |
| 20:32.14 | mvanbaak | if I'm correct |
| 20:35.54 | eliel | mvanbaak: great! |
| 20:38.17 | eliel | mvanbaak: I think we need to focus on fixing the output, to be more clean |
| 20:39.42 | mvanbaak | yup |
| 20:39.44 | mvanbaak | it's a mess |
| 20:39.53 | jsmith | agrees |
| 20:40.14 | jsmith | So, while we're on that topic, let me throw out a couple of ideas |
| 20:40.20 | mvanbaak | k |
| 20:40.23 | mvanbaak | shoot |
| 20:40.33 | jsmith | What if we use ANSI formatting for tags like <replaceable> and <literal> |
| 20:40.55 | jsmith | As opposed to putting quotes or angle brackets around them |
| 20:41.24 | jsmith | (or maybe fall back to quotes and angle brackets if they have set nocolor=yes in asterisk.conf) |
| 20:42.43 | mvanbaak | do we put quotes around them now ? |
| 20:42.46 | mvanbaak | not that I know |
| 20:44.53 | eliel | jsmith: What is the meaning of a <literal> node? |
| 20:45.48 | jsmith | eliel: Literal means just that... that you literally mean what's inside that node. |
| 20:45.56 | mvanbaak | ah |
| 20:46.10 | eliel | and replaceable? |
| 20:46.19 | mvanbaak | and <replacebale> means it's just a string that should be replaced by something real |
| 20:46.27 | jsmith | eliel: For example: <para>This application will send the caller to the <literal>s</literal> extension</para> |
| 20:46.43 | jsmith | mvanbaak: Yeah... <replaceable> means "replace this with the actual value of that option" |
| 20:47.01 | mvanbaak | like: <replaceable>Technology</replaceable> means Technology should by SIP or IAX2 or SKINNY or whatever |
| 20:47.11 | jsmith | mvanbaak: Exactly. |
| 20:47.29 | mvanbaak | ah |
| 20:47.29 | jsmith | mvanbaak: You use it that way both in the syntax *and* the description. |
| 20:47.35 | mvanbaak | makes more sense now |
| 20:47.37 | eliel | ok, now I understand |
| 20:48.09 | mvanbaak | do we really want to go that far for a 'core show application Dial' ? |
| 20:48.19 | mvanbaak | to print that in different colors etc ? |
| 20:49.34 | jsmith | Absolutely! |
| 20:49.34 | mvanbaak | gheh |
| 20:49.34 | mvanbaak | ok |
| 20:49.34 | jsmith | It makes it *much* easier for the beginner to tell what we're talking about. |
| 20:49.34 | jsmith | It's like the difference between: |
| 20:49.35 | jsmith | <PROTECTED> |
| 20:49.35 | mvanbaak | 'rasterisk needs to be run on an fbdev enabled terminal' |
| 20:49.36 | jsmith | and |
| 20:49.55 | jsmith | <PROTECTED> |
| 20:50.24 | jsmith | The idea is to set those elements apart, so that they're easy to spot and say "Hey, that's one of the parameters to the application. I get it!" |
| 20:51.11 | eliel | grgrrr |
| 20:51.23 | eliel | heh |
| 20:52.19 | eliel | jsmith: Can you give a full description of every tags that you would like and which chars should be used if no colors in the terminal to print it? |
| 20:52.34 | seanbright | it's also easier to publish dead-tree type documentation from that too :) |
| 20:53.04 | jsmith | seanbright: Ssshhh! That's my secret! Don't tell anyone! |
| 20:53.09 | seanbright | hehe |
| 20:53.16 | jsmith | eliel: Yes, I can do that. |
| 20:53.18 | seanbright | i'm onto you |
| 20:53.26 | jsmith | seanbright: Scary! |
| 20:54.01 | eliel | Yes, we can implement latext like tags to then have a one to one transition :-) |
| 20:54.02 | jsmith | eliel: I think right now I'm only using literal, replaceable, filename, and emphasis. I can't think of any others |
| 20:54.19 | jsmith | eliel: You know that you can convert DocBook to LaTeX, right? |
| 20:54.22 | jsmith | ducks |
| 20:55.01 | eliel | heh, then we can create the script to generate tfot for 1.6 :-) |
| 20:56.23 | eliel | M0013283 |
| 20:56.25 | MuffinMan | [confirmed] [Asterisk] Documentation 0013283: [patch] Coding Guidelines in TeX format. reported by eliel (Karma: +160.50) http://bugs.digium.com/view.php?id=0013283 |
| 20:56.25 | jsmith | eliel: <emphasis role="strong">Exactly</emphasis> |
| 20:57.42 | eliel | heh |
| 21:02.26 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 21:05.02 | Corydon76-lap | eliel: \textbf{Exactly} |
| 21:07.06 | eliel | Corydon76-lap: Heh, \verb*|print hello()| |
| 21:07.55 | Corydon76-lap | jsmith: see how much shorter and more concise TeX is? |
| 21:07.58 | Corydon76-lap | ducks |
| 21:08.31 | eliel | Donald Knuth ++ |
| 21:08.52 | jsmith | Corydon76-lap: I'm not disagreeing with you one bit on those points |
| 21:09.03 | jsmith | Corydon76-lap: TeX is *very* nice for what it does |
| 21:09.33 | jsmith | Corydon76-lap: What DocBook brings to the table (in exchange for ugly XML tags and all) is to separate the business layer from the presentation layer, so to speak. |
| 21:12.41 | lmadsen | Corydon76-lap: ping... |
| 21:12.55 | Corydon76-lap | pong |
| 21:13.17 | lmadsen | so... I have a question from our earlier discussion re: the double variables when using a Local channel and a transfer happens... |
| 21:15.46 | lmadsen | same idea, but this time its just a transfer, and there is no Local channel involved. When I do the transfer, I set a variable called MONITOR_FILENAME, and then an attended transfer happens. When the call between B --> C happens, I run the same logic (Macro) which sets the same variable. When I perform the transfer and A is talking to C, I have a DumpChan() with two MONITOR_FILENAMEs, but with two separate values. |
| 21:16.03 | lmadsen | The problem I'm having, is I only have access to one of those variables, and of course its not the one I want... |
| 21:16.28 | lmadsen | It seems to be whatever variable is listed first in the stack is the variable value I end up getting |
| 21:16.37 | Corydon76-lap | Correct |
| 21:17.03 | lmadsen | and I can't seem to figure out how to get the value I'm looking for since the two channels are unrelated, so I can't do a check to see if the variable exists first |
| 21:17.06 | Corydon76-lap | That's precisely how we hide variables on the stack |
| 21:17.50 | lmadsen | any idea how I can get access to the value I'm trying to not hide? |
| 21:18.13 | Corydon76-lap | I have an idea, but I don't like it |
| 21:18.26 | lmadsen | well... unfortunately this is ABE, so it can't even be a code change... |
| 21:18.43 | Corydon76-lap | Another module? |
| 21:19.01 | Corydon76-lap | PEEK(<n>,<varname) |
| 21:19.03 | lmadsen | well, I want to see if there is any method of doing it with the tools already at my disposal... |
| 21:19.12 | Corydon76-lap | No, there is not |
| 21:19.23 | lmadsen | Corydon76-lap: perhaps... or even a modification to app_stack... ? |
| 21:19.32 | Corydon76-lap | and it was intentional |
| 21:19.35 | lmadsen | although this PEEK() you speak of would do it |
| 21:19.40 | lmadsen | I just need to read, not writw |
| 21:19.41 | lmadsen | write* |
| 21:19.52 | lmadsen | so it seems like a fairly safe operation |
| 21:19.57 | Corydon76-lap | No, you won't be able to write, anyway |
| 21:20.03 | lmadsen | makes sense |
| 21:20.13 | mvanbaak | question |
| 21:20.25 | Corydon76-lap | I'm not sure I like the name or the implication, though |
| 21:20.29 | mvanbaak | should the <synopsis> text be in a <para> tag as well ? |
| 21:20.52 | mvanbaak | <synopsis><para>Do nothing</para></synopsis> ? |
| 21:20.55 | Corydon76-lap | Question, though... |
| 21:21.08 | lmadsen | sure |
| 21:21.26 | Corydon76-lap | If you do a PEEK(1,foo) and only one foo exists on the stack, should it return blank or the last one? |
| 21:21.56 | lmadsen | uhhh... do you mean PEEK(2,foo) ? |
| 21:22.04 | lmadsen | if there is one, and I say one... I should get.... one.... ? |
| 21:22.11 | Corydon76-lap | PEEK(0,foo) is the same as foo |
| 21:22.20 | lmadsen | oh, ok, starting from 0 count then |
| 21:22.23 | mvanbaak | yup |
| 21:22.30 | mvanbaak | I think it should return blank |
| 21:22.32 | lmadsen | in that case, then I would say return null |
| 21:22.35 | Corydon76-lap | where n is how many to lift up and peek under |
| 21:23.13 | lmadsen | While($[${EXISTS(${PEEK(${X},MY_VAR)})}]) |
| 21:23.18 | mvanbaak | if you return the last one, it's easy to make the mistake to think: 'if this is in item2, we need the stuff in item1' |
| 21:23.29 | Corydon76-lap | I really hate EXISTS |
| 21:23.36 | lmadsen | really? works good for me |
| 21:23.42 | Corydon76-lap | it does not do what it sounds like it does |
| 21:23.52 | lmadsen | I know its just the inverse of ISNULL() |
| 21:24.07 | Corydon76-lap | Yes, and ISNULL doesn't do that, either |
| 21:24.20 | lmadsen | anyways... :) |
| 21:24.28 | mvanbaak | jsmith: still here ? |
| 21:24.50 | Corydon76-lap | Neither can distinguish between a variable that is zero-length versus a non-existant variable |
| 21:24.59 | *** join/#asterisk-dev obnauticus (n=obnautic@about/windows/regular/obnauticus) |
| 21:25.14 | lmadsen | Corydon76-lap: ah, gotcha -- so far, for me, that hasn't mattered |
| 21:25.20 | Corydon76-lap | Afternoon, obnoxious |
| 21:25.27 | jsmith | mvanbaak: Yeah, more more less... |
| 21:25.38 | jsmith | mvanbaak: What can I help with? |
| 21:25.41 | mvanbaak | jsmith: you think the synopsis line should be in <para> tags as well ? |
| 21:25.49 | mvanbaak | the <description> now has to be |
| 21:25.53 | jsmith | mvanbaak: Naw... as it's not free-form text |
| 21:26.11 | jsmith | mvanbaak: But I really don't have a strong opinion either way... |
| 21:26.40 | jsmith | My gut feeling is to use <para> whenever there's free-form text that could have one *or more* paragraphs |
| 21:26.53 | mvanbaak | ok |
| 21:27.01 | mvanbaak | so synopsis should be ok without <para> |
| 21:27.15 | mvanbaak | but <description> has to use the <para> tags |
| 21:27.27 | jsmith | Works for me... I'm not sure how eliel's code will work without it though |
| 21:27.32 | mvanbaak | not |
| 21:27.37 | mvanbaak | that's why I asked |
| 21:27.45 | jsmith | I'm fine either way... if it makes it easier to code, I'm find having it in a para |
| 21:27.49 | mvanbaak | if this is the way it should be, I'll have to fix it |
| 21:28.05 | jsmith | I'm not anywhere close to saying "This is the one true way!" |
| 21:29.47 | mvanbaak | hhmm |
| 21:29.53 | mvanbaak | all other tags need the <para> |
| 21:30.05 | jsmith | All?!? |
| 21:30.09 | mvanbaak | yup |
| 21:30.26 | jsmith | I don't know that I'd go that far |
| 21:30.40 | mvanbaak | <option> <node> <argument> <variable> |
| 21:30.57 | jsmith | Or are you saying all *of the top-level nodes* need paras |
| 21:31.05 | mvanbaak | look at app_dial.c |
| 21:31.27 | jsmith | updating it now |
| 21:31.31 | mvanbaak | you did that <para> stuff |
| 21:31.51 | jsmith | Not all of it |
| 21:31.58 | mvanbaak | nope, but most of it |
| 21:32.01 | jsmith | eliel added a bunch (for things like variables) |
| 21:36.37 | mvanbaak | yup |
| 21:39.30 | jsmith | mvanbaak: So tell me what you think we should do |
| 21:46.11 | mvanbaak | looking at the code, and the commits of eliel, he thinks all 'text' should be inside a <para> tag |
| 21:47.15 | jsmith | I don't think that's a valid assumption |
| 21:47.24 | jsmith | That being said, it's certainly easier to code for |
| 21:47.24 | mvanbaak | it is based on the code |
| 21:47.30 | mvanbaak | yup |
| 21:47.31 | mvanbaak | lol |
| 21:47.48 | jsmith | Well, when all you have is a hammer, everything starts looking like a nail |
| 21:48.21 | mvanbaak | I'll mail eliel about it |
| 21:48.30 | mvanbaak | for now, we have to use <para> |
| 21:48.46 | mvanbaak | I'll ask him what he thinks about the stuff I have in my local tree now |
| 21:51.46 | jsmith | Ok |
| 22:08.08 | *** join/#asterisk-dev jameswf-home (n=james@dsl093-157-131.phx1.dsl.speakeasy.net) |
| 22:23.02 | mvanbaak | jsmith: ok, the <para> is no longer needed in the <synopsis> node |
| 22:23.26 | jsmith | mvanbaak: w00t! |
| 22:24.49 | mvanbaak | :) |
| 22:24.50 | *** join/#asterisk-dev jcollie (n=jcollie@fedora/jcollie) |
| 22:25.03 | mvanbaak | I think the <synopsis> should not have a <para> tag |
| 22:25.23 | mvanbaak | if it needs a <para> tag, the text is for the description, not for the synopsis |
| 22:39.04 | mvanbaak | hurray, eliel agrees |
| 22:39.34 | seanbright | Corydon76-dig: ping |
| 22:49.33 | seanbright | it might be interesting to write an apache module to replace the httpd related functions in asterisk... |
| 22:50.55 | mvanbaak | no |
| 22:51.18 | seanbright | heh |
| 22:51.31 | mvanbaak | you make asterisk depend on apache for that. what about us that use thttpd |
| 22:51.40 | seanbright | no, no dependency |
| 22:51.48 | seanbright | optional |
| 22:52.57 | seanbright | would have to modularize the http stuff though... and do some wacky IPC jazz |
| 22:53.10 | Corydon76-lap | seanbright: pong |
| 22:53.39 | seanbright | Corydon76-lap: do you recall the brief conversation from a few weeks ago about a function i wanted to introduce called ast_format_duration and where it should live? |
| 22:53.49 | mvanbaak | seanbright: make sure to implement thttpd as well |
| 22:54.12 | Corydon76-lap | No, I don't recall. |
| 22:54.12 | seanbright | mvanbaak: thttpd is for n00bs |
| 22:54.12 | mvanbaak | seanbright: and maybe ngix (or however that's called nowedays) |
| 22:54.12 | seanbright | ok |
| 22:54.12 | seanbright | err |
| 22:54.12 | seanbright | Corydon76-lap: ok |
| 22:54.25 | Corydon76-lap | What was it for? |
| 22:54.47 | seanbright | takes a number of seconds and returns a string like "7 years, 3 months, 2 days, 8 hours, 4 minutes, 12 seconds" |
| 22:54.58 | mvanbaak | to echo '42' on all questions |
| 22:55.08 | Corydon76-lap | Oh |
| 22:55.21 | Qwell | cli.c already has that |
| 22:55.22 | Corydon76-lap | either app.c or utils.c |
| 22:55.31 | Qwell | core show uptime.. |
| 22:55.45 | Corydon76-lap | Qwell: it's reimplemented in half a dozen places |
| 22:55.49 | Qwell | oh |
| 22:55.52 | seanbright | right |
| 22:55.57 | seanbright | trying to centralize it |
| 22:56.16 | seanbright | it's not a problem for something in res/ to use something in app.c? |
| 22:56.23 | seanbright | seems criss-crossy |
| 22:56.25 | Corydon76-lap | seanbright: extra option... if the value has years, display only years and months... |
| 22:56.39 | Corydon76-lap | If it has months, only months and days |
| 22:56.51 | Corydon76-lap | If it has days, only days and hours... |
| 22:57.00 | seanbright | that's basically what it does |
| 22:57.03 | seanbright | sorta |
| 22:57.04 | Corydon76-lap | The whole shebang is rather ridiculous |
| 22:57.24 | seanbright | the 'core show uptime' version doesn't show a component if it is 0 |
| 22:57.48 | seanbright | so if it's been 365 days and 1 second you get "1 year, 1 second" |
| 22:57.48 | Corydon76-lap | 7 years, 5 months, 6 days, 13 hours, 28 minutes, and 19 seconds... |
| 22:58.16 | Corydon76-lap | No, I think "1 year" should be for that case |
| 22:58.24 | seanbright | ah |
| 22:58.25 | seanbright | why? |
| 22:58.31 | seanbright | because the rest is extraneous? |
| 22:58.38 | seanbright | or TMI? |
| 22:58.50 | Corydon76-lap | Think significant digits |
| 22:59.01 | seanbright | sure |
| 22:59.10 | seanbright | don't want to end up with option-soup though |
| 22:59.49 | Corydon76-lap | Make it the default, then |
| 23:00.02 | Corydon76-lap | and add an option for "insane" |
| 23:00.08 | seanbright | and i don't know why, but doing it in app.c feels wrong to me |
| 23:00.13 | seanbright | not that i know what is right |
| 23:00.30 | Corydon76-lap | cli.c, then |
| 23:00.43 | Corydon76-lap | since it gets used only by cli apps |
| 23:00.51 | seanbright | good point |
| 23:00.53 | seanbright | done and done |
| 23:00.57 | mvanbaak | in 'core show uptime' please dont 'optimize' out the less significant items |
| 23:01.30 | seanbright | mvanbaak: that is already done |
| 23:01.36 | mvanbaak | I really dont like '1 year, 5 days and 3 hours' to become '1 year' |
| 23:01.39 | Corydon76-lap | mvanbaak: why not? |
| 23:01.58 | mvanbaak | because it will messup my nagios stats |
| 23:02.09 | Corydon76-lap | I'm reminded of the character Data, from STTNG |
| 23:02.10 | mvanbaak | and monitoring |
| 23:02.27 | seanbright | it's already optimized out |
| 23:02.29 | mvanbaak | it will flood my phone with warning SMS messages |
| 23:02.43 | seanbright | System uptime: 2 seconds |
| 23:02.45 | Corydon76-lap | always goes down to the second, without realizing the people are really only concerned with the most significant digits |
| 23:02.48 | mvanbaak | seanbright: not in 1.0 and 1.2 |
| 23:03.00 | seanbright | mvanbaak: well i'm not patching 1.0 or 1.2 :) |
| 23:03.02 | Corydon76-lap | not in 1.4, or 1.6.0, either |
| 23:03.09 | seanbright | huh? |
| 23:03.13 | Corydon76-lap | 1.6.1, perhaps |
| 23:03.14 | seanbright | System uptime: 2 seconds |
| 23:03.17 | seanbright | ^^^ |
| 23:03.23 | Corydon76-lap | It's a new API call, so it's only for trunk |
| 23:03.37 | seanbright | oh right |
| 23:04.21 | seanbright | System uptime: 2 minutes |
| 23:04.23 | mvanbaak | strongbad*CLI> show uptime |
| 23:04.23 | mvanbaak | System uptime: 25 weeks, 3 days, 14 hours, 41 minutes, 38 seconds |
| 23:04.23 | mvanbaak | Last reload: 1 week, 14 hours, 34 minutes, 29 seconds |
| 23:04.26 | seanbright | seconds are 'optimized' away |
| 23:04.35 | seanbright | mvanbaak: right, do it again in 22 seconds |
| 23:04.56 | mvanbaak | System uptime: 25 weeks, 3 days, 14 hours, 42 minutes, 11 seconds |
| 23:04.56 | mvanbaak | Last reload: 1 week, 14 hours, 35 minutes, 2 seconds |
| 23:05.01 | seanbright | sigh... |
| 23:05.11 | seanbright | mvanbaak: if one of the values is **0** it is not included |
| 23:05.24 | Corydon76-lap | seanbright: maybe bitwise to display weeks in preference to months, or something like that |
| 23:05.34 | Corydon76-lap | seanbright: declare some constants |
| 23:05.48 | seanbright | jeebus |
| 23:05.50 | mvanbaak | wtf is wrong with just showing the whole uptime |
| 23:05.56 | seanbright | mvanbaak: nothing!! |
| 23:06.10 | Corydon76-lap | mvanbaak: you've seen STTNG, right? |
| 23:06.17 | kpfleming | how about just adding the output of the epoch timestamp from when asterisk was started |
| 23:06.17 | mvanbaak | nope |
| 23:06.22 | seanbright | mvanbaak: i'm just saying that even without my patch asterisk already doesn't display those values if they are 0 |
| 23:06.28 | seanbright | mvanbaak: so there will be no functionality change |
| 23:06.34 | kpfleming | then you don't need the uptime, you just know it's the same process that you saw last time if the starting timestamp has not changed |
| 23:06.51 | Corydon76-lap | kpfleming: that's not a bad idea, actually |
| 23:06.58 | mvanbaak | hhmm, indeed |
| 23:07.09 | kpfleming | is glad to occasionally have good ideas |
| 23:07.24 | mvanbaak | I can live with that :) |
| 23:07.31 | Corydon76-lap | asterisk -rx 'core show starttime' perhaps? |
| 23:07.41 | seanbright | should be using CLI for that stuff... but i digress |
| 23:07.42 | seanbright | ;) |
| 23:07.43 | kpfleming | sure, something like that |
| 23:07.45 | seanbright | err |
| 23:07.47 | seanbright | shouldn't* |
| 23:08.11 | mvanbaak | combined with 'core show pid' .... |
| 23:08.15 | kpfleming | yes |
| 23:08.27 | seanbright | there is already a manager command to get uptime and all that i think |
| 23:08.31 | seanbright | use AMI |
| 23:08.31 | mvanbaak | rock solid way to determine if we are talking to the same process |
| 23:08.32 | seanbright | done and done |
| 23:08.38 | kpfleming | 'core show processinfo' could display the PID and start time |
| 23:08.47 | kpfleming | do we already have 'core show pid'? |
| 23:09.02 | mvanbaak | the pid is printed in the 'connect' line of rasterisk |
| 23:09.03 | seanbright | there is always 'core show uptime seconds' |
| 23:09.03 | Corydon76-lap | Don't think so |
| 23:09.09 | seanbright | which is more machine parseable |
| 23:09.10 | mvanbaak | Connected to Asterisk 1.0.9-BRIstuffed-0.2.0-RC8o currently running on strongbad (pid = 13213) |
| 23:09.18 | kpfleming | true |
| 23:09.25 | kpfleming | not very machine-extractable though |
| 23:09.28 | mvanbaak | it was in 1.0.9 |
| 23:09.29 | mvanbaak | ;) |
| 23:09.31 | mvanbaak | nope |
| 23:09.36 | mvanbaak | that's why I mentioned it |
| 23:09.48 | Corydon76-lap | That's why we have AMI |
| 23:09.49 | *** join/#asterisk-dev jtodd (i=c8q4rm31@ns.fox-den.com) |
| 23:09.49 | *** mode/#asterisk-dev [+o jtodd] by ChanServ |
| 23:09.57 | seanbright | kpfleming: how do you mean? |
| 23:09.58 | Corydon76-lap | It's a jtodd! |
| 23:10.08 | mvanbaak | Corydon76-lap: yeah, but the sysinfo stuff only works on linux |
| 23:10.14 | mvanbaak | and not on *BSD |
| 23:10.29 | Corydon76-lap | mvanbaak: AMI? |
| 23:10.38 | Corydon76-lap | Asterisk Manager Interface? |
| 23:10.39 | mvanbaak | the sysinfo stuff, no |
| 23:10.55 | Corydon76-lap | When did sysinfo come into it? |
| 23:10.56 | mvanbaak | it depends on some linux-only includes |
| 23:11.08 | mvanbaak | to grab the uptime, pid, etc |
| 23:11.26 | Corydon76-lap | It does? |
| 23:11.33 | seanbright | yes |
| 23:11.42 | Corydon76-lap | I thought we printed the pid based on getpid(), which is POSIX |
| 23:12.01 | seanbright | oh, the pid, no. |
| 23:12.49 | seanbright | err |
| 23:13.12 | seanbright | yes, we use getpid() for pid, the rest of the sysinfo stuff is linux specific |
| 23:13.13 | mvanbaak | there's an AMI function to get the pid ? |
| 23:13.26 | seanbright | mvanbaak: no, but it would be about 12 lines of code to add |
| 23:13.37 | seanbright | that includes documentation |
| 23:13.39 | seanbright | :) |
| 23:13.41 | mvanbaak | I know, it will be trivial |
| 23:14.32 | mvanbaak | just be sure to place it outside the "#ifdef 'sysinfo'" (pseudo code) |
| 23:14.41 | seanbright | doesn't plan to write it |
| 23:14.58 | seanbright | ps -ef | grep asterisk |
| 23:15.05 | seanbright | that's how i get the pid |
| 23:15.05 | seanbright | :) |
| 23:15.12 | mvanbaak | me neither, for now |
| 23:15.31 | mvanbaak | it's on my "When I'm on a plain" list |
| 23:15.51 | mvanbaak | same as fix the sysinfo stuff to use 'sysctl' when not on linux |
| 23:16.04 | Corydon76-lap | mvanbaak: the rain in Spain? |
| 23:16.30 | mvanbaak | Corydon76-lap: more like: 'suspend it till Sept 22' |
| 23:17.20 | mvanbaak | uch |
| 23:17.22 | mvanbaak | plane |
| 23:17.26 | mvanbaak | yeah yeah |
| 23:17.38 | Corydon76-lap | ...falls mainly on the plain |
| 23:17.45 | mvanbaak | I'll be on a plane for 16 hours |
| 23:17.58 | Corydon76-lap | Lucky for you |
| 23:18.02 | mvanbaak | geez, PHX is the other end of the world |
| 23:18.15 | mvanbaak | and some more |
| 23:18.35 | Corydon76-lap | Could be worse |
| 23:18.39 | mvanbaak | yup |
| 23:18.45 | Corydon76-lap | It could be raining |
| 23:18.52 | mvanbaak | like, when I follow your advise |
| 23:19.07 | mvanbaak | get a plane to east us, and rent a car to drive to PHX |
| 23:19.46 | Corydon76-lap | (Apparently you missed that reference) |
| 23:19.53 | mvanbaak | lal |
| 23:20.09 | mvanbaak | s/a/o/ |
| 23:20.33 | Corydon76-lap | (Young Frankenstein) |
| 23:20.53 | mvanbaak | <state type="exhausted" /> |
| 23:21.07 | mvanbaak | too much appdocsxml for one day |
| 23:21.18 | seanbright | abbie normal |
| 23:21.30 | Corydon76-lap | Abbie Someone |
| 23:21.40 | mvanbaak | BUT,.... we have syntax, description and synopsis working ! |
| 23:21.43 | mvanbaak | \o/ |
| 23:22.16 | Corydon76-lap | I will NOT be angry |
| 23:22.33 | mvanbaak | I'm already integrating it into vPBXAdmin |
| 23:22.44 | Corydon76-lap | Well, time to go home. Later, gents |
| 23:22.56 | mvanbaak | so we can hint the user, and syntax check it before we store it into the database |
| 23:23.04 | mvanbaak | well, time to get some sleep |
| 23:23.06 | mvanbaak | latero all |
| 23:23.11 | mvanbaak | Tue Aug 12 01:23:11 CEST 2008 |
| 23:23.29 | mvanbaak | latero all |
| 23:36.34 | *** join/#asterisk-dev outtolunc (n=me@c-67-170-211-86.hsd1.ca.comcast.net) |
| 23:44.00 | *** join/#asterisk-dev schmooze (n=schmooze@rrcs-67-52-214-19.west.biz.rr.com) |
| 23:56.21 | *** join/#asterisk-dev jtodd (i=h1yiebqz@ns.fox-den.com) |
| 23:56.21 | *** mode/#asterisk-dev [+o jtodd] by ChanServ |