| 00:05.27 | seanbright | is listening to the new MoH for the first time... |
| 00:06.54 | seanbright | it's... jazzy |
| 00:08.33 | *** join/#asterisk-dev jmspeex_ (n=jmspeex@modemcable112.109-81-70.mc.videotron.ca) |
| 00:19.12 | seanbright | and then techno-y |
| 00:53.37 | *** join/#asterisk-dev Deeewayne (n=dwayne@c-71-228-179-90.hsd1.al.comcast.net) |
| 00:53.37 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 01:08.09 | *** join/#asterisk-dev Qwell (i=north@pdpc/sponsor/digium/Qwell) |
| 01:08.09 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 01:08.40 | *** join/#asterisk-dev russellb (n=russellb@asterisk/digium-open-source-team-lead/russellb) |
| 01:08.40 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 01:08.43 | *** join/#asterisk-dev file (n=file@asterisk/developer-and-muffin-lover/file) |
| 01:08.43 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 03:34.15 | *** join/#asterisk-dev Juggie (n=Juggie@CPE001601df17fb-CM001ceac25ada.cpe.net.cable.rogers.com) |
| 03:42.15 | *** part/#asterisk-dev shido6 (n=shido6@74-132-202-71.dhcp.insightbb.com) |
| 03:55.20 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 03:55.20 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 05:07.09 | *** join/#asterisk-dev errotan (n=errotan@62.201.123.132) |
| 05:57.43 | *** join/#asterisk-dev |Cybex| (n=John@atwork-26.r-212.178.82.atwork.nl) |
| 06:53.00 | *** join/#asterisk-dev obnauticus (n=obnautic@about/windows/regular/obnauticus) |
| 07:11.50 | *** join/#asterisk-dev tamiel (n=tamiel@213.30.183.226) |
| 07:30.04 | *** join/#asterisk-dev obnauticus (n=obnautic@about/windows/regular/obnauticus) |
| 07:46.49 | *** join/#asterisk-dev Pazzo (n=ugelt@195.254.225.136) |
| 08:06.32 | *** join/#asterisk-dev obnauticus (n=obnautic@about/windows/regular/obnauticus) |
| 08:09.48 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@local.xorcom.com) |
| 08:09.48 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 08:39.33 | *** join/#asterisk-dev _ys (n=ys@xgw.infor.net.ru) |
| 08:59.27 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@local.xorcom.com) |
| 08:59.27 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 10:05.07 | *** join/#asterisk-dev XoplqoX (n=XoplqoX@i59F533AD.versanet.de) |
| 10:15.45 | *** join/#asterisk-dev Dovid (n=annon@tony09-118-62.inter.net.il) |
| 10:15.48 | Dovid | j #asterisk-cli |
| 11:27.32 | *** join/#asterisk-dev denon (i=denon@sassinak.net) |
| 11:35.28 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:35.28 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:38.24 | *** join/#asterisk-dev Victor_Yure (n=victor@unaffiliated/victoryure/x-837844) |
| 11:42.17 | *** join/#asterisk-dev DarkRift (n=dark@modemcable015.68-200-24.mc.videotron.ca) |
| 11:44.18 | *** join/#asterisk-dev micols (n=mio@81.161.188.225) |
| 11:47.05 | *** join/#asterisk-dev Iamnacho (i=Iamnacho@ip98-186-180-143.ks.ks.cox.net) |
| 11:58.34 | *** join/#asterisk-dev smurf (n=smurf@debian/developer/smurf) [NETSPLIT VICTIM] |
| 12:06.35 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:28.25 | *** join/#asterisk-dev eliel (n=eliels@200.61.172.61) |
| 12:28.25 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 13:08.53 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:08.53 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 13:09.31 | XoplqoX | Hello i have write an experimental prototype channel which read raw alaw data form a file.The function ast_channel_set_fd uses the fd from the file. If the channel state is AST_STATE_UP this warnig rise up [Sep 29 14:59:17] WARNING[6068]: translate.c:168 framein: no samples for alawtoulaw. Has some one an idea what i make wrong. |
| 13:18.04 | kpfleming | you really don't want to use a file fd for a channel, it will always be ready for reading |
| 13:18.21 | kpfleming | and once the file has reached its end, you'll have a major problem |
| 13:18.44 | kpfleming | and we already have ways to read audio from files :-) |
| 13:34.55 | XoplqoX | i only want read audio data from a file to understand how an channel works. I know about the problem with the end and the readability of an regular file. Which ways could be used for reading audio form files |
| 13:35.08 | kpfleming | ast_filestream |
| 13:35.18 | kpfleming | that's how we read from files |
| 13:35.26 | *** join/#asterisk-dev Deeewayne (n=dwayne@75.76.254.162) |
| 13:35.26 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 13:43.18 | *** join/#asterisk-dev Ta^3 (n=tacvbo@189.146.181.137) |
| 13:44.14 | *** join/#asterisk-dev Victor_Yure (n=victor@unaffiliated/victoryure/x-837844) |
| 13:49.41 | tzafrir_laptop | make the file a pipe |
| 13:51.17 | tzafrir_laptop | and have the process writing there sleep occasionally: while :; do dd if=/dev/urandom bs=$whatever count=1; sleep $some_time; done # and you're done :-) |
| 13:52.52 | atis_work | huh, that will sound terribly :p |
| 13:53.30 | *** join/#asterisk-dev PoWeRKiLL (n=powerkil@bzq-79-180-19-231.red.bezeqint.net) |
| 14:01.34 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 14:17.30 | *** join/#asterisk-dev putnopvut (n=putnopvu@asterisk/master-of-queues/mmichelson) |
| 14:17.30 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:39.52 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 14:40.00 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 14:55.17 | atis_work | putnopvut: do you have any idea why queue_unref calls destroy_queue? |
| 14:55.17 | atis_work | http://pastebin.ca/1584376 |
| 14:55.31 | putnopvut | atis_work: if the reference count for a queue becomes 0, then destroy_queue is called. |
| 14:55.54 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:55.54 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:56.00 | atis_work | uh, i wonder then how reference count could have become 0 |
| 14:57.48 | atis_work | umm, shouln't all queues be held in global list? |
| 14:58.14 | atis_work | it seems that queue_function_qac_dep just creates another copy and then it gets destroyed |
| 14:58.47 | atis_work | the same would be true for queue_function_qac |
| 14:59.42 | atis_work | ok, ignore it, load_realtime_queue does ao2_find |
| 15:00.27 | putnopvut | but it's a very bad thing that a queue being destroyed is causing an infinite recursion problem. |
| 15:01.07 | atis_work | i've seen it few times, and thought that it's fault of my patch, but now i'm testing vanilla 1.6.1 |
| 15:01.34 | *** join/#asterisk-dev |Cybex| (n=John@80.100.126.176) |
| 15:01.42 | atis_work | i'm going to make a record of posted backtraces/issues in a week :) |
| 15:04.35 | atis_work | actually it's not recursion, each new call to remove_from interfaces use different interface |
| 15:08.18 | *** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/active/jeffg) |
| 15:08.37 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:08.37 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:09.01 | *** join/#asterisk-dev dwery (n=dwery@nslu2-linux/dwery) |
| 15:12.26 | *** join/#asterisk-dev _ys (n=Miranda@236-070.nat.mns.ru) |
| 15:16.47 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 15:28.01 | atis_work | putnopvut: i think i had really unusual conditions for that crash. asterisk was just getting up from another crash, and had bunch of calls hitting it |
| 15:30.54 | *** join/#asterisk-dev moy (n=moy@74.12.135.147) |
| 15:31.49 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 15:31.49 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 15:43.59 | *** join/#asterisk-dev denon (i=denon@sassinak.net) |
| 15:58.58 | *** join/#asterisk-dev Ta^3 (n=tacvbo@189.146.181.137) |
| 16:07.32 | *** join/#asterisk-dev shido6 (n=shido6@74.132.202.71) |
| 16:11.14 | *** join/#asterisk-dev marv[work] (n=timr@router.asteriasgi.com) |
| 16:15.26 | *** join/#asterisk-dev tnt_ (n=tnt_@32.81-242-81.adsl-dyn.isp.belgacom.be) |
| 16:21.11 | tnt_ | I'm having a little trouble when dealing with incoming call in a channel driver. Basically, I get a di |
| 16:21.14 | tnt_ | al request from a cell phone containing the extension to dial, I create the channel in asterisk with e |
| 16:21.17 | tnt_ | xten and context set. Then I get a call back to 'answer' but I need time to negotiate a voice channel |
| 16:21.20 | tnt_ | with the cell phone, it's not instant. How can I 'hold off' and signal later when the answer is done ? |
| 16:27.41 | Corydon76-dig | tnt_: #asterisk |
| 16:30.52 | kpfleming | no, this is really a dev question |
| 16:31.04 | tnt_ | Corydon76-dig: I just asked again there but that seems like a non-trivial channel driver coding question ... |
| 16:31.21 | kpfleming | tnt_: you will need to *not* put the channel into AST_STATE_UP until it is actually up |
| 16:31.43 | kpfleming | however, i would really suggest that you setup the voice channel before ever launching the channel into the PBX |
| 16:32.04 | kpfleming | because the dialplan is going to expect to be able send and receive audio to the devie |
| 16:32.20 | tnt_ | kpfleming: But I dont put it UP, asterisk kinda does it without asking me in ast_raw_answer. |
| 16:34.06 | tnt_ | kpfleming: But an full on audio channel takes RF bandwidth and when activated, the cell phone will display the call as answered and not 'in progress'. |
| 16:35.22 | kpfleming | the other channel (the one you dialed from the dialplan) is responsible for setting the channel state to UP |
| 16:35.24 | kpfleming | if you are the calling channel, you can't delay that process |
| 16:35.44 | *** join/#asterisk-dev Marquis42 (n=bfhbmw0@65-127-126-34.dia.static.qwest.net) |
| 16:39.06 | tnt_ | kpfleming: Mmm, damn too bad. Also, what's with the ast_indicate condition=-1 ? What's the purpose of this ? |
| 16:39.15 | *** join/#asterisk-dev errotan (n=errotan@5403E700.catv.pool.telekom.hu) |
| 16:39.53 | kpfleming | to tell your channel driver to stop playing any indication tones that may have been previously requests |
| 16:41.29 | tnt_ | Ok thanks. I'll rethink my call logic to deal with the answer issue. |
| 16:45.20 | *** join/#asterisk-dev Victor_Yure (n=victor@unaffiliated/victoryure/x-837844) |
| 17:07.31 | *** join/#asterisk-dev hugorebelo (n=hugorebe@200.171.132.124) |
| 17:14.54 | *** join/#asterisk-dev xpot-mobile (n=james@173.8.94.1) |
| 17:16.46 | *** join/#asterisk-dev Iamnach0 (i=Iamnacho@ip98-186-180-143.ks.ks.cox.net) |
| 17:24.22 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 17:24.22 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 18:06.28 | *** join/#asterisk-dev Ta^3 (n=tacvbo@189.180.37.69) |
| 18:10.46 | *** join/#asterisk-dev jnfuller (n=jnfuller@99.199.153.211) |
| 18:12.00 | jnfuller | Hey guys, I'm a little confused about the svn versions. Is trunk based of 1.4 or 1.6? |
| 18:14.02 | Corydon76-dig | Neither |
| 18:14.13 | Corydon76-dig | Trunk is the main development tree |
| 18:14.34 | Corydon76-dig | 1.4 was branched off trunk at a certain time in the past, as was 1.6.0, 1.6.1, and 1.6.2. |
| 18:15.33 | jnfuller | ah so if I want to stick with 1.6.1 I should use the branch instead of trunk. the wording on asterisk.org was a bit confusing |
| 18:15.38 | Corydon76-dig | Your question basically was whether the trunk of a tree grew out of the left branch or the right branch, which is nonsensical |
| 18:16.08 | Corydon76-dig | If you want to stick with 1.6.1, you use the branch, correct |
| 18:16.10 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 18:16.33 | Corydon76-dig | A release is a snapshot of that branch at a particular time. |
| 18:16.35 | *** join/#asterisk-dev CunningPike (n=CunningP@204.239.8.157) |
| 18:17.44 | seanbright | also called a 'tag' |
| 18:18.16 | jnfuller | cool makes sense now, was reading "latest version of svn code" on asterisk.org and wondering if that meant it was 1.6.2 |
| 18:18.32 | seanbright | latest revision of a given branch |
| 18:18.32 | jnfuller | but your explanation clears things up |
| 18:18.37 | seanbright | that was probably the intent |
| 18:18.43 | seanbright | what page is this? |
| 18:19.24 | jnfuller | http://www.asterisk.org/developers/getting-started |
| 18:19.39 | jnfuller | sorry, reads "newest version of svn code" not latest |
| 18:20.25 | seanbright | yeah, the wording is a little unclear |
| 18:20.46 | seanbright | it's like we have the code to subversion in /trunk |
| 18:24.46 | jnfuller | that page is pretty out of date, still references zaptel |
| 18:34.37 | jnfuller | anyway, thanks for the help, downloading the right branches now |
| 18:48.30 | seanbright | am i the only one not getting commit messages? |
| 18:48.38 | seanbright | (svn-commits) |
| 18:50.24 | Corydon76-dig | seanbright: you're not the only one seeing problems |
| 18:50.31 | seanbright | k |
| 18:50.42 | *** part/#asterisk-dev jnfuller (n=jnfuller@99.199.153.211) |
| 18:51.01 | kpfleming | M15987 |
| 18:51.56 | file | that's odd... |
| 18:52.26 | *** join/#asterisk-dev MuffinMan (n=muffinma@asterisk/issue-tracker-bot/muffinman) |
| 18:52.43 | kpfleming | M15987 |
| 18:52.45 | MuffinMan | [assigned] [Asterisk] Core/General 0015987: ao2_iterator_init() does not hold a reference to the container it is iterating reported by kpfleming (Karma: +103.00) https://issues.asterisk.org/view.php?id=15987 |
| 18:52.50 | kpfleming | that's better |
| 18:53.59 | mnicholson | should app_confbridge answer the channel automatically? app_meetme does. |
| 18:54.17 | kpfleming | is there an option to do so? |
| 18:54.22 | mnicholson | no |
| 18:54.28 | mnicholson | at least not in 1.6.2 |
| 18:54.47 | seanbright | i would just say "no: |
| 18:54.48 | seanbright | "no" |
| 18:55.01 | seanbright | Answer() ftw |
| 18:58.30 | mnicholson | seanbright, can you think of any cases where you would want to use it without first answering the channel? |
| 18:58.41 | seanbright | i can't, no. |
| 18:58.49 | seanbright | but that doesn't mean one of our users won't come up with something |
| 18:59.01 | seanbright | and as we see every day, they always come up with something |
| 18:59.04 | mnicholson | true, but it seems pretty useless on unanswered channels |
| 18:59.27 | seanbright | i'm not really opposed to doing it automatically |
| 18:59.47 | seanbright | i'm opposed to adding a flag/option |
| 19:00.08 | mnicholson | i was thinking it should be done automatically, like in app_meetme and other apps |
| 19:01.28 | seanbright | my thought process: |
| 19:02.05 | seanbright | we don't do it automatically, the user has to call Answer() first, people say "that's weird" but at the end of the day it works |
| 19:02.42 | seanbright | we do it automatically, 2 releases from now a bug pops up on mantis "ZOMGWTF do you answer the chanel!? my CDRs are all messed up!" |
| 19:02.43 | kpfleming | we are trying to avoid adding implicit behavior that then requires options to turn it off |
| 19:03.03 | kpfleming | especially when the explicit version is so easy |
| 19:03.09 | seanbright | yes |
| 19:03.12 | seanbright | what he said. |
| 19:03.19 | kpfleming | if you want to make it not require calling Answer(), add an option the force the channel to be answered |
| 19:03.27 | seanbright | ugh |
| 19:04.27 | seanbright | why would you do that? |
| 19:04.38 | kpfleming | personally i wouldn't |
| 19:04.58 | kpfleming | but it's possible that someone might want to run ConfBridge directly from an originate action/call file/etc. where they don't have the option to call Answer() first |
| 19:05.33 | mnicholson | there is a simple work around for that too, they can just drop the call into the dialplan, Answer, then Bridge |
| 19:05.34 | seanbright | then you go to an exten/context instead of directly to an app |
| 19:05.42 | kpfleming | yes, i understand |
| 19:05.56 | kpfleming | i'm just saying that it wouldn't be an objectionable thing to add, it has some limited use |
| 19:06.02 | *** join/#asterisk-dev WHYS (n=drumm@137.28.94.209) |
| 19:06.11 | seanbright | it just junks things up |
| 19:06.34 | mnicholson | ok, I'll leave it as is and close out this bug then. Maybe we should document the fact that the channel will not be automatically answered. |
| 19:07.04 | leifmadsen | if it is different than other apps that auto-answer, then I'd say it should be documented in the XML |
| 19:07.14 | mnicholson | there is no way to know that without out trying it or looking at the source, additionally app_meetme *does* automatically answer the channel, so it could be confusing |
| 19:07.45 | seanbright | what issue is this? |
| 19:09.06 | mnicholson | 15964 |
| 19:10.33 | seanbright | well, my vote is 'no change required' |
| 19:10.49 | leifmadsen | my vote is documentation change required :) |
| 19:10.56 | mnicholson | mine too |
| 19:11.05 | seanbright | well, sure. |
| 19:11.09 | seanbright | no code change required. |
| 19:13.04 | mnicholson | ok, ill make a note in the app's documentation |
| 19:13.49 | seanbright | someone will make it auto answer one day. |
| 19:14.07 | seanbright | when no one is around to protect it. |
| 19:14.16 | seanbright | heh |
| 19:14.24 | mnicholson | lol |
| 19:18.29 | tnt_ | If I wrote support for gsm AMR codec & format for Asterisk, could that be merged ? Or does the whole patent issue be a problem ? |
| 19:19.01 | seanbright | the patent issue would be a problem |
| 19:20.12 | tnt_ | seanbright: Even if the actual AMR code is in fact a shared library that would have to be installed separatly ? |
| 19:21.02 | seanbright | eh... shady |
| 19:21.15 | seanbright | (ianal) |
| 19:25.41 | tnt_ | seanbright: Yeah neither am I, but I don't really want to pay one to find out ... this sucks. |
| 19:26.29 | seanbright | nothing stopping you from writing and distributing it yourself |
| 19:29.35 | atis_work | regarding answer, i don't know any app that would require Answer before it does something with audio, so i would recommend having the same behaviour |
| 19:30.25 | atis_work | there is explicit flag for Queue to not answer, and so on |
| 19:31.10 | tnt_ | seanbright: yes, but if it's not mergeable, that means there _are_ indeed legal issues that could somehow be a problem for people to use it or to me distribute it. |
| 19:32.44 | tnt_ | OTOH, looking at the patent DB on AMR from ETSI, they seem to all be US patents and so irrelevant to me ... |
| 19:33.09 | seanbright | tnt_: there would be legal issues using the shared library, so what's the difference? |
| 19:34.15 | tnt_ | seanbright: I'm not the one distributing the sharedlibrary, it already exists :) |
| 19:34.30 | seanbright | but the legal issues for the "consumer" are the same |
| 19:34.58 | seanbright | "... that could somehow be a problem for people to use it..." |
| 19:35.15 | tnt_ | yes. |
| 19:37.09 | tnt_ | yes, I know what I said. It's not perfect but you don't have to go an tell everyone you're using it. |
| 19:37.56 | mnicholson | wouldn't your system tell everyone who called you that you were using it :) |
| 19:38.09 | seanbright | i was about to say the same thing |
| 19:38.23 | seanbright | but i didn't answer() first so you didn't hear me |
| 19:38.30 | mnicholson | seanbright, lol |
| 19:39.38 | seanbright | i'm starting to come around to the auto answer idea, mnicholson. |
| 19:39.50 | seanbright | with flag to disable. |
| 19:40.22 | tnt_ | mnicholson: well, my cell phone doesn't really display visually what codec it's using, you'd have to go out of your way to find out. |
| 19:40.34 | tnt_ | :) |
| 19:40.41 | seanbright | just trying to figure out the over/under on number of mantis issues opened as a result of it not auto-answering. |
| 19:40.42 | mnicholson | tnt_, well your phone company knows :), but this is true |
| 19:41.20 | mnicholson | seanbright, i am going to commit a note for the documentation, everyone will read it. Everything will be ok. |
| 19:41.28 | seanbright | alrighty |
| 19:41.50 | seanbright | but... but... but... |
| 19:41.51 | seanbright | heh |
| 19:42.22 | mnicholson | heh, maybe people will read the docs when it breaks |
| 19:42.34 | seanbright | silly mnicholson |
| 19:42.52 | atis_work | dream on :) |
| 19:43.46 | mnicholson | we all have our dreams :) |
| 19:44.41 | atis_work | maybe malloc will free itself when not needed? :) |
| 19:44.49 | *** join/#asterisk-dev ebroad (n=EB@72.11.213.195) |
| 19:49.23 | ebroad | when a trunk sends a + preceding the number, should asterisk be including this in the rpid sent to the extension? |
| 20:18.44 | putnopvut | file: May I make a humble suggestion regarding the RTP engine? Please set the debug levels of the messages printed in ast_rtp_codecs_payloads_clear and ast_rtp_codecs_payloads_code higher than they are now. Thanks! |
| 20:19.02 | file | go ahead! |
| 20:19.05 | file | I approve. |
| 20:19.07 | kpfleming | or eliminate them |
| 20:19.14 | kpfleming | at least the clear ones |
| 20:19.36 | putnopvut | I think I'll just kill them. |
| 20:20.50 | kpfleming | umm... why do we have a configure script test for __attribute__((deprecated)) that we don't use the result of? |
| 20:21.12 | seanbright | maybe we did at one point? |
| 20:22.22 | seanbright | commit asterisk 91032 |
| 20:22.23 | MuffinMan | [91032] Committed by russell on 2007-12-04T23:46:40.058748Z: Modify file.h to maintain API compatibility with earlier versions. If a recent |
| 20:22.23 | MuffinMan | ..compiler is being used, then a warning will show up for any modules still using |
| 20:22.23 | MuffinMan | ..the old name "private" instead of "_private". |
| 20:22.23 | MuffinMan | ..(patch suggested by paravoid) |
| 20:22.23 | MuffinMan | .. |
| 20:22.25 | MuffinMan | .. http://svn.digium.com/view/asterisk?view=rev&revision=91032 |
| 21:07.51 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 21:23.50 | *** join/#asterisk-dev Victor_Yure (n=victor@unaffiliated/victoryure/x-837844) |
| 21:33.31 | *** join/#asterisk-dev jmworx (n=jeval@mail.octasic.com) |
| 22:15.56 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@212.179.75.202) |
| 22:15.56 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 23:10.03 | *** join/#asterisk-dev Iamnacho (i=Iamnacho@ip98-186-180-143.ks.ks.cox.net) |
| 23:13.27 | seanbright | russellb: thanks, pal. |
| 23:13.41 | seanbright | i need constant validation. otherwise i can't make it out of bed in the morning. |
| 23:13.45 | seanbright | :) |
| 23:38.31 | russellb | seanbright: heh, sorry about that. I remembered talking with someone(s) about that idea forever ago, but didn't remember who/when/where. |
| 23:38.36 | russellb | I just remembered the good idea ... |
| 23:38.43 | seanbright | i really don't care |
| 23:38.48 | seanbright | well |
| 23:38.49 | seanbright | that's not true |
| 23:38.53 | seanbright | but it's not big deal |
| 23:38.54 | seanbright | :) |