| 00:16.00 | seanbright | are algorithms in a book considered public domain? |
| 00:18.25 | *** join/#asterisk-dev russellb (n=russell@asterisk/digium-open-source-team-lead/russellb) |
| 00:18.25 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 00:21.28 | Marquis42 | seanbright: That's a good question, but my gut feeling (disclaimer: IANAL, etc.) is that it's not necessarily public domain. But it would also depend on the age of the book (i.e., if any ridiculous algorithm patents have subsequently expired). |
| 00:22.00 | seanbright | agreed. |
| 00:22.38 | putnopvut | seanbright: I happen to know that some algorithms are patented. I would suspect that if they are, then the book would have to note that fact. |
| 00:22.56 | putnopvut | In fact, you may want to see if the book makes mention of the copyright/patent status of the algorithms contained. |
| 00:23.08 | Marquis42 | putnopvut: That's a good point. |
| 00:23.21 | seanbright | this is a book called 'algorithms in c' by sedgewick |
| 00:23.31 | seanbright | not sure if anything in here is actually patented |
| 00:24.06 | seanbright | and 'patent' isn't in the index :) |
| 00:24.10 | putnopvut | Yeah, no idea. |
| 00:25.41 | Marquis42 | I'm not help on the public domain-ness of the algorithms, but a cursory glance at Amazon makes it look like a good book. Thanks for mentioning it. |
| 00:28.10 | putnopvut | now my curiosity is piqued too. |
| 00:28.44 | putnopvut | ouch, parts 1-5? seems like a large collection. |
| 00:34.17 | seanbright | it's very... academically written |
| 00:34.24 | seanbright | i've had it for years |
| 00:34.44 | seanbright | 'mastering algorithms in C' has a lower barrier to entry |
| 00:34.49 | seanbright | but isn't quite as comprehensive |
| 00:35.01 | Corydon76-dig | Uh, you're mixing two different areas of intellectual property law. Public domain has nothing to do with patents |
| 00:35.23 | Corydon76-dig | Public domain has to do with copyrights. |
| 00:35.28 | seanbright | i need to flatten this box and install ubuntu |
| 00:35.33 | Corydon76-dig | Patent law is completely different. |
| 00:36.31 | Corydon76-dig | An algorithm cannot be public domain. Only a specific implementation can be public domain (or copyrighted). |
| 00:36.37 | seanbright | oh, good. |
| 00:36.40 | seanbright | that helps |
| 00:36.53 | seanbright | putnopvut: the copy i have is just 1-4 |
| 00:37.00 | seanbright | what is part 5? |
| 00:37.06 | putnopvut | graph algorithms. |
| 00:37.09 | seanbright | fun |
| 00:37.14 | putnopvut | And it appears to be about the same size as 1-4 combined. |
| 00:37.20 | seanbright | wow |
| 00:37.30 | Corydon76-dig | You can have a copyrighted implementation of an algorithm which is not patent-encumbered, and you can have a public domain implementation of an algorithm which is patented. |
| 00:38.11 | Marquis42 | Hrmmm... Anybody have any clue when aelparse might be buildable again in trunk? I'm working on some extensions to AEL (flex and bison, yay! :/ ) and that makes it bit more difficult to test. |
| 00:38.51 | seanbright | Marquis42: codefreeze-lap mentioned working on that in the near future. |
| 00:38.55 | putnopvut | Marquis42: I think codefreeze-lap is the one responsible for writing aelparse. I'm not sure when he's planning to work on that anytime soon, though. He has his plate pretty full with CDR stuff. |
| 00:39.14 | putnopvut | ...two conflicting responses! yay! |
| 00:39.22 | Marquis42 | Haha, nice! |
| 00:39.25 | seanbright | heh, he mentioned last week that it was on his list |
| 00:39.35 | putnopvut | Yeah, if he mentioned it recently, then I'd say believe that. |
| 00:39.54 | putnopvut | I just was trying to cover his ass, so to speak, in case he wouldn't be able to get around to it for a while :) |
| 00:39.57 | Marquis42 | I know he's been working on a bunch of crazy CDR stuff, so I can understand if it's not his top priority. I was just curious. |
| 00:41.09 | Marquis42 | For the record, I'm working on allowing return values in AEL macros subsequently being able to use macro calls a rvalues in assignments. Good times, good times... |
| 00:42.04 | seanbright | hmmm. now i can't find it in my irc logs. |
| 00:42.06 | codefreeze-lap | Marquis42: I was hoping to do it over the weekend, I even mused tonight, but I'm too brain-dead. |
| 00:42.40 | codefreeze-lap | Marquis42: return vals for macros? I'm interested |
| 00:42.41 | Marquis42 | codefreeze-lap: No worries. Whenever you have time. I saw the comment in the Makefile about extconf being horribly broken, and it made me sad. ;) |
| 00:42.57 | Marquis42 | Yeah, so you can do assignment just like a function call in a regular language. |
| 00:43.16 | codefreeze-lap | I create stuff that is easily, horribly broken, I guess. I'll fix it. |
| 00:44.15 | seanbright | hah! from revision 162013: |
| 00:44.17 | seanbright | "Now, to get aelparse up and running again in trunk, and out of its "horribly broken" state, so I can run the regression suite!" |
| 00:44.43 | seanbright | i'm not crazy after all :) |
| 00:44.56 | codefreeze-lap | yep, I'm *motivated* to fix it. |
| 00:45.00 | Marquis42 | seanbright: And that last part is when I found out aelparse doesn't build in trunk right now. I made some changes and wanted to ensure that *I* didn't horribly break anything... |
| 00:48.21 | Marquis42 | Anyhow, I've been here since 5:30am so I think it's time for me to go home. You won't have to listen to me whine about aelparse any more. :D |
| 01:10.35 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 01:10.35 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 01:37.01 | *** join/#asterisk-dev Trido (i=trido@ppp178-168.static.internode.on.net) |
| 02:24.42 | *** join/#asterisk-dev russellb (n=russell@asterisk/digium-open-source-team-lead/russellb) |
| 02:24.42 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 02:53.43 | *** join/#asterisk-dev denon (i=denon@synapse.subneural.net) |
| 03:38.21 | *** join/#asterisk-dev Trido (i=trido@ppp178-168.static.internode.on.net) |
| 03:45.54 | *** join/#asterisk-dev moy (n=moy@CPE00195bf6526b-CM0018682bdbd4.cpe.net.cable.rogers.com) |
| 03:46.57 | *** join/#asterisk-dev Juggie (n=Juggie@CPE001601df17fb-CM001ceac25ada.cpe.net.cable.rogers.com) |
| 03:47.04 | *** join/#asterisk-dev ZX81 (n=matt@202.49.106.158) |
| 03:47.40 | ZX81 | hey, anyone know if anyone else has had any problems with one way audio between zap and zap on latest 1.4svn of asterisk + zap? |
| 03:47.57 | ZX81 | sruffell: you mostest :) even though you're probably afk |
| 03:47.58 | ZX81 | :) |
| 03:48.24 | ZX81 | I upgraded the machine at a hotel this morning to bring in a fix for the astribank |
| 03:49.05 | ZX81 | after like 2 hours sip->zap, zap->sip, zap->zap go one way audio |
| 03:49.14 | ZX81 | restarting asterisk doesn't fix it |
| 03:49.20 | ZX81 | restarting zap does |
| 03:49.28 | ZX81 | aex800p with echo can |
| 03:50.37 | ZX81 | anyone even know where I should look? nothing in /var/log/messages, /var/log/asterisk/* etc, dmesg |
| 03:53.12 | sruffell | hmm... |
| 03:53.20 | sruffell | this is new to me. |
| 03:53.49 | sruffell | restarting the drivers fixes it? |
| 03:53.59 | ZX81 | yeah |
| 03:54.12 | sruffell | what if you disable the echocanceler? |
| 03:54.17 | ZX81 | doing /etc/init.d/zaptel restart |
| 03:54.21 | ZX81 | yeah that's what I wondered |
| 03:54.30 | ZX81 | easy to do for vpmadt |
| 03:54.33 | sruffell | could you try that? Although I'm not aware of any general issues. |
| 03:54.44 | ZX81 | VPMADT032 |
| 03:54.54 | ZX81 | just echocan setting in zapata? |
| 03:55.16 | ZX81 | hmmm |
| 03:55.17 | ZX81 | echocancelwhenbridged=no |
| 03:55.18 | ZX81 | is set |
| 03:55.22 | sruffell | in /etc/modprobe.d somewhere, make sure options wctdm24xxp vpmsupport=0 |
| 03:55.25 | sruffell | is set somewhere |
| 03:55.30 | ZX81 | and same problem with zap lines to astribank |
| 03:55.34 | ZX81 | ok |
| 03:56.08 | sruffell | although if you're having the same issue with Astribank, I guess the vpm could not be the culprit. |
| 03:56.14 | ZX81 | well |
| 03:56.22 | ZX81 | its aex -> astribank |
| 03:56.27 | sruffell | ah..ok |
| 03:56.30 | sruffell | still worth a try then. |
| 03:56.35 | ZX81 | didn't get a chance to test astribank->astribank |
| 03:56.36 | ZX81 | ok |
| 03:56.39 | ZX81 | will set that |
| 03:56.42 | ZX81 | call them every hour |
| 03:56.46 | ZX81 | (took a while to happen) |
| 03:56.53 | ZX81 | when they hangup on me I'll restart it |
| 03:56.56 | ZX81 | :) |
| 03:56.58 | sruffell | kk |
| 03:57.00 | ZX81 | thanks for your help man |
| 03:57.10 | ZX81 | will post a bt entry if it doesn't or does resolve it |
| 03:57.11 | ZX81 | :) |
| 03:57.25 | sruffell | bt entry? |
| 03:57.28 | sruffell | mantis? |
| 03:57.32 | ZX81 | yah |
| 03:57.33 | ZX81 | soz |
| 03:57.35 | sruffell | lol.. |
| 03:57.38 | ZX81 | bugtrack |
| 03:57.39 | ZX81 | :D |
| 04:45.58 | *** join/#asterisk-dev mog (n=mog@c-68-62-172-152.hsd1.al.comcast.net) |
| 04:45.58 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 04:56.28 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-20-153.hsd1.sc.comcast.net) |
| 04:56.28 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 05:56.32 | codefreeze-lap | Marquis42: Done, trunk, 1.6.0 svn, and 1.6.1 svn all have aelparse back now |
| 05:57.20 | codefreeze-lap | is really, really, really brain-dead now. |
| 05:58.07 | snuff-work | good working hard then ;) |
| 05:59.42 | codefreeze-lap | bows a brain-dead bow |
| 07:40.46 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 08:20.16 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 09:37.11 | *** join/#asterisk-dev qdk (n=qdk@94.191.242.41.bredband.3.dk) |
| 09:45.16 | *** part/#asterisk-dev frawd (n=francois@136.Red-79-147-116.staticIP.rima-tde.net) |
| 09:46.14 | *** join/#asterisk-dev ccesario (n=ccesario@189-19-9-100.dsl.telesp.net.br) |
| 10:22.32 | *** join/#asterisk-dev qdk_ (n=qdk@94.191.226.89.bredband.3.dk) |
| 10:31.56 | *** join/#asterisk-dev eliel (n=eliel@200.61.172.61) |
| 10:31.56 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 10:33.42 | *** join/#asterisk-dev pputman (n=centrex@nat/digium/x-6c81b8dceb2da41a) |
| 11:14.16 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:47.26 | *** join/#asterisk-dev dioedu (n=dioedu@201.7.117.114) |
| 12:59.15 | *** join/#asterisk-dev snuff-home (n=snuffy@60-240-117-7-nsw-pppoe.tpgi.com.au) |
| 12:59.15 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 13:20.54 | *** join/#asterisk-dev snuff-home (n=snuffy@60-240-117-7-nsw-pppoe.tpgi.com.au) |
| 13:20.54 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 13:22.04 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:22.04 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 13:40.19 | *** join/#asterisk-dev DarkRift (n=dark@65.92.249.12) |
| 14:00.46 | jsmith | Anybody know how to keep gdb from paging the results when I look at a backtrace? |
| 14:00.59 | jsmith | I know there's a setting to turn it off, but can't find it |
| 14:05.20 | jsmith | "set pagination off", apparently |
| 14:07.50 | lmadsen | oh, neat |
| 14:08.02 | lmadsen | usually when I pipe it into tee it also does that automatically |
| 14:34.45 | *** join/#asterisk-dev Rico29 (n=Rico@lns-bzn-48f-81-56-220-28.adsl.proxad.net) |
| 14:34.49 | Rico29 | hi |
| 14:35.05 | Rico29 | jui've got a question about AGI perl module |
| 14:35.10 | Rico29 | *I've |
| 14:35.32 | *** join/#asterisk-dev mog (n=mog@nat/digium/x-3ae82bf8b1135dd2) |
| 14:35.32 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 14:35.39 | Rico29 | i just want to know the bitrate of encoded wav sounds with "agi::record_file" function |
| 14:36.47 | lmadsen | probably 8-bit, 8kHz |
| 14:38.03 | tzafrir_laptop | 16bit (slinear) |
| 14:39.10 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.130.105) |
| 14:51.25 | Rico29 | which one I choose ? :D |
| 14:52.22 | *** join/#asterisk-dev steliosk (n=Stelios@ipa107.2.tellas.gr) |
| 14:52.50 | *** join/#asterisk-dev putnopvut (n=putnopvu@nat/digium/x-f5e1ebc65cbe55ec) |
| 14:52.50 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:00.06 | file | codefreeze-lap: your review for the parking stuff isn't showing the diff because you did not tell it the correct thing for branch... |
| 15:03.40 | *** join/#asterisk-dev sysreq (n=sysreq@unaffiliated/sysreq) |
| 15:13.42 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 15:24.55 | *** join/#asterisk-dev kamanashisroy (n=kamanash@119.30.34.9) |
| 15:32.49 | *** join/#asterisk-dev Deeewayne (n=Deeewayn@nat/digium/x-aaba86df7b4117b2) |
| 15:32.49 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 15:37.59 | anonymouz666 | If I have 2 cards (2e1 each) (60 channels - 30 active channels in this test) in the same box and Dial from card one to another (DAHDI->DAHDI) will be the same numbers of threads processing the call if I compare to 60 active channels receiving the call from PSTN? |
| 15:39.44 | anonymouz666 | or this question could be resumed.. the numbers of threads is directly related to the number of active channels |
| 15:39.50 | anonymouz666 | ? |
| 15:40.07 | *** join/#asterisk-dev CunningPike (n=arodgers@S010600095b33697f.vc.shawcable.net) |
| 15:42.19 | tzafrir_laptop | anonymouz666, generally one thread per active channel (and a number of "constant" ones) |
| 15:44.58 | anonymouz666 | tzafrir_laptop: ok, that's right. so dialing from one to other (2 E1s) I'll get max of 30 active channels, so 30 threads. And receiving 60 calls will give to me 60 active channels and so 60 threads. My testing isn't reproducing the same scenario then. |
| 15:45.26 | anonymouz666 | thanks for clarifying. |
| 15:47.47 | *** join/#asterisk-dev shido6 (n=shido6@209.114.208.111) |
| 15:56.09 | *** join/#asterisk-dev CunningPike (n=arodgers@S010600095b33697f.vc.shawcable.net) |
| 15:57.00 | *** join/#asterisk-dev CunningPike (n=arodgers@vpn.dnv.org) |
| 15:58.21 | *** join/#asterisk-dev riksta (n=rick@office.encompassmedia.co.uk) |
| 15:59.40 | riksta | Hi, I've been using a patch http://bugs.digium.com/view.php?id=11954 for a while now, which allows you to send the called party to a context^exten^pri .... I am wondering how we go about getting this included in one of the coming releases? |
| 16:00.05 | riksta | send the called party (on calling party hangup) i meant |
| 16:00.16 | lmadsen | it would be in the next 1.6.x release |
| 16:00.22 | lmadsen | 1.6.2 for example |
| 16:00.31 | riksta | ahh excellent 1.6.1 .. no? |
| 16:00.31 | lmadsen | it won't go into an existing release |
| 16:00.37 | lmadsen | nope, that is feature frozen |
| 16:00.40 | lmadsen | it'll be in trunk righ tnow |
| 16:00.43 | riksta | ok, I understand |
| 16:00.49 | riksta | yeah i have been using trunk |
| 16:00.59 | riksta | i just didnt understand the process of when it will be in the release, thanks |
| 16:01.09 | lmadsen | yep, next point release it'll go in |
| 16:01.12 | lmadsen | no worries |
| 16:01.12 | riksta | where is a list of what's in the 1.6.1 feature frozen |
| 16:01.28 | lmadsen | my guess.... ChangeLog |
| 16:01.47 | riksta | but there's lots of them? |
| 16:02.12 | lmadsen | lots is a relative term :) |
| 16:02.18 | lmadsen | doesn't know what all went into 1.6.1 |
| 16:02.27 | riksta | ha :) ok no problem, thanks for your time |
| 16:02.54 | riksta | i looked in the 1.6.0.3-rc1 release, it isnt there |
| 16:02.59 | riksta | so i imagine it wont be in 1.6.1 |
| 16:03.08 | seanbright | that is correct |
| 16:03.10 | seanbright | 1.6.2 |
| 16:03.14 | riksta | thanks for clearing that up |
| 16:03.18 | seanbright | yup |
| 16:05.16 | lmadsen | didn't I already say that? :) |
| 16:05.29 | seanbright | you did |
| 16:05.37 | seanbright | you get the credit as far as i am concerned |
| 16:05.42 | lmadsen | ha |
| 16:06.14 | mvanbaak | !karma+ lmadsen |
| 16:06.20 | lmadsen | heh |
| 16:06.26 | lmadsen | jbot: lmadsen++ |
| 16:06.38 | putnopvut | jbot: punch lmadsen in the karma |
| 16:06.39 | jbot | ACTION lets fly with a wild haymaker which catches lmadsen in the karma right on the nose |
| 16:06.39 | lmadsen | haha.. jbot doesn't want me to karma myself |
| 16:06.56 | putnopvut | MuffinMan: reward lmadsen |
| 16:08.47 | seanbright | lmadsen++ |
| 16:08.56 | seanbright | jbot: karma |
| 16:08.56 | jbot | seanbright has karma of -1 |
| 16:09.03 | seanbright | jbot: karma lmadsen++ |
| 16:09.03 | jbot | lmadsen++ has neutral karma |
| 16:09.07 | seanbright | jbot: karma lmadsen |
| 16:09.07 | jbot | lmadsen has neutral karma |
| 16:09.17 | seanbright | jbot: help karma |
| 16:09.20 | jsmith-teaching | ~karma seanbright |
| 16:09.20 | jbot | seanbright has karma of -1 |
| 16:09.24 | lmadsen | you just have to say: jbot: lmadsen++ |
| 16:09.25 | jsmith-teaching | Doh! |
| 16:09.28 | seanbright | jbot: lmadsen++ |
| 16:09.33 | jsmith-teaching | ~karma file |
| 16:09.33 | jbot | file has neutral karma |
| 16:09.37 | jsmith-teaching | ~karma putnopvut |
| 16:09.37 | jbot | putnopvut has neutral karma |
| 16:09.37 | lmadsen | jbot: seanbright++ |
| 16:10.34 | codefreeze-lap | file: sorry, I've been distracted by buildbot failures... what should I have put in the reviewboard branch info? |
| 16:10.49 | file | codefreeze-lap: branches/1.4 |
| 16:12.57 | codefreeze-lap | file: as to buildbot, is there any way to test fixes? Why is buildbot suddenly barfing on stuff that's not changed in over a year? |
| 16:14.00 | seanbright | jsmith-teaching: how do you escape variables in extensions.conf? |
| 16:14.02 | file | there are instructions on the wiki for testing fixes |
| 16:14.19 | seanbright | jsmith-teaching: like if i want the *value* of a variable to be Sean-${AWESOME} |
| 16:14.38 | seanbright | jsmith-teaching: wouldn't it be Set(SomeVar=Sean-$\{AWESOME\}) |
| 16:14.57 | lmadsen | I thought there was a dialplan function to do that... but maybe that was the other way around in evaluating it |
| 16:18.25 | lmadsen | sruffell: ping? |
| 16:18.26 | Corydon76-dig | lmadsen: yeah, only ${EVAL()} |
| 16:18.34 | lmadsen | right... EVAL() is what I was trying to remember |
| 16:19.30 | seanbright | ok, so slashes seem to work |
| 16:19.59 | lmadsen | nice |
| 16:20.47 | *** join/#asterisk-dev jameswf (n=james@unaffiliated/jameswf-home) |
| 16:20.58 | Corydon76-dig | seanbright: you can also do: Set(dollar=$) Set(other=${dollar}{foo}) |
| 16:21.13 | seanbright | Corydon76-dig: yeah, that's scary though. |
| 16:21.22 | Corydon76-dig | because it's the COMBINATION of $ and { that starts a variable |
| 16:21.40 | seanbright | right |
| 16:21.50 | seanbright | i prefer the $\{ method |
| 16:21.53 | lmadsen | heh |
| 16:24.33 | *** join/#asterisk-dev mnicholson (n=mnichols@nat/digium/x-c246914fb70d643a) |
| 16:25.38 | *** join/#asterisk-dev awk_r (n=rawk@nat/digium/x-f1645a0f09c46d2b) |
| 16:27.35 | *** join/#asterisk-dev russellb (n=russellb@asterisk/digium-open-source-team-lead/russellb) |
| 16:27.35 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 16:28.03 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 16:28.03 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 16:28.44 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 16:31.57 | mvanbaak | eliel: ping |
| 16:32.07 | eliel | mvanbaak: pong |
| 16:32.15 | eliel | (500ms) |
| 16:32.20 | mvanbaak | :) |
| 16:32.27 | mvanbaak | your work on the seperator |
| 16:32.47 | mvanbaak | I think there are a lot more places in the code where it should be updated |
| 16:33.04 | eliel | mvanbaak: could you point them on the review board? |
| 16:33.09 | mvanbaak | I was browsing through the output of: grep -rni '","' * | grep -v '.svn' |
| 16:36.18 | eliel | ok, i will use that |
| 16:36.57 | mvanbaak | just a brainfart on my end. thought I should let you know :) |
| 16:42.30 | eliel | mvanbaak: thanks |
| 16:44.49 | eliel | M14098 |
| 16:44.51 | MuffinMan | [assigned] [Asterisk] Core/General 0014098: [patch] Simplify main/strings.c code reported by eliel (Karma: +181.50) http://bugs.digium.com/view.php?id=14098 |
| 16:44.57 | eliel | Corydon76-dig: ping |
| 16:45.48 | eliel | Why do you think this will make users use ->STR (??) I will just let STR exist in strings.c and strings.h outside of this files ->STR will not exist anymore |
| 16:47.56 | eliel | hmm, I need STR to be defined if struct ast_str is defined... |
| 16:54.56 | Corydon76-dig | eliel: because to use ast_str, you #include "asterisk/strings.h" |
| 16:55.07 | Corydon76-dig | eliel: now it's defined for anyone to use |
| 16:58.38 | eliel | we could move ast_str_alloc to a function instead of a #define |
| 16:58.50 | eliel | and move that code to strings.c |
| 16:59.33 | Corydon76-dig | eliel: No, you cannot. |
| 16:59.56 | Corydon76-dig | alloca MUST happen in the same function, as it's allocated on the STACK |
| 17:00.21 | eliel | ups, you are right |
| 17:01.08 | eliel | Corydon76-dig: we could create a ast_str_alloc_helper and call that one to initialize the struct. |
| 17:01.49 | eliel | and move the rest of the api to strings.c |
| 17:02.46 | Corydon76-dig | eliel: no, the point of the AST_INLINE_API is to make the code extremely fast. If you remove the code to strings.c, you'll add a stack frame allocation to every use of ast_str |
| 17:04.45 | eliel | ok, so, my idea is to just replace the code inside strings.c to make it more readable... and leave strings.h as it is |
| 17:08.07 | Corydon76-dig | eliel: If you want to make strings.h more readable, change it to use a SINGLE #ifdef DEBUG_OPAQUE |
| 17:08.33 | Corydon76-dig | and then define all of the functions one way within a block, then the other way, in the other block |
| 17:08.58 | Corydon76-dig | The reason I did it this way, is that I like both implementations to be on the same screen, if I have to change anything |
| 17:09.22 | russellb | but all code is copied twice ... |
| 17:09.26 | russellb | which is generally not preferable. |
| 17:09.54 | russellb | I would have complained if you had put it on reviewboard :-) |
| 17:11.47 | eliel | Corydon76-dig: I agree that having the two implementation in the same screen is better, also we will not remember to change the "debug opaque" implementation if we dont see it |
| 17:12.45 | eliel | this is just to test the code at compilation time isnt it? |
| 17:13.15 | Corydon76-dig | Basically, yes |
| 17:13.48 | Corydon76-dig | Actually, the point of it was to catch people who were hardcoding in their patches |
| 17:13.57 | eliel | what if we put dummy functions instead of an implementation when debug_opaque is defined |
| 17:14.06 | eliel | asterisk wont work |
| 17:14.22 | eliel | but is just for debugging purposes, for a developer that knows what is doing... |
| 17:15.39 | eliel | no, i don't like too much my idea... |
| 17:16.09 | eliel | but also, don't like obfuscating the code, just to make sure everyone is using it in the right way... |
| 17:17.39 | eliel | oohhh, gcc we need an attribute to hide the structure members to the user, hehe |
| 17:17.43 | Corydon76-dig | I fail to see how this is obfuscating code, in the first place |
| 17:19.02 | Corydon76-dig | And we've spent entirely too much time already on this discussion. |
| 17:23.13 | russellb | it's obfuscated because all code is now copied twice |
| 17:23.31 | russellb | i wouldn't call it obfuscated |
| 17:23.48 | russellb | it's ... just ... duplicated code :-) |
| 17:23.58 | russellb | which does make it less readable, I guess |
| 17:24.57 | Corydon76-dig | Now if I added all the ifdef's to avoid duplication of code, THAT would be obfuscated |
| 17:25.08 | Corydon76-dig | I considered this the happy medium. |
| 17:25.29 | russellb | eliel's original suggestion was a trivial way to avoid it ... |
| 17:25.34 | russellb | I don't see what's wrong with that |
| 17:26.04 | eliel | russellb: it is not |
| 17:26.05 | Corydon76-dig | russellb: if only we could prevent people from using the def's inside a header file |
| 17:26.37 | russellb | why would we care to? we wouldn't let patches go in like that |
| 17:26.48 | russellb | and if people code around it in 3rd party code, who cares, that's their own fault |
| 17:27.24 | Corydon76-dig | Okay, if you add a big comment that says NOT to use those defines in your own code |
| 17:27.39 | russellb | pretty much. The API should be sufficiently documented to indicate how to use it |
| 17:27.53 | russellb | (and how not to) |
| 17:28.45 | file | quite |
| 17:49.20 | *** join/#asterisk-dev qdk (n=qdk@94.191.218.86.bredband.3.dk) |
| 17:54.23 | russellb | eliel: ping |
| 17:54.49 | russellb | eliel: make validate-docs is failing because it says argsep isn't valid for <argument>, but it looks like it's in the DTD ... |
| 17:55.07 | russellb | oh no it's not |
| 17:55.12 | russellb | nevermind, i'll fix :-) |
| 18:27.41 | mvanbaak | M13900 |
| 18:27.43 | MuffinMan | [assigned] [Asterisk] Channels/chan_iax2 0013900: [feature request] Asterisk does not respect DNS TTL in iax.conf reported by ffadaie (Karma: +0.50) http://bugs.digium.com/view.php?id=13900 |
| 18:27.59 | mvanbaak | I have an idea how we can fix this |
| 18:28.09 | mvanbaak | but I want some feedback on the idea before I start writing code |
| 18:28.17 | mvanbaak | anyone has a couple of minutes for this ? |
| 18:34.39 | mvanbaak | and why do we have upstream awstats in repotools ? |
| 18:36.19 | mvanbaak | my idea to fix the DNS stuff is to alter dnsmgr.c to reset the refresh_interval to the smallest TTL of all the lookups it manages |
| 18:37.05 | mvanbaak | so if I use dnsmanager in asterisk, and set the interval to 3 hours, but one of the lookups returns a ttl of 5 minutes we reset the refresh interval to 5 minutes |
| 18:37.32 | mvanbaak | with a safety net of 1 minute at minimum |
| 18:52.14 | mvanbaak | eew, mantis uses short tags :( |
| 18:55.44 | jsmith-teaching | mvanbaak: Yuck! |
| 18:58.17 | mvanbaak | yeah, mantis wont work on my OpenBSD system |
| 19:02.00 | mvanbaak | 13 |
| 19:02.24 | *** join/#asterisk-dev The_Boy_Wonder (n=davidvos@74-47-21-87.dsl1.ckvl.tn.frontiernet.net) |
| 19:05.41 | *** join/#asterisk-dev JerJer (n=PhatJ@24-236-207-64.dhcp.aldl.mi.charter.com) |
| 19:08.33 | *** join/#asterisk-dev ctooley (n=ctooley@mo-71-1-105-142.dhcp.embarqhsd.net) |
| 19:08.33 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 19:15.07 | wedhorn | mvanbaak: ping |
| 19:15.34 | mvanbaak | wedhorn: PONG !!!!!! |
| 19:15.49 | wedhorn | having fun with your skinny phones? |
| 19:16.07 | mvanbaak | yup |
| 19:16.13 | mvanbaak | having fun crashes |
| 19:16.22 | mvanbaak | now that I went back to 1.6 |
| 19:16.39 | wedhorn | I thought pj's issue was to do with his device unregistering (7920 from memory) |
| 19:16.51 | wedhorn | ah, thought you were still in trunk |
| 19:16.57 | mvanbaak | nope |
| 19:17.04 | mvanbaak | in trunk I did not have this problem |
| 19:17.17 | mvanbaak | and PJ reports he does not see it in trunk neither |
| 19:17.34 | wedhorn | hang on, I thought he still did |
| 19:17.37 | mvanbaak | but, pj has a lot of different backtraces |
| 19:17.47 | mvanbaak | and mine is always the same |
| 19:18.47 | wedhorn | M13777 |
| 19:18.49 | MuffinMan | [assigned] [Asterisk] Channels/chan_skinny 0013777: crash or dialing isn't possible reported by pj (Karma: +9.00) http://bugs.digium.com/view.php?id=13777 |
| 19:18.57 | mvanbaak | you want my full backtrace ? |
| 19:19.03 | wedhorn | original is 1.6, all subsequent is trunk |
| 19:19.22 | mvanbaak | ahha ! |
| 19:19.32 | mvanbaak | so gdb1.txt is from 1.6 and the rest is from trunk |
| 19:19.38 | wedhorn | and gdb2 |
| 19:19.57 | mvanbaak | then I can state: gdb1.txt is happening to me as well with a 7960 in 1.6. but I dont have it in trunk |
| 19:20.18 | wedhorn | ok, but I don't really care about 1.6 ;) |
| 19:21.00 | mvanbaak | gheh, I had the same till my home server died and I moved my setup to our production setup |
| 19:21.28 | mvanbaak | now I remember why I always install a trunk box at locations with skinny phones :) |
| 19:21.48 | mvanbaak | I'll be back in 30 minutes |
| 19:21.49 | wedhorn | yeah, hopefully we can fix that by 3.8 |
| 19:34.32 | *** join/#asterisk-dev telecos (n=sergio@6.166.219.87.dynamic.jazztel.es) |
| 19:40.09 | tzanger | hmm |
| 19:40.19 | tzanger | where in zaptel did the default value returned get stored? |
| 19:40.27 | tzanger | i.e. 0x7f of 0xff I think for ulaw/alaw |
| 19:41.10 | tzanger | I remember seeing it somewhere but now for the life of me can't find it |
| 19:41.27 | tzanger | er default tx value for when a zap chan wasn't in use |
| 19:45.49 | russellb | Corydon76-dig: ping |
| 19:46.20 | Corydon76-dig | pong |
| 19:47.01 | russellb | nevermind, we just figured it out :-) |
| 19:47.02 | russellb | carry on! |
| 19:47.03 | russellb | lol |
| 19:47.17 | Corydon76-dig | I'm working on a blog post on asterisk.org, in case you're curious |
| 19:47.23 | russellb | awesome :-) |
| 19:47.34 | russellb | file and I were looking at some gosub code and had a question |
| 19:47.55 | Corydon76-dig | Ask, and maybe I can clarify not only on what, but why |
| 19:48.07 | russellb | we figured it out |
| 19:48.20 | Corydon76-dig | Sometimes the why is more verbose. ;-) |
| 19:49.41 | russellb | we were trying to figure out how the gosub option for dial worked |
| 19:49.51 | russellb | we were looking at ast_pbx_run() as ast_pbx_start() |
| 19:49.57 | russellb | and wondering WTF? HOW DOES THAT WORK?! |
| 19:50.04 | russellb | oh, it's not creating another thread, lawl |
| 19:50.11 | russellb | :-) |
| 19:50.51 | Corydon76-dig | Isn't that cool? |
| 19:50.51 | russellb | yep, nice job :-) |
| 19:50.51 | putnopvut | yay for app_dial_gosub_virtual_context |
| 19:50.52 | Corydon76-dig | It's why I had to create that app for exiting live |
| 19:51.00 | russellb | nods |
| 19:51.01 | Corydon76-dig | KeepAlive() |
| 19:51.15 | russellb | though I'm thinking I'd like to just add a new argument for ast_pbx_run() that says don't kill the channel on exit |
| 19:51.44 | russellb | since this is the only case left where KEEPALIVE is being used (after murf's patch) |
| 19:51.50 | Corydon76-dig | Ah, I was just thinking about keeping ABI intact |
| 19:52.10 | russellb | and in this case, we know this up front, so we can just set it as a parameter |
| 19:52.10 | putnopvut | russellb: you may also want to add a parameter saying not to increase the call count, too. |
| 19:52.23 | russellb | putnopvut: yeah, could be interesting. |
| 19:52.39 | russellb | well, it would be a new API call to maintain ABI |
| 19:53.01 | Corydon76-dig | I'm seeing a flags parameter in the future of ast_pbx_run2 |
| 19:53.11 | russellb | pretty much, yes :-) |
| 19:53.19 | russellb | i was thinking an ast_pbx_args struct ... |
| 19:53.26 | russellb | that would have flags in it ... |
| 19:53.40 | russellb | and go ahead and make it 64 bits in size for future expandability |
| 19:54.21 | Corydon76-dig | I dunno about that. I tried using a 64-bit bitfield on the ast_timing upgrade, and gcc puked at me |
| 19:54.38 | russellb | oh really ... |
| 19:54.45 | tzanger | hmm |
| 19:54.47 | Corydon76-dig | It doesn't like 64-bit constants in hexadecimal |
| 19:54.59 | tzanger | I cannot find what sets writechunk to the default value when a channel isn't open |
| 19:55.07 | putnopvut | Corydon76-dig: what if you append something like ULL to the literal? |
| 19:55.13 | russellb | hm. well, i was going to do it like ... union { uint64_t padding; struct { unsigned int option:1; unsigned int otheroption:1; } } |
| 19:55.17 | Corydon76-dig | putnopvut: I did not try that |
| 19:55.56 | russellb | all of that as the contents of ast_pbx_args |
| 20:00.17 | kpfleming | yummy... anonymous structs |
| 20:07.36 | mvanbaak | back |
| 20:16.23 | mvanbaak | anyone want to comment on my idea to change dnsmgr ? |
| 20:38.55 | jsmith-teaching | kpfleming: Are the crunchy and salty like pretzels? Sticky and sweet like a jelly doughnut? |
| 20:39.06 | jsmith-teaching | mvanbaak: You get a +1 from me on it... |
| 20:51.04 | *** join/#asterisk-dev sasargen (n=chatzill@174-153-125-248.pools.spcsdns.net) |
| 20:53.57 | putnopvut | ooh, that's weird. wcgrep "hangs" in trunk when I run `wcgrep ast_load_realtime` |
| 20:54.11 | putnopvut | oh, and now it doesn't.. |
| 20:54.17 | putnopvut | Weird. |
| 20:58.13 | seanbright | it's always faster the second time |
| 20:58.20 | seanbright | some fs caching or something |
| 20:58.43 | russellb | yep |
| 20:59.45 | seanbright | better that reiserfs. which kills your wife. |
| 21:00.28 | *** join/#asterisk-dev schmooze (n=schmooze@h69-129-142-83.mdsnwi.tisp.static.tds.net) |
| 21:02.22 | seanbright | what? too soon? |
| 21:05.35 | seanbright | mvanbaak: where is you idea to change dnsmgr? |
| 21:09.13 | *** join/#asterisk-dev frawd (n=francois@104.Red-83-57-200.dynamicIP.rima-tde.net) |
| 21:09.15 | mvanbaak | seanbright: it's in the backlog |
| 21:10.10 | mvanbaak | seanbright: hang on |
| 21:10.21 | seanbright | i see it |
| 21:10.22 | mvanbaak | seanbright: http://pastebin.ca/1288042 |
| 21:11.10 | *** join/#asterisk-dev ZX81 (n=matt@202.49.106.158) |
| 21:11.30 | ZX81 | sruffell: hi |
| 21:11.40 | ZX81 | sruffell: looks like it was the echo can causing it to die |
| 21:11.49 | ZX81 | I think the problem is this: |
| 21:12.03 | ZX81 | I pressed crtl-c while it was loading firmware to the card |
| 21:12.09 | ZX81 | (well I'm assuming) |
| 21:12.23 | ZX81 | and that check for result is missing from zaptel svn 1.4 |
| 21:12.37 | ZX81 | ala http://bugs.digium.com/view.php?id=13275 |
| 21:12.48 | ZX81 | down_interruptible |
| 21:13.24 | ZX81 | it does: |
| 21:13.25 | ZX81 | if (vpm) |
| 21:13.25 | ZX81 | <PROTECTED> |
| 21:14.01 | ZX81 | rev 4595 |
| 21:14.14 | sruffell | hmm.... |
| 21:14.57 | ZX81 | so the good thing is, disabling the vpm support meant it was fixed |
| 21:14.58 | ZX81 | but |
| 21:15.15 | ZX81 | I would have thought that /etc/init.d/zaptel restart would have reloaded the fw |
| 21:15.46 | ZX81 | I mean it's not really much of an issue seeing as their pbx is running again :) |
| 21:16.05 | sruffell | so then you hit the case I mentioned here http://svn.digium.com/view/dahdi?view=rev&revision=5236 exactly.... but the module didn't need to be reloaded. |
| 21:16.41 | sruffell | so you hit ctrl-c, but didn't need to reload the module. |
| 21:18.08 | ZX81 | ok, the reason I think I was pressing ctrl c is that I was trying a whole lot of fixes for the astribank |
| 21:18.24 | ZX81 | so it's not 100% sure it happenedm during fw load but is quite possible |
| 21:18.25 | ZX81 | :) |
| 21:18.36 | tzafrir_laptop | ZX81, hi |
| 21:18.47 | ZX81 | :) hi |
| 21:18.48 | mvanbaak | seanbright: what you think of that idea ? |
| 21:18.53 | sruffell | hmm...I should check that...to make sure that if ctrl-c is pressed...the load of the module actually fails. |
| 21:19.04 | seanbright | mvanbaak: no time to look at the code involved. |
| 21:19.05 | sruffell | load of the kernel module...not the vpm module in this case. |
| 21:19.22 | mvanbaak | seanbright: dont worry about the code |
| 21:19.26 | mvanbaak | seanbright: I'll fix that |
| 21:19.31 | mvanbaak | it's not going to be that bad |
| 21:19.40 | ZX81 | tzafrir_laptop: cheers for the changes to xpp, haven't restarted the machine, but reloading the fw looked like it worked fine |
| 21:19.41 | ZX81 | brb |
| 21:20.09 | seanbright | mvanbaak: what about those cases when the users aren't using the dns manager? |
| 21:20.13 | mvanbaak | there's one single function in dnsmgr.c that does the reloads, and the last statement in that function is to schedule a refresh again after refresh_interval * 1000 |
| 21:20.21 | mvanbaak | seanbright: so that's not going to be too hard to fix |
| 21:20.38 | mvanbaak | if they dont use the dns manager, the old behaviour applies |
| 21:21.03 | mvanbaak | on the bugtracker the comment about dnsmanager was that it did not take the TTL into account |
| 21:21.11 | mvanbaak | so if we fix that, that comment is moot |
| 21:21.31 | seanbright | mvanbaak: i thought it was about chan_iax2 caching the address instead of the domain name for peers |
| 21:22.07 | mvanbaak | seanbright: indeed, and with dnsmanager that problem was fixed, with one comment, the one about ttl vs configured refresh timeout |
| 21:22.39 | seanbright | mvanbaak: i see |
| 21:22.57 | seanbright | mvanbaak: well then it sounds like a decent idea |
| 21:23.00 | mvanbaak | so if we fix dnsmanager to respect the TTL instead of the configured refresh param we are all set |
| 21:23.42 | mvanbaak | main/dnsmgr.c line 214-240 |
| 21:23.49 | mvanbaak | that's all that needs changes |
| 21:24.57 | mvanbaak | some code to store and sort the TTL's we get with the DNS requests, and altering the return value so it returns the smallest TTL value |
| 21:25.01 | putnopvut | Oh, and for everyone wondering, I'm aware I broke compilation in trunk... |
| 21:25.59 | seanbright | hmmm |
| 21:26.07 | seanbright | looks like stevie-ramjet broke trunk |
| 21:26.10 | seanbright | is he around? |
| 21:26.14 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 21:26.14 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 21:26.31 | Corydon76-dig | putnopvut: you did? Shame! Shame! Shame! |
| 21:26.51 | Corydon76-dig | (Are you sure I'm not the one who broke trunk?) |
| 21:27.11 | lmadsen | is not sure of anything |
| 21:29.04 | file | ha |
| 21:30.59 | putnopvut | Corydon76-dig: I guess we both did :) |
| 21:36.00 | *** join/#asterisk-dev Trido (i=trido@ppp178-168.static.internode.on.net) |
| 21:49.25 | mnicholson | mvanbaak, your commit yesterday broke the build on freebsd |
| 21:50.12 | mnicholson | http://pastebin.com/m1aecec1a |
| 21:50.19 | mvanbaak | mnicholson: it broke on everything but OpenBSD |
| 21:50.24 | mvanbaak | mnicholson: russell fixed it |
| 21:50.58 | mnicholson | mvanbaak, mmm, it's still failing with that |
| 21:51.04 | mnicholson | on freebsd at least |
| 21:51.31 | mvanbaak | hhmm |
| 21:51.37 | mvanbaak | than I'll have a look at your pastebin ;) |
| 21:52.06 | russellb | mnicholson: we used to have buildbot exposed to the public via buildbot.digium.com. Can you add to your list checking on what happened to that and getting it back up? |
| 21:52.19 | mnicholson | russellb, yeah, i can do that |
| 21:52.22 | russellb | thanks |
| 21:52.38 | mvanbaak | hhmm |
| 21:52.48 | mvanbaak | mnicholson: latest trunk version ? |
| 21:52.55 | mnicholson | mvanbaak, yup |
| 21:55.12 | mvanbaak | hhmm |
| 21:55.14 | mvanbaak | I see |
| 21:58.21 | mvanbaak | that sux |
| 22:00.28 | mvanbaak | mnicholson: where is the top binary located in freebsd ? |
| 22:00.32 | mvanbaak | whereis top |
| 22:03.07 | mnicholson | mvanbaak, i know nothing about freebsd :) |
| 22:03.19 | mnicholson | oh, you want me to run that cmd. 1 sec |
| 22:04.21 | mvanbaak | uhhuh |
| 22:05.47 | mnicholson | mvanbaak, /user/bin/top |
| 22:05.53 | mvanbaak | thank you |
| 22:07.59 | lmadsen | fails at making releases :) |
| 22:09.00 | mvanbaak | fails at understanding how they find out the number of cpu's in freebsd |
| 22:12.05 | mvanbaak | ok, I'll have to look at it tomorrow |
| 22:12.10 | mvanbaak | it's time to go to bed here |
| 22:12.52 | mvanbaak | lmadsen, russellb, anyone: dont branch 1.6.2 before I fixed that sysinfo stuff on freebsd mkay ? |
| 22:12.59 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-20-153.hsd1.sc.comcast.net) |
| 22:12.59 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 22:13.02 | lmadsen | mvanbaak: there will be no branching today |
| 22:13.20 | mvanbaak | k |
| 22:13.52 | Corydon76-dig | branches lmadsen and merges in his sexuality branch |
| 22:14.13 | russellb | O.O |
| 22:15.21 | Corydon76-dig | russellb: experimental code ;-) |
| 22:15.47 | lmadsen | o.O |
| 22:16.05 | russellb | oh dear |
| 22:24.02 | mvanbaak | gheh |
| 22:24.08 | mvanbaak | latero all |
| 22:42.24 | Qwell | If I'm getting undefined reference to 'SSL_new' when trying to build against c-client... that probably means I need an -lssl, doesn't it? |
| 22:44.08 | putnopvut | Qwell: yeah, most likely |
| 22:44.17 | putnopvut | apt-get install libssl-dev or some such on ubuntu. |
| 22:44.19 | Qwell | and probably crypto, and...pam? |
| 22:44.28 | Qwell | putnopvut: it's installed |
| 22:44.31 | putnopvut | hrm |
| 22:44.45 | putnopvut | Qwell: or you could compile c-client without ssl support. |
| 22:44.49 | putnopvut | But I wouldn't recommend it. |
| 22:44.51 | Qwell | not an option |
| 23:03.25 | *** part/#asterisk-dev russellb (n=russellb@asterisk/digium-open-source-team-lead/russellb) |
| 23:04.10 | *** join/#asterisk-dev Trido (i=trido@ppp178-168.static.internode.on.net) |
| 23:06.11 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-20-153.hsd1.sc.comcast.net) |
| 23:06.11 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 23:10.19 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@local.xorcom.com) |
| 23:10.25 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 23:48.21 | Corydon76-dig | pokes lmadsen |