| 00:00.47 | *** join/#asterisk-dev BBHoss (n=bbhoss@68.159.148.181) |
| 00:21.54 | *** join/#asterisk-dev outtolunc (n=me@c-71-198-197-201.hsd1.ca.comcast.net) |
| 00:54.48 | *** join/#asterisk-dev jameswf (n=james@unaffiliated/jameswf-home) |
| 01:16.17 | *** join/#asterisk-dev snuff-work (n=aaa@203.19.141.34) |
| 01:16.17 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 01:21.44 | *** join/#asterisk-dev jameswf-home (n=james@unaffiliated/jameswf-home) |
| 01:34.38 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 01:34.41 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 01:37.46 | pmhaddad | so uh digium should so totally sell a tshirt that is black with the asterisk logo in orange |
| 01:37.57 | pmhaddad | this white and orange stuff needs to go |
| 01:48.15 | *** join/#asterisk-dev jameswf (n=james@unaffiliated/jameswf-home) |
| 01:55.01 | *** join/#asterisk-dev Deeewayne (n=dwayne@c-76-29-245-9.hsd1.al.comcast.net) |
| 01:55.01 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 01:59.48 | *** join/#asterisk-dev tuxd00d (n=tuxd00d@128.187.128.72) |
| 02:15.22 | *** join/#asterisk-dev obnauticus (n=obnautic@about/windows/regular/obnauticus) |
| 02:20.26 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 02:51.07 | *** join/#asterisk-dev djbelieny (n=djbelien@72-48-61-165.dyn.grandenetworks.net) |
| 02:51.13 | *** part/#asterisk-dev djbelieny (n=djbelien@72-48-61-165.dyn.grandenetworks.net) |
| 03:05.02 | *** join/#asterisk-dev russellb (n=russell@asterisk/digium-open-source-team-lead/russellb) |
| 03:05.02 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 03:05.58 | *** join/#asterisk-dev double_cheesburg (n=chatzill@ip70-162-238-155.ph.ph.cox.net) |
| 03:45.15 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 03:45.15 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 03:52.41 | *** join/#asterisk-dev felipe_ (n=felipe@my.nada.kth.se) |
| 04:01.09 | *** join/#asterisk-dev De_Mon (i=de_mon@fl-67-77-166-5.dyn.embarqhsd.net) |
| 04:19.50 | *** join/#asterisk-dev schmooze_tony (n=schmooze@rrcs-67-52-212-6.west.biz.rr.com) |
| 04:39.48 | codefreeze-lap | pmhaddad: I've got a few Black ones with white lettering.... close... |
| 04:42.25 | *** join/#asterisk-dev mog (n=mog@c-68-62-218-186.hsd1.al.comcast.net) |
| 04:42.25 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 05:37.23 | pmhaddad | codefreeze-lap, that would work |
| 05:37.32 | pmhaddad | they sell those officially? |
| 05:41.43 | *** join/#asterisk-dev denon (i=denon@synapse.subneural.net) |
| 05:57.48 | codefreeze-lap | pmhaddad: don't know. Picked up mine 2 years ago at Astricon |
| 05:58.06 | pmhaddad | codefreeze-lap, ah cool. hopin to make it out there this year |
| 05:58.24 | codefreeze-lap | me too... |
| 07:00.12 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 07:24.34 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@local.xorcom.com) |
| 07:24.40 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 07:26.08 | mvanbaak | gheh, looking at the summary pages russell created I see a lot of stuff I do states "make X compile on OpenBSD" ;) |
| 07:38.38 | *** join/#asterisk-dev fiddur (i=fiddur@c042.rit.se) |
| 07:47.40 | fiddur | Good morning :) |
| 07:51.58 | *** join/#asterisk-dev contactramu (n=contactr@123.201.69.115) |
| 07:59.13 | *** part/#asterisk-dev contactramu (n=contactr@123.201.69.115) |
| 08:04.24 | *** join/#asterisk-dev jmworx (n=jeval@mail.octasic.com) |
| 08:11.32 | *** join/#asterisk-dev schmooze_tony (n=schmooze@h69-129-142-83.mdsnwi.tisp.static.tds.net) |
| 08:21.30 | *** join/#asterisk-dev tamiel (n=tamiel@213.30.183.226) |
| 09:53.47 | oej | morning |
| 09:55.37 | mvanbaak | hey oej |
| 09:57.15 | *** join/#asterisk-dev jcollie (n=jcollie@fedora/jcollie) |
| 10:05.35 | *** join/#asterisk-dev lbt (n=david@78.32.229.233) |
| 10:21.16 | *** join/#asterisk-dev snuff-work (n=aaa@120.17.130.214) |
| 10:21.16 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 10:23.14 | *** join/#asterisk-dev frawd (n=francois@248.pool85-49-240.dynamic.orange.es) |
| 10:23.33 | *** part/#asterisk-dev frawd (n=francois@248.pool85-49-240.dynamic.orange.es) |
| 10:32.22 | tzafrir_laptop | mvanbaak, I think that it's the commit message that should be fixed, then |
| 10:33.01 | tzafrir_laptop | The first line of the commit message should be its summary |
| 10:33.01 | mvanbaak | eh ? |
| 10:33.17 | mvanbaak | you refer to my remark here or my remark on the ml ? |
| 10:33.43 | tzafrir_laptop | the one on the ML |
| 10:34.09 | mvanbaak | ah. yeah. |
| 10:34.20 | mvanbaak | that, or the script they created should do some more work |
| 10:34.22 | tzafrir_laptop | And yes, we should make it a habit of breaking OpenBSD :-) |
| 10:34.37 | mvanbaak | lol. |
| 10:35.09 | mvanbaak | if so, I'll end up on top of that list, fixing OpenBSD after every commit |
| 10:37.44 | fiddur | How can I develop anything in trunk if it just core dumps as soon as I do anything? :P I guess I'm supposed to trace it and make bug reports, but I don't really have time for that, when I can develop in branch 1.6.0. But, I can say that realtime queues at least is very unstable in trunk right now :P |
| 10:41.45 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 10:42.39 | *** join/#asterisk-dev ChanServ (ChanServ@services.) |
| 10:42.39 | *** mode/#asterisk-dev [+o ChanServ] by irc.freenode.net |
| 11:16.32 | *** join/#asterisk-dev Pazzo (n=ugelt@reserved-225136.rol.raiffeisen.net) |
| 11:39.04 | *** join/#asterisk-dev shazaum (n=shazaum@unaffiliated/shazaum) |
| 11:47.15 | snuff-work | mm i love the summary thing |
| 11:50.52 | *** join/#asterisk-dev qdk (n=qdk@81.7.168.130) |
| 11:59.38 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:40.32 | *** join/#asterisk-dev mvanbaak (n=michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 12:40.32 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 12:42.09 | *** part/#asterisk-dev oej (n=olle@ns.webway.se) |
| 12:43.37 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 12:43.37 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:51.21 | *** join/#asterisk-dev mvanbaak (n=michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 12:51.21 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 12:53.21 | *** join/#asterisk-dev mvanbaak (n=michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 12:53.22 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 12:54.09 | sergee | what is the best way to get remote IP addr using sip_pvt ? |
| 12:54.42 | sergee | in case of udp transport |
| 12:56.47 | sergee | sip_pvt->relatedpeer->addr ? |
| 13:26.46 | fiddur | Hi. I've added a queue-setting to disregard members penalties when there are fewer than 'penaltymemberslimit' members in the queue. I'd be glad to hear comments http://bugs.digium.com/view.php?id=14559 |
| 13:49.45 | *** join/#asterisk-dev Mr_BOnD_007 (i=Mr_BOnD_@119.160.199.6) |
| 13:55.11 | *** join/#asterisk-dev ctooley (n=ctooley@mo-71-0-218-176.dhcp.embarqhsd.net) |
| 13:55.11 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 14:00.43 | tzafrir_laptop | yikes. What happened to LWN? Shock waves of the article oabout jtodd's presentation? |
| 14:14.20 | kpfleming | LWN is up for me |
| 14:22.39 | *** join/#asterisk-dev file (n=file@asterisk/developer-and-muffin-lover/file) |
| 14:22.39 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 14:32.50 | *** join/#asterisk-dev djbelieny (n=djbelien@72-48-61-165.dyn.grandenetworks.net) |
| 14:33.32 | *** part/#asterisk-dev djbelieny (n=djbelien@72-48-61-165.dyn.grandenetworks.net) |
| 14:35.09 | *** join/#asterisk-dev pmhaddad-work (n=pmhaddad@141.219.87.43) |
| 14:43.04 | *** join/#asterisk-dev russellb (n=russell@asterisk/digium-open-source-team-lead/russellb) |
| 14:43.04 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 14:45.48 | *** join/#asterisk-dev shazaum (n=shazaum@unaffiliated/shazaum) |
| 14:49.48 | tzafrir_laptop | kpfleming, up. But the layout has changed. For the worse |
| 14:50.59 | *** join/#asterisk-dev Mr_BOnD_007 (i=Mr_BOnD_@119.160.199.6) |
| 14:51.51 | festr_ | russellb: hi, I was talking yesterday about asterisk and smp. I had bad monitoring tool. There is no single thread which consumes more than 1-3%. |
| 14:52.08 | russellb | oic :-) |
| 14:52.19 | festr_ | if anyone uses htop make sure you have the latest version :) |
| 14:52.23 | festr_ | russellb: what is oic? :) |
| 14:52.29 | russellb | "oh, i see" |
| 14:52.34 | festr_ | :) |
| 14:53.04 | Mr_BOnD_007 | russellb if you dont mind can you answer my question ? |
| 14:54.00 | Mr_BOnD_007 | if i want to use only GUI dont Want to Dial The Number is it possible ? in asterisk ? just it will show the Number Name Street Disposition ETC. (VICIDIAL ) |
| 14:54.11 | russellb | #asterisk, please |
| 14:54.17 | Mr_BOnD_007 | okie sir sory |
| 14:54.19 | *** part/#asterisk-dev Mr_BOnD_007 (i=Mr_BOnD_@119.160.199.6) |
| 14:54.25 | festr_ | btw, I've done some measurent of cpu and load between debian etch and half (which means gernel 2.6.24 and gcc 4.1) 32bit version and amd64bit version on INTEL xeon 54XX series on P500PAL. Interesting is, that 32bit version is slightely faster. |
| 14:54.26 | *** join/#asterisk-dev Mr_BOnD_007 (i=Mr_BOnD_@119.160.199.6) |
| 14:56.34 | festr_ | testing with 240 calls on 8span E1 sangoma alaw codec to SIP |
| 14:58.27 | *** join/#asterisk-dev jameswf (n=james@unaffiliated/jameswf-home) |
| 15:01.02 | *** join/#asterisk-dev moy (n=chatzill@74.12.124.158) |
| 15:20.47 | *** join/#asterisk-dev Mog (n=mog@c-68-62-218-186.hsd1.al.comcast.net) |
| 15:20.47 | *** mode/#asterisk-dev [+o Mog] by ChanServ |
| 15:25.48 | *** join/#asterisk-dev timeshell (n=chatzill@gw.lusi.on.ca) |
| 15:29.35 | *** join/#asterisk-dev Deeewayne (n=dwayne@nat/digium/x-95afeddcdaf2db97) |
| 15:29.35 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 15:42.28 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 15:42.56 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 15:42.56 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 15:44.40 | *** join/#asterisk-dev shazaum (n=shazaum@unaffiliated/shazaum) |
| 15:51.01 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 15:51.02 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 16:04.38 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 16:04.38 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 16:12.39 | *** join/#asterisk-dev docelmo (n=vircuser@pool-141-152-221-248.lyn.east.verizon.net) |
| 16:21.23 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 16:21.23 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 16:23.56 | *** join/#asterisk-dev shazaum (n=shazaum@unaffiliated/shazaum) |
| 16:25.23 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 16:40.58 | festr_ | I was wrong again... 64 bit has more stable load graphs than 32 bit. But overall cpu consuption is the same. |
| 16:42.16 | jsmith | still can't believe he wrote a patch for libpri yesterday |
| 16:45.48 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.10.119) |
| 16:50.04 | *** join/#asterisk-dev moy (n=moy@74.12.124.158) |
| 16:55.05 | Qwell | jsmith: gasp |
| 16:55.44 | jsmith | Qwell: Scary I know... what's even worse, is that I now understand more than I ever thought I could about transmitting bearer capabilities in Q.931 |
| 16:55.57 | jsmith | Qwell: (to the point I can quote chapter and verse in the bug report!) |
| 16:58.13 | *** join/#asterisk-dev jtodd (n=jtodd@nat/digium/x-3552028d45eea296) |
| 17:00.24 | *** join/#asterisk-dev qdk (n=qdk@81.7.168.130) |
| 17:02.43 | Qwell | jsmith: sorry to hear that |
| 17:02.51 | Qwell | must have been frightening |
| 17:04.03 | jsmith | Qwell: It really wasn't that bad... in fact, I kind of enjoyed it. |
| 17:05.26 | jsmith | Qwell: The best part was... my C skills weren't as rusty as I would have thought. My patch even compiled on the first try! |
| 17:05.41 | jsmith | Qwell: (and worked too!) |
| 17:22.44 | mvanbaak | woot ! |
| 17:28.41 | kpfleming | jsmith: the Q.931 specs have verses? how bizare |
| 17:29.03 | jsmith | kpfleming: Not only that, but they use all kinds of funny numbering too... |
| 17:39.35 | Corydon76-dig | jsmith: if it has verses, does it have a chorus, too? |
| 17:39.38 | Corydon76-dig | ducks |
| 17:41.37 | lmadsen | gooses |
| 17:42.08 | Corydon76-dig | wonders if lmadsen is doing testing today |
| 17:42.15 | lmadsen | Corydon76-dig: I am! |
| 17:42.25 | lmadsen | Probably shortly after lunch |
| 17:42.27 | *** join/#asterisk-dev _ys (n=Miranda@80.70.236.69) |
| 17:42.28 | jsmith | Corydon76-dig: Yes, the chorus is "Who writes these things?" |
| 17:42.31 | lmadsen | it is 9:42am here |
| 17:42.47 | lmadsen | I have a meeting at 11am, then I'll eat, then I'll do testing and triage all afternoon |
| 17:43.01 | Corydon76-dig | loads lmadsen up |
| 18:05.42 | *** join/#asterisk-dev Dovid (n=annon@tony09-121-90.inter.net.il) |
| 18:28.26 | *** part/#asterisk-dev snuff-work (n=aaa@120.17.130.214) |
| 18:39.19 | *** join/#asterisk-dev jcollie (n=jcollie@fedora/jcollie) |
| 18:58.55 | jpeeler | codefreeze-lap: i'm wondering if that feature timeout detection change warrants decreasing the default from 2000 to 1000 |
| 18:59.10 | kpfleming | i would think so |
| 18:59.16 | kpfleming | otherwise implicit behavior will change |
| 18:59.24 | jpeeler | well it was originally increased from 500 |
| 18:59.48 | kpfleming | if the 'units' have effectively changed, then the value should be changed to reflect that |
| 19:04.31 | *** join/#asterisk-dev alerios (n=alerios@190.144.75.22) |
| 19:09.01 | kpfleming | umm... hey |
| 19:09.27 | kpfleming | so i've come across a number of places where we call ast_frdup() on a frame to ensure we have a copy we own, and then free the original frame |
| 19:09.43 | kpfleming | however, the original frame may already have been completely dynamically allocated, in which case that is wasteful |
| 19:10.07 | kpfleming | we should instead call ast_frisolate(), and then only free the original frame if ast_frisolate() gave us a different one back |
| 19:10.23 | kpfleming | discuss |
| 19:11.17 | kpfleming | i expect a thorough analysis, conclusions and action plan when i return from lunch :-) |
| 19:11.22 | russellb | lol |
| 19:12.11 | mnicholson | will that work in all cases? |
| 19:13.16 | mnicholson | like say I have a frame with mallocd_data, I pass that to your function, you call ast_frisolate(), which copies non malloced parts, then call ast_frfree() (or i call ast_frfree(), expecting you to have duped the frame), the data will get freed and you will have a bad pointer on your hands |
| 19:15.59 | mnicholson | in order to ensure we have a unique copy, we have to always call ast_frdup() |
| 19:17.35 | mnicholson | we could make frames referenced counted, or partially reference counted to work around this, then ast_frisolate() could increase the ref count on any malloced parts and malloc any non malloced parts. That would still create problems if some one decided to reuse that frame for something else. |
| 19:30.24 | mnicholson | we need an optimized way to transfer ownership of a frame and it's data |
| 19:32.14 | mnicholson | right now, that is ast_frdup() |
| 19:34.44 | russellb | what he said, heh |
| 19:34.50 | russellb | mnicholson: nice analysis. |
| 19:37.19 | mnicholson | thx |
| 19:42.45 | jamessan | man, I wish I could do what kpfleming just did and have things get resolved at work :) |
| 19:43.00 | russellb | heh |
| 19:43.20 | russellb | kpfleming r0x0rz |
| 19:44.14 | mnicholson | jamessan, upgrade your co-workers :) |
| 19:44.41 | lmadsen | yum upgrade coworkers |
| 19:44.43 | mnicholson | jamessan, or open source your products and build a community to do the work for you :) |
| 19:44.46 | lmadsen | "No update found." |
| 19:44.50 | jamessan | mnicholson, I've been waiting for the upgrades to be released for a while |
| 19:44.58 | mnicholson | lol |
| 19:45.39 | lmadsen | anyone here compile asterisk on solaris? There is a fairly old bug open for it that has a patch that resolves 1 of the 2 build issues |
| 19:45.46 | lmadsen | curious if it's still an issue (I presume it is) |
| 19:45.57 | lmadsen | oops sorry... I thought I was in #asterisk-bugs :) |
| 19:47.08 | *** join/#asterisk-dev schmooze (n=schmooze@h69-129-142-83.mdsnwi.tisp.static.tds.net) |
| 19:52.00 | kpfleming | yes, while i was eating i realized my statement was slightly wrong |
| 19:52.21 | russellb | awww, it's ok :-) |
| 19:52.24 | russellb | good brain exercise |
| 19:52.43 | kpfleming | the sequence 'y = ast_frdup(x); ast_frfree(x);' can be replaced with 'if ((y = ast_frisolate(x)) != x) ast_frfree(x);' |
| 19:52.53 | kpfleming | this only works if you were going to free the original frame anyway |
| 19:53.20 | kpfleming | most of our API calls do not 'consume' frames they are given, so they can't do this |
| 19:55.10 | kpfleming | russellb: TRACE_FRAMES is going away... it's totally broken |
| 19:55.31 | kpfleming | even when it worked, it would only track a small subset of frames anyway |
| 19:56.21 | kpfleming | this patch is going to become the 'Omnibus Frame Handling Improvement Patch of 2009' |
| 19:56.21 | russellb | heh, okie dokie. |
| 19:56.41 | russellb | well, if it can be done in parts, it would make it easier to track down breakage if it exists |
| 19:56.46 | russellb | but if it has to be all at once, so be it |
| 19:56.55 | kpfleming | there will be no breakage! |
| 19:56.59 | russellb | not that you would ever cause breakage! |
| 19:57.00 | russellb | bows |
| 19:57.15 | file | kpfleming: dangerous words. |
| 19:57.21 | russellb | no kidding |
| 19:57.23 | kpfleming | and even though it is 1.4, there will be some optimizations included |
| 19:57.29 | ctooley | There are no bugs, only undocumented features. |
| 19:57.32 | russellb | kpfleming: *gasp* |
| 19:57.44 | file | I'm going to optimize the entire planet. |
| 19:57.50 | mnicholson | kpfleming, re: ast_frisolate(), yeah that sounds like it would work |
| 19:57.54 | Corydon76-dig | shifts russellb towards reviewboard |
| 19:58.09 | kpfleming | mnicholson: yes, but it's not a common idiom |
| 19:58.10 | russellb | has replace his reviewboard time allocation with some internal code review |
| 19:58.10 | russellb | sorry |
| 19:58.13 | russellb | replaced. |
| 19:58.17 | ctooley | has a plan for optimizing the planet. It includes IQ tests, shotguns and targets. |
| 19:58.36 | Corydon76-dig | replaces russell's home time with reviewboard time |
| 19:58.45 | russellb | i already do that a good amount, heh |
| 19:59.04 | russellb | maybe this weekend, we'll see .. |
| 19:59.06 | Corydon76-dig | What, shotguns? |
| 19:59.32 | ctooley | Corydon76-dig, stray shot is just a bonus. |
| 20:00.00 | mnicholson | ctooley, thats like -03, it's not always safe |
| 20:00.07 | Corydon76-dig | ctooley: bonus is getting your friend to apologize for getting shot in the face |
| 20:00.31 | ctooley | Corydon76-dig, that's just permission for getting a second chance to do it right. |
| 20:01.08 | mnicholson | s/-03/-O3/ |
| 20:01.42 | ctooley | mnicholson, safety is not in the optimization plan on purpose. |
| 20:02.20 | Corydon76-dig | gets a -O6 competitive upgrade |
| 20:03.07 | mnicholson | checks man gcc, doesn't see anything about -O3 being unsafe... hmm... |
| 20:11.27 | *** join/#asterisk-dev korihor (n=korihor@200.44.218.45) |
| 20:18.14 | codefreeze-lap | jpeeler: sorry I've been so long, been in & out for lunch, and missed your comment earlier about the default timeout.... My thoughts are these: a. the 1/4 sec timeout, er 500 in the config file) was impractically too short... really had to be nimble to be quick enough. |
| 20:18.28 | *** part/#asterisk-dev korihor (n=korihor@200.44.218.45) |
| 20:18.59 | jpeeler | codefreeze-lap: agreed, so if it was behaving as 250 before, 1000 is surely enough |
| 20:19.08 | *** join/#asterisk-dev korihor (n=korihor@200.44.218.45) |
| 20:19.16 | kpfleming | 500 is not 1/4 second, it was only 1/4 second because of the bug you fixed |
| 20:19.24 | kpfleming | so yes... 2000 is now waaaaay too long |
| 20:19.25 | jpeeler | right |
| 20:20.19 | codefreeze-lap | jpeeler: well, the average user shouldn't have to feel rushed to enter the sequence. I'll play around with it and try to come up with a practical, minimal number... 1000 may be sufficient; let me do a few experiments. |
| 20:20.23 | kpfleming | mnicholson: your comments earlier just made me find another pair of bugs in ast_frisolate()... but it is rarely used at the moment, so probably never happened |
| 20:20.42 | jpeeler | i noticed a big difference even with it set to 500 |
| 20:22.28 | codefreeze-lap | jpeeler: well, you younger guys might be ok with a .5 sec spacing requirement; but us old codgers could probably find something slightly longer more comfortable.... ;) |
| 20:23.23 | Corydon76-dig | proposes 1300 |
| 20:23.48 | jpeeler | 1337 |
| 20:24.01 | codefreeze-lap | jpeeler: lol |
| 20:24.09 | Corydon76-dig | jpeeler: hawt |
| 20:24.17 | codefreeze-lap | Corydon76-dig: why 1300? that's a pretty specific number! |
| 20:24.42 | Corydon76-dig | codefreeze-lap: It feels about right |
| 20:25.11 | codefreeze-lap | rolls up sleeves for a few minutes of "usability testing" |
| 20:25.19 | Qwell | double it - let's call it 2600 |
| 20:25.27 | Corydon76-dig | 2 seconds is too long |
| 20:25.39 | Qwell | Corydon76-dig: you missed it |
| 20:25.46 | Corydon76-dig | 1 second isn't long enough |
| 20:26.00 | kpfleming | does the timeout get short-circuited if we find a matching feature sequence that can't match anything longer? |
| 20:26.54 | codefreeze-lap | kpfleming: I think so. A match should yield immediate results |
| 20:27.05 | kpfleming | ok, then the timeout can be longer |
| 20:27.19 | kpfleming | if the timeout has to expire for the feature to trigger, then i wouldn't want it to be so long |
| 20:27.27 | jpeeler | yes, it is immediate |
| 20:27.39 | codefreeze-lap | It's only a complete timeout that gets confusing. Say, you enter a *, and just wait (where your patterns all start with *) |
| 20:27.43 | Corydon76-dig | kpfleming: but you don't want it too long, because if you fat-finger something, you want a reset quickly |
| 20:27.51 | kpfleming | right |
| 20:27.57 | codefreeze-lap | It will be x seconds before you hear the tone passed through. |
| 20:28.05 | kpfleming | i think 1 second is probably fine |
| 20:28.29 | jpeeler | agreed, not that i have any say though |
| 20:28.31 | Corydon76-dig | kpfleming: from my experience, 1 second isn't long enough for most people |
| 20:28.41 | codefreeze-lap | Tilghman might be right, tho-- 1300 might be nice. I'll test it out |
| 20:28.48 | kpfleming | 1 second to hit the second key of the sequence? that sounds really bizarre |
| 20:28.53 | Corydon76-dig | You have to train people to push buttons more quickly than they usually will |
| 20:29.03 | kpfleming | wow... those people are slow |
| 20:29.19 | Corydon76-dig | Welcome to the world of the reseller |
| 20:29.36 | kpfleming | this is an inter-digit timeout, right, not a timeout for the whole key sequence? |
| 20:29.50 | codefreeze-lap | yes |
| 20:29.56 | kpfleming | wow... those people are slow :-) |
| 20:30.07 | kpfleming | i think setting it longer than 1 second by default is too long |
| 20:30.21 | codefreeze-lap | kpfleming: as one of them, all I can say is: you have no idea :) |
| 20:30.21 | kpfleming | if a particular installation wants it longer, then fine |
| 20:31.08 | lmadsen | 1138 seems like a nice round number |
| 20:31.16 | Corydon76-dig | kpfleming: I agree, if the only possibilities were 1 second or 2 seconds, but since we have in-betweens, we can optimize for the common case |
| 20:31.34 | kpfleming | you are talking about making it longer than it already is, or has ever been |
| 20:31.45 | kpfleming | if that was the common case, we would have had constant complaints about it |
| 20:31.46 | Corydon76-dig | by default, yes |
| 20:32.12 | Corydon76-dig | It's not so fast that people can't be trained |
| 20:32.14 | kpfleming | i suspect making it that long will *generate* complaints |
| 20:32.36 | kpfleming | what? if the people need training, change it on *their* system |
| 20:32.42 | kpfleming | don't make everyone else suffer |
| 20:33.42 | Corydon76-dig | Heh, as a reseller, we typically never changed it, but just funneled all the complaints into training them to hit the buttons faster |
| 20:34.05 | kpfleming | but that was when it was 1/4 second or 1/2 second by default |
| 20:34.17 | kpfleming | it's already twice that, or more |
| 20:34.19 | ctooley | Playing with interdigit timeouts is something I have a lot of experience with as the amount time someone spends in our prepaid IVR is directly related to the amount of cost we have for the call. 1.25 to 1.5 seconds is best. |
| 20:34.35 | codefreeze-lap | kpfleming: please: I've been futzing with it set to a quarter sec for 2 years. Maybe 3/4ths of all my attempts failed. I found that easier than actually modding the file. Most will do so. |
| 20:34.41 | lmadsen | votes for 1250 |
| 20:34.55 | ctooley | Shorter cause a lot of failures, longer is confusing |
| 20:34.56 | kpfleming | codefreeze-lap: who suggested setting it back 250 msec? i sure didn't |
| 20:35.10 | kpfleming | my suggestion was to agree with jpeeler who suggested 1 second |
| 20:35.38 | ctooley | But, that's because most of our users are calling from payphones and trying to enter numbers on the back of a poorly printed card. |
| 20:35.43 | kpfleming | right |
| 20:35.51 | kpfleming | and also people calling from cell phones will dial more slowly as well |
| 20:36.09 | kpfleming | in this case, we aren't talking about long digit strings that the user can't memorize, they are short strings that should be memorized |
| 20:37.04 | *** join/#asterisk-dev shazaum (n=shazaum@unaffiliated/shazaum) |
| 20:37.53 | codefreeze-lap | But we are also talking about folks in the middle of a conversation, fairly distracted at times, some with the dialpad on the handset, too... |
| 20:38.41 | codefreeze-lap | Let me get a feel of the respective "prices to pay" at 1.0, 1.3, and 1.5 sec |
| 20:39.00 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@bzq-179-75-202.static.bezeqint.net) |
| 20:39.00 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 20:39.05 | kpfleming | have you been happy with it at 1 second like it has been recently? |
| 20:39.57 | jpeeler | (in trunk) |
| 20:40.10 | kpfleming | ahh |
| 20:40.14 | jpeeler | i think that's the only place it is |
| 20:40.15 | kpfleming | well, then that's different then |
| 20:40.23 | *** join/#asterisk-dev alerios (n=alerios@190.144.75.22) |
| 20:40.37 | kpfleming | now that we've consumed about $1K in developer time, just change it to 1 second everywhere and move on :-) |
| 20:41.55 | russellb | lol |
| 20:42.01 | russellb | +1 |
| 20:42.09 | Corydon76-dig | said his piece, then moved on |
| 20:44.16 | codefreeze-lap | OK, I'll commit that in the example config file |
| 21:18.03 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 21:18.03 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 21:45.45 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 21:58.00 | *** join/#asterisk-dev qdk (n=qdk@195.242.194.42) |
| 22:12.15 | *** part/#asterisk-dev alerios (n=alerios@190.144.75.22) |
| 22:30.28 | *** join/#asterisk-dev obnauticus (n=obnautic@about/windows/regular/obnauticus) |
| 22:33.57 | *** join/#asterisk-dev Pazzo (n=ugelt@sadsl-246059.rol.raiffeisen.net) |
| 22:40.15 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 22:40.15 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 22:47.15 | *** join/#asterisk-dev timeshell_atwork (n=chatzill@gw.lusi.on.ca) |
| 22:53.06 | *** part/#asterisk-dev Mog (n=mog@c-68-62-218-186.hsd1.al.comcast.net) |
| 22:54.39 | *** join/#asterisk-dev Assid (n=assid@unaffiliated/assid) |
| 22:54.41 | Assid | hi |
| 22:55.05 | Assid | would it be possible to get some help regarding asterisk+jabber module to speak to gtalk? |
| 22:55.41 | russellb | possibly in #asterisk :-) |
| 22:58.05 | *** join/#asterisk-dev djbelieny (n=djbelien@72-48-61-165.dyn.grandenetworks.net) |
| 23:01.48 | *** part/#asterisk-dev djbelieny (n=djbelien@72-48-61-165.dyn.grandenetworks.net) |
| 23:13.47 | kpfleming | mnicholson: in both cases of existing usage of ast_frisolate(), the frame being 'isolated' is on the stack, so is implicitly freed after the ast_frisolate() call |
| 23:14.41 | mnicholson | ahh ok |
| 23:16.23 | kpfleming | have added more comments to frame.h about what we talked about |
| 23:16.28 | kpfleming | hopefully nobody will use it improperly |
| 23:19.23 | *** join/#asterisk-dev obnauticus (n=obnautic@about/windows/regular/obnauticus) |
| 23:25.31 | *** join/#asterisk-dev russellb (n=russellb@asterisk/digium-open-source-team-lead/russellb) |
| 23:25.31 | *** mode/#asterisk-dev [+o russellb] by ChanServ |