| 00:13.50 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-20-153.hsd1.sc.comcast.net) |
| 00:13.50 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 00:19.00 | *** join/#asterisk-dev jeffspeff2 (i=jeff@c-98-240-113-135.hsd1.ky.comcast.net) |
| 00:21.44 | *** join/#asterisk-dev jeffspeff (i=jeff@c-98-240-113-135.hsd1.ky.comcast.net) |
| 00:50.28 | *** join/#asterisk-dev outtolunc (n=me@c-67-170-211-86.hsd1.ca.comcast.net) |
| 00:51.35 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 00:51.35 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 00:52.34 | *** join/#asterisk-dev jeffspeff (i=jeff@c-98-240-113-135.hsd1.ky.comcast.net) |
| 01:14.18 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-20-153.hsd1.sc.comcast.net) |
| 01:14.18 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 02:06.55 | *** join/#asterisk-dev korihor (n=korihor@190.78.32.60) |
| 02:07.31 | *** join/#asterisk-dev dwayne (i=dwayne@76.29.245.9) |
| 03:55.36 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 03:55.36 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 03:56.35 | *** join/#asterisk-dev denon (n=denon@tooth.decay.org) |
| 05:36.10 | *** join/#asterisk-dev davevg-btwtech (n=davevg-b@nj-67-76-177-147.sta.embarqhsd.net) |
| 05:53.28 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 05:53.28 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:05.43 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@local.xorcom.com) |
| 06:05.43 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 06:15.42 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-20-153.hsd1.sc.comcast.net) |
| 06:15.42 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 06:30.34 | oej | Morning |
| 06:30.51 | snuff-work | ello oej |
| 06:32.53 | DarKnesS_WolF | morning oej |
| 06:33.05 | DarKnesS_WolF | mmm oej where are u from to wake up arouund 2 am USA time ? |
| 06:33.17 | oej | Sweden :-) |
| 06:37.10 | tzafrir_laptop | http://en.wikipedia.org/wiki/Sweden,_Maine ? http://en.wikipedia.org/wiki/Sweden,_New_York ? http://en.wikipedia.org/wiki/Sweden_Township,_Pennsylvania ? :-) |
| 06:39.27 | *** join/#asterisk-dev obnauticus (n=obnautic@about/windows/regular/obnauticus) |
| 06:47.20 | tzafrir_laptop | Is libtonezone ABI-compatible in both dahdi and zaptel? API-compatible? |
| 06:51.18 | tzafrir_laptop | basically yes, if we assume DAHDI_MAX_CADENCE is the same as ZT_MAX_CADENSCE ... |
| 06:55.10 | DarKnesS_WolF | ojah ic :-) |
| 08:04.45 | mvanbaak | mornin all |
| 08:05.27 | snuff-work | hello mvanbaak.. hows the xml branch going? |
| 08:18.53 | DarKnesS_WolF | morning |
| 08:22.40 | mvanbaak | snuff-work: it's progressing |
| 08:22.51 | mvanbaak | snuff-work: I should finish the ast_strification of it |
| 08:22.55 | mvanbaak | and then we are ready I think |
| 08:27.32 | snuff-work | nice |
| 08:59.44 | *** join/#asterisk-dev luxxx77 (n=luxxx77@e176230221.adsl.alicedsl.de) |
| 09:02.40 | wedhorn | mvanbaak: ping |
| 09:04.16 | mvanbaak | pong |
| 09:05.10 | wedhorn | with your skinny phones, if you receive a call to the non-active line (multi line phone) does it answer it or give you a dialtone on the active line? |
| 09:05.23 | mvanbaak | I have no idea |
| 09:05.27 | mvanbaak | never tested that |
| 09:07.03 | wedhorn | I assume you're at work, can you check when you get home |
| 09:07.32 | wedhorn | and for that matter, do you agree that it should pick up the other line that is ringing? |
| 09:40.42 | *** join/#asterisk-dev maxhbp2005 (n=maxhbp20@122.169.14.158) |
| 09:40.46 | mvanbaak | only if you hit the answer softbutton |
| 09:40.54 | mvanbaak | it should not do that automagically |
| 09:41.03 | mvanbaak | and yes, I can test it after work |
| 09:41.06 | *** part/#asterisk-dev maxhbp2005 (n=maxhbp20@122.169.14.158) |
| 09:43.52 | wedhorn | mvanbaak: maybe we need an option, the old phones don't have an answer button (and there is no indication which line is active while the phone is onhook) |
| 09:44.23 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.141) |
| 09:46.17 | mvanbaak | ah |
| 09:46.26 | mvanbaak | how does callwaiting work on them ? |
| 09:48.32 | wedhorn | it doesn't (well not reliably) hence the reason I wrote the callwaiting=no patch ;) |
| 09:49.56 | wedhorn | but that's more a sub handling issue. I plan on fixing that up too and using the hold button (and line) to toggle through the call list |
| 09:54.40 | *** join/#asterisk-dev snuff-home (n=snuffy@60-240-117-7-nsw-pppoe.tpgi.com.au) |
| 10:44.37 | *** join/#asterisk-dev maxhbp2005 (n=maxhbp20@122.169.14.158) |
| 10:44.57 | maxhbp2005 | hi |
| 10:45.30 | maxhbp2005 | i want help for inbound blind transfer |
| 10:45.38 | maxhbp2005 | anybody there? |
| 10:48.32 | seanbright | maxhbp2005: #asterisk |
| 10:49.17 | maxhbp2005 | ok |
| 10:49.32 | *** part/#asterisk-dev maxhbp2005 (n=maxhbp20@122.169.14.158) |
| 11:32.08 | *** join/#asterisk-dev oej (n=olle@80.251.192.2) |
| 11:32.08 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:44.42 | mvanbaak | good afternoon oej |
| 11:47.33 | *** join/#asterisk-dev eliel (n=eliel@200.61.172.61) |
| 11:53.41 | *** join/#asterisk-dev ctooley (n=ctooley@209.33.108.195) |
| 11:53.41 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 12:05.46 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:09.17 | *** join/#asterisk-dev DagMoller (n=aguirre@unaffiliated/dagmoller) |
| 12:14.02 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:14.02 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 12:17.14 | *** join/#asterisk-dev russellb (n=russellb@asterisk/developer-and-stable-maintainer/drumkilla) |
| 12:17.14 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 12:42.42 | *** join/#asterisk-dev Rem| (n=remi@bg-fw2out.monmouth.com) |
| 13:00.52 | snuff-home | russ have question of smdi :) |
| 13:06.25 | *** join/#asterisk-dev korihor (n=korihor@200.7.99.2) |
| 13:06.50 | russellb | snuff-home: k, go ahead |
| 13:07.18 | snuff-home | it seems to use astobj as just a list.. |
| 13:07.31 | snuff-home | link_end.. link_start |
| 13:07.48 | russellb | I wouldn't worry about link order |
| 13:07.52 | russellb | the order in that container doesn't matter |
| 13:08.09 | russellb | it _does_ use the reference counting feature, though, because other modules may access those interfaces |
| 13:08.14 | snuff-home | ok just that it seems to be fifo operations.. mwi_push etc |
| 13:08.25 | russellb | oh, wait one second |
| 13:09.20 | russellb | Ok, now I see |
| 13:09.51 | russellb | It looks like the smdi interfaces should be in an astobj2 container, but the mwi queue and the md queue should probably just be regular lists |
| 13:10.12 | russellb | I don't see any benefit of using a ref counted object model for those |
| 13:10.39 | snuff-home | ok so md/mwi go from obj lists back to std list.. and interfaces goto ao2 :) |
| 13:10.56 | russellb | Yeah, I think so |
| 13:11.03 | russellb | i'm going to look for a few more minutes to be sure .. |
| 13:11.55 | snuff-home | its ok i have time to wait.. i remember someone commiting code that allowed reverse iteration to ao2 or was that my imagination? (might be someone branch) |
| 13:12.27 | russellb | gah ... there are a lot of API calls in smdi.h ... I wonder if they are actually used |
| 13:15.44 | snuff-home | they would be somewhere.. since it still compiles under dev mode with module enabled ;) |
| 13:17.02 | russellb | nah, you won't get warnings for that |
| 13:17.27 | *** join/#asterisk-dev w9sh (n=w9sh@adsl-068-209-117-205.sip.asm.bellsouth.net) |
| 13:17.43 | snuff-home | mm i did for traceframes_deprecated fn call |
| 13:17.56 | russellb | that's because it was a function that was declared as static |
| 13:17.57 | snuff-home | aka why i posted a fix on bugs |
| 13:18.01 | russellb | meaning, not a public API call |
| 13:18.05 | snuff-home | ah |
| 13:18.13 | russellb | the compiler has no way to know whether a public API call will be used or not |
| 13:18.16 | snuff-home | course since its called in 2 places |
| 13:18.18 | russellb | since that's something that can change at runtime |
| 13:20.27 | snuff-home | true.. |
| 13:24.08 | tzafrir_laptop | http://docs.tzafrir.org.il/dahdi-linux/ is finally up ... |
| 13:27.00 | russellb | looks good |
| 13:28.43 | tzafrir_laptop | BTW: it's trivial to add to anywhere under asterisk.org . Just stuff generated from zaptel/dahdi |
| 13:33.51 | *** part/#asterisk-dev dwayne (i=dwayne@76.29.245.9) |
| 13:41.37 | *** join/#asterisk-dev thx_man (n=thx_man@port-83-236-207-89.static.qsc.de) |
| 13:44.32 | thx_man | hi, i compiled ast 1.6 + libpri 1.6 + zaptel 1.4.11 + zaphfc. i see the card in astersik. but only in bri_net mode, bri_net_ptmp will not work. any idea? |
| 13:44.49 | Qwell | there is no libpri 1.6 |
| 13:45.26 | thx_man | http://www.digium.com/elqNow/elqRedir.htm?ref=http://downloads.digium.com/pub/libpri/releases/libpri-1.6.0-beta1.tar.gz |
| 13:45.32 | Qwell | also, asterisk 1.6 no longer supports zaptel - you should upgrade to dahdi and upgrade everything else |
| 13:45.40 | Qwell | blinks |
| 13:45.47 | Qwell | okay, don't use that |
| 13:45.53 | thx_man | crap ? |
| 13:46.02 | kpfleming | and libpri does not have bri_net_ptmp |
| 13:46.05 | kpfleming | only bri_net_ptp |
| 13:46.14 | kpfleming | and bri_cpe_ptp, bri_cpe_ptmp |
| 13:46.29 | Qwell | kpfleming: is there any reason we should keep that tarball up? |
| 13:46.35 | kpfleming | what tarball? |
| 13:46.40 | kpfleming | oh |
| 13:46.41 | kpfleming | no |
| 13:46.41 | Qwell | 1.6.0-beta1.. |
| 13:46.43 | kpfleming | it should go away |
| 13:47.45 | thx_man | :( damn |
| 13:48.14 | kpfleming | doesn't matter, all the stuff that was in there is in libpri-1.4.7 anyway |
| 13:49.11 | *** join/#asterisk-dev codefreeze-lap (n=murf@216.166.159.235) |
| 13:49.11 | *** mode/#asterisk-dev [+o codefreeze-lap] by ChanServ |
| 13:49.12 | thx_man | ok you told me zaptel will not work, if i compile dahdi, there will be no chance that my hfc card will work right? |
| 13:49.41 | Qwell | thx_man: there is a chance it won't build with dahdi yet |
| 13:50.56 | Qwell | and it isn't that zaptel won't work - the betas of 1.6.0 do work with zaptel, but if you upgrade Asterisk, you'll need to use dahdi |
| 13:50.57 | kpfleming | it probably wont |
| 13:52.23 | thx_man | is the only way misdn to make a internal isdn bus under ast 1.6? |
| 13:52.30 | *** join/#asterisk-dev dioedu (n=dioedu@201.7.117.114) |
| 13:52.44 | thx_man | if dahdi will not work in current state |
| 13:59.45 | thx_man | ok if zaptel will work under ast 1.6 beta, i don't understand why my asterisk will not start up with bri_net_ptmp. i patched zaptel with the 0.4.0bristuff patches so that the zaphfc driver compiled correctly. i forgot something right? |
| 14:00.36 | kpfleming | i have no idea, we don't know anything about those patches |
| 14:00.44 | kpfleming | you'll have to talk to whoever made the patche |
| 14:01.12 | *** join/#asterisk-dev sruffell (n=sruffell@adsl-074-185-078-025.sip.bhm.bellsouth.net) |
| 14:01.12 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:19.09 | codefreeze-lap | The Gunbarrel fire continues to advance. They are letting it burn, to get rid of dead timber and pine bark beetles. It makes for Orange sunsets.... http://www.kulr8.com/news/wyoming/26950234.html |
| 14:19.36 | codefreeze-lap | And a lot of ash and cinders on your car in the mornings |
| 14:20.33 | *** join/#asterisk-dev joshaidan (n=joshaida@S01060090f8009fa6.tb.shawcable.net) |
| 14:20.40 | codefreeze-lap | Hah, can't run the swamp cooler because the whole house smells of campfire |
| 14:23.45 | codefreeze-lap | Some nice pics: http://2bluedogs.wordpress.com/2008/08/04/gunbarrel-wildfire-photos-080208/ -- but a little old now |
| 14:30.14 | tzafrir_laptop | I'm looking at pri_dchannel() in 1.4:channels/chan_dahdi.c , |
| 14:31.15 | tzafrir_laptop | In the case of PRI_EVENT_RING , in the case where: if (pri->pvts[chanpos]->owner) { |
| 14:31.36 | tzafrir_laptop | there's a break without releasing the channel lock. Is that intentional? |
| 14:32.31 | kpfleming | it is unlikely that anyone knows the answer to that question without researching the history of the code |
| 14:35.43 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 14:46.36 | *** join/#asterisk-dev putnopvut (n=putnopvu@nat/digium/x-392c416cfb644f79) |
| 14:46.36 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:54.01 | seanbright | contemplates an AddHangupHook() application |
| 14:56.33 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.137) |
| 14:57.04 | seanbright | contemplates no longer |
| 14:58.08 | putnopvut | AddHangupHook? Isn't that the 'h' extension? |
| 14:58.26 | seanbright | AddHangupHook would be context agnostic |
| 14:59.17 | seanbright | meaning you attach a hook to a channel and no matter where it goes in the dialplan the hook will get called on hangup |
| 14:59.24 | seanbright | i know... it's pure genius |
| 14:59.26 | seanbright | heh |
| 14:59.31 | putnopvut | It truly is. |
| 14:59.35 | file | oh that sort of hook... |
| 15:00.12 | putnopvut | My knuckle has started bleeding. I have no idea why. |
| 15:00.21 | seanbright | mainly because for the life of me i can't get my h extension to actually get called :) |
| 15:00.33 | seanbright | necessity is the mother of invention |
| 15:00.54 | seanbright | putnopvut: stop dragging them on the ground |
| 15:00.55 | seanbright | zing |
| 15:01.03 | putnopvut | oh snap! |
| 15:03.07 | Juggie | i could think of worse things to say but i'm going to take the high road. |
| 15:03.18 | seanbright | Juggie: why start now? |
| 15:03.24 | seanbright | :) |
| 15:05.18 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 15:05.18 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 15:11.44 | seanbright | codefreeze-lap: can you have an h exten inside a macro in AEL? |
| 15:11.48 | *** part/#asterisk-dev wwalker (n=wwalker@pdpc/supporter/sustaining/wwalker) |
| 15:15.13 | Corydon76-dig | seanbright: you can have one, but it won't work |
| 15:15.18 | seanbright | super |
| 15:15.55 | Corydon76-dig | The h extension must be in the original context from where you called the first in the nested macros |
| 15:16.10 | seanbright | yeah |
| 15:16.23 | seanbright | for some reason (not asking for support, just complaining), that doesn't get called for me |
| 15:16.28 | seanbright | probably doing something stupid |
| 15:19.35 | Corydon76-dig | If you did a Goto out of a Macro, that's considered the new location |
| 15:20.01 | seanbright | hmmm |
| 15:20.25 | seanbright | maybe something is wonky with the generated dialplan |
| 15:20.37 | Corydon76-dig | because Goto causes the Macro to exit |
| 15:22.12 | seanbright | yeah, i don't Goto from the macro, and all the internal Gotos just use s or one of the s-based extens in the macro |
| 15:25.58 | *** join/#asterisk-dev ajohnson (n=ajohnson@63.147.46.186) |
| 15:26.39 | seanbright | going to set up a stripped down version on my dev box and see if i can figure it out |
| 15:29.32 | Corydon76-dig | strip down, woohoo |
| 15:29.47 | Corydon76-dig | pics pls |
| 15:31.21 | russellb | thinks that someone should write a common scheduler thread implementation ... |
| 15:31.58 | putnopvut | russellb: what do you mean by that? |
| 15:32.26 | putnopvut | You mean like a non-Asterisky sched.[hc]? |
| 15:32.31 | russellb | no ... |
| 15:32.38 | russellb | like, a common implementation of the scheduler loop |
| 15:32.38 | putnopvut | Or you mean that Asterisk needs a common scheduler implementation? |
| 15:32.43 | putnopvut | oh |
| 15:32.45 | putnopvut | hmm |
| 15:32.52 | russellb | with proper handling of timeouts and exits ... |
| 15:33.01 | russellb | instead of having it different in every module |
| 15:33.08 | russellb | with minor bugs like the one i just noticed in chan_iax2 |
| 15:33.15 | russellb | i'm just thinking out loud, i guess |
| 15:33.20 | putnopvut | mkay |
| 15:34.12 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 15:34.17 | russellb | putnopvut: similar to the taskprocessor stuff ... just putting some of the implementation details in a single place ... |
| 15:34.27 | putnopvut | Gotcha |
| 15:34.48 | putnopvut | I guess I need to look closer at how different modules handle the scheduler, since I really am only familiar with chan_sip's use. |
| 15:35.45 | russellb | chan_sip's use has race conditions :( |
| 15:38.37 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.8.157) |
| 15:39.37 | russellb | if you schedule something in chan_sip, you can expect it to take up to 1 second, even if you asked for quicker |
| 15:41.50 | jsmith | sighs |
| 15:42.17 | lmadsen | unsighs |
| 15:42.22 | lmadsen | jsmith: hi! |
| 15:42.26 | file | files |
| 15:43.18 | jsmith | Wasn't codefreeze-lap working on some updates to the SIP scheduler |
| 15:43.24 | jsmith | may be totally mistaken |
| 15:43.35 | russellb | he was poking at the implementation of the scheduler internally |
| 15:43.47 | russellb | the speed of adding/removing/running items ... |
| 15:43.55 | russellb | i'm talking about use of the API .. |
| 15:45.56 | jsmith | Ah, gotcha |
| 15:46.06 | jsmith | "If it's worth writing, it's worth writing again" |
| 15:53.39 | russellb | the chan_sip scheduler usage is worse than I thought ... it may completely not run it at all in cases that it is supposed to |
| 15:53.50 | *** join/#asterisk-dev mgroman (n=miles@adsl-68-252-62-180.dsl.wotnoh.ameritech.net) |
| 15:53.51 | russellb | whether it runs it or not is dependent upon a completely unrelated return value |
| 15:54.03 | russellb | sighs |
| 15:54.19 | mgroman | Hi, in the Asterisk API, where can I find pbx_findapp()? |
| 15:54.44 | russellb | include/asterisk/pbx.h |
| 15:54.47 | mgroman | thanks |
| 15:54.53 | russellb | grep is your friend ;) |
| 15:56.02 | jsmith | mgroman: Or at http://www.asterisk.org/doxygen/trunk/pbx_8c.html#ddb5ff156654fdebe7273da5a9a6c41c |
| 15:56.11 | russellb | ooh |
| 15:56.43 | mgroman | really, im just trying to find out why my box cant find an app. Just checking to see what exactly that function is looking at |
| 15:56.48 | mgroman | thanks all |
| 15:56.53 | *** join/#asterisk-dev ctooley (n=ctooley@209.33.108.195) |
| 15:56.53 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 15:57.33 | russellb | I wonder where I should document these scheduler findings ... |
| 15:57.35 | russellb | just trunk? |
| 15:57.37 | file | it looks through a linked list trying to find the application based on name... if it can not find it then it was not registered |
| 15:58.05 | russellb | it's the same list that you see when you do "core show applications" |
| 15:58.47 | mgroman | o ok, well im gonna look into why it isnt getting registered...sorry for asking a question like this in -dev |
| 15:59.32 | *** join/#asterisk-dev smurf (n=smurf@debian/developer/smurf) |
| 16:03.23 | seanbright | did those CDR changes in 1.4 ever get reverted? |
| 16:03.33 | seanbright | i guess i could look |
| 16:03.34 | file | for the 'h' extension? yes |
| 16:03.39 | seanbright | oh good |
| 16:03.46 | codefreeze-lap | seanbright: yep |
| 16:04.06 | *** part/#asterisk-dev mgroman (n=miles@adsl-68-252-62-180.dsl.wotnoh.ameritech.net) |
| 16:05.07 | codefreeze-lap | seanbright: I have some patches that should bring that code closer to current behavior, I'd love to have folks test the patches, and let me know what's still to do.... see bug 13251 |
| 16:10.31 | *** join/#asterisk-dev Laureano (n=Laureano@190.245.108.2) |
| 16:13.31 | seanbright | Corydon76-dig: the 'h' exten in MACRO_CONTEXT is called? |
| 16:18.02 | Corydon76-dig | seanbright: not necessarily |
| 16:18.28 | Corydon76-dig | that's the context, I believe, from which the macro was called, yes, but it could similarly be another macro |
| 16:18.42 | Corydon76-dig | You have to find the base location |
| 16:18.56 | seanbright | right, but i don't call macros from my macro |
| 16:19.02 | seanbright | so it would be the same in that case |
| 16:19.25 | Corydon76-dig | Okay, in your case, sure |
| 16:29.36 | mvanbaak | russellb: congrats on commit 140000 |
| 16:29.59 | russellb | for serious? |
| 16:30.00 | russellb | <3 |
| 16:30.03 | russellb | commit asterisk 140000 |
| 16:30.12 | mvanbaak | or am I misreading it ? |
| 16:30.19 | MuffinMan | [140000] Committed by root on 2008-08-25T23:26:03.889764Z: Merged revisions 139981 via svnmerge from |
| 16:30.19 | MuffinMan | ..file:///srv/subversion/repos/asterisk/trunk |
| 16:30.19 | MuffinMan | .. |
| 16:30.19 | MuffinMan | .......... |
| 16:30.20 | MuffinMan | ..r139981 | tilghman | 2008-08-25 18:13:32 -0500 (Mon, 25 Aug 2008) | 7 lines |
| 16:30.22 | MuffinMan | .. |
| 16:30.23 | mvanbaak | wait, ... |
| 16:30.25 | MuffinMan | ..Optional light colored background, for those who use black on white terminals. |
| 16:30.25 | mvanbaak | lol |
| 16:30.27 | MuffinMan | ..(closes issue #13306) |
| 16:30.28 | russellb | eep |
| 16:30.29 | mvanbaak | damn |
| 16:30.30 | MuffinMan | .. Reported by: Corydon76 |
| 16:30.32 | MuffinMan | .. Patches: |
| 16:30.35 | MuffinMan | .. 20080814__bug13306__3.diff.txt uploaded by Corydon76 (license 14) |
| 16:30.37 | *** mode/#asterisk-dev [+b %MuffinMan!*@*] by russellb |
| 16:30.44 | mvanbaak | I hate non-unicode terminals |
| 16:31.08 | mvanbaak | my screen was garbled because of unicode characters |
| 16:31.16 | mvanbaak | it missed one digit |
| 16:31.31 | mvanbaak | 14060 |
| 16:31.40 | mvanbaak | 140060 |
| 16:31.44 | mvanbaak | that |
| 16:31.48 | russellb | oic |
| 16:31.48 | Corydon76-dig | mvanbaak: you like the color change? |
| 16:31.56 | mvanbaak | Corydon76-dig: yes sur |
| 16:32.11 | mvanbaak | stupid OpenBSD does not support unicode yet |
| 16:32.20 | *** mode/#asterisk-dev [-b %MuffinMan!*@*] by russellb |
| 16:32.53 | Corydon76-dig | I think omitting the background color was probably a good way to go, as this change did |
| 16:33.28 | seanbright | "stupid OpenBSD?" |
| 16:33.38 | seanbright | who are you and what have you done with mvanbaak?! |
| 16:33.45 | mvanbaak | Corydon76-dig: it sure is |
| 16:34.54 | codefreeze-lap | Along that line, making the CLI front end for asterisk unicode-friendly would also be a nice thing! |
| 16:35.49 | tzafrir_laptop | replacing readline would probably be a good start |
| 16:36.01 | tzafrir_laptop | err... editline, that is |
| 16:36.24 | tzafrir_laptop | there's some work to make unicode-aware versions of libedit |
| 16:42.35 | seanbright | Corydon76-dig: pbx.c:2542 __ast_pbx_run: Searching in context: macro-test-handle-outbound |
| 16:42.55 | seanbright | (i added an ast_log right before the h exten is called) |
| 16:46.23 | seanbright | i think the issue is that AEL2 is generating dialplan and not macros |
| 16:46.34 | seanbright | ael macros aren't "macros" in the asterisk sense, correct? |
| 16:47.05 | codefreeze-lap | seanbright: not after 1.4 |
| 16:47.13 | seanbright | i'm using 1.4 |
| 16:47.54 | codefreeze-lap | have you looked at the generated code? (dialplan show) |
| 16:48.03 | seanbright | yes |
| 16:48.11 | codefreeze-lap | what are you seeing? |
| 16:49.04 | seanbright | i'm seeing that my h extens are not getting called... |
| 16:49.11 | seanbright | because it's looking the macro context |
| 16:49.12 | seanbright | and not in the parent |
| 16:49.24 | seanbright | looking *in* the macro context |
| 16:50.37 | codefreeze-lap | seanbright: sounds like a bug? |
| 16:50.47 | seanbright | yeah? |
| 16:51.01 | seanbright | i'm not sure... |
| 16:51.04 | codefreeze-lap | based on the above conversation, I'd have to guess. |
| 16:51.18 | seanbright | well let me create a minimal test case... hold |
| 16:51.18 | *** join/#asterisk-dev jtodd (n=jtodd@blob.fox-den.com) |
| 16:51.18 | *** mode/#asterisk-dev [+o jtodd] by ChanServ |
| 16:52.51 | mvanbaak | seanbright: you are running 1.4 ? that's ancient ;) |
| 16:52.58 | seanbright | in production, yes. |
| 16:53.07 | mvanbaak | :) I know |
| 16:54.23 | *** join/#asterisk-dev jameswf-home (n=james@cl-24.phx-01.us.sixxs.net) |
| 16:56.24 | mvanbaak | I do that as well |
| 17:01.21 | seanbright | codefreeze-lap: http://pastebin.ca/1185427 |
| 17:03.33 | codefreeze-lap | seanbright: put an h exten inside the macro, then, and see if that run is run |
| 17:03.49 | codefreeze-lap | uh /run is run/ one is run/ |
| 17:03.50 | seanbright | codefreeze-lap: how do i do that with AEL? just h => { foo } |
| 17:03.51 | seanbright | ? |
| 17:04.08 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 17:04.47 | codefreeze-lap | no, in a macro, you would say catch h { .... code.... } |
| 17:04.54 | seanbright | ohhh |
| 17:05.30 | seanbright | with associated try {} i assume |
| 17:06.18 | codefreeze-lap | seanbright: uhhhhhh, ..... no. sorry. |
| 17:06.22 | seanbright | oh |
| 17:06.23 | seanbright | heh |
| 17:06.53 | codefreeze-lap | this morning, **you** are the trying one, I think.... :) |
| 17:07.05 | seanbright | ouch |
| 17:07.26 | seanbright | that worked |
| 17:08.06 | seanbright | so Corydon76-dig gave me bad info (probably because he thought i was talking about > 1.4) |
| 17:09.05 | seanbright | codefreeze-lap: danke |
| 17:10.18 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 17:10.18 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 17:10.24 | mvanbaak | wb kpfleming |
| 17:10.34 | kpfleming | thanks |
| 17:11.55 | codefreeze-lap | seanbright: uh..... or, the fact that it's executing the 'h' exten in the macro is a bug.... which would take some research... |
| 17:12.48 | Corydon76-dig | seanbright: it honestly should not be looking for the "h" exten in a macro. Really. |
| 17:17.00 | seanbright | ah |
| 17:17.09 | seanbright | well then it is a bug |
| 17:17.14 | seanbright | but it's working for me now |
| 17:17.17 | seanbright | so i'm happy |
| 17:17.18 | seanbright | :) |
| 17:17.31 | Corydon76-dig | B-I N-G-O |
| 17:17.44 | Corydon76-dig | was his name-o |
| 17:18.49 | *** join/#asterisk-dev jameswf-home (n=james@cl-24.phx-01.us.sixxs.net) |
| 17:20.33 | *** join/#asterisk-dev putnopvut (n=putnopvu@nat/digium/x-88773e9828271b25) |
| 17:20.33 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 17:32.49 | *** join/#asterisk-dev jameswf-home (n=james@cl-24.phx-01.us.sixxs.net) |
| 17:47.21 | *** join/#asterisk-dev jameswf-home (n=james@cl-24.phx-01.us.sixxs.net) |
| 17:57.19 | russellb | wtf @ this menuselect-tree -- http://pastebin.ca/1185488 |
| 17:57.37 | russellb | this keeps happening to me ... |
| 17:58.09 | russellb | blames Qwell |
| 17:58.18 | Qwell | O.o |
| 17:58.41 | Qwell | oh |
| 17:58.47 | Qwell | stupid !gawk |
| 17:58.56 | *** join/#asterisk-dev jameswf-home (n=james@cl-24.phx-01.us.sixxs.net) |
| 17:59.16 | Qwell | russellb: is it actually breaking things, or just extra verbose? |
| 17:59.17 | russellb | and when it happens, it is different amounts of the shell output that make it in there |
| 17:59.21 | russellb | it's breaking things |
| 17:59.41 | russellb | mxml vomits |
| 18:00.02 | Qwell | there was an awk change in build_tools/get_makeopts, that was supposed to fix nawk |
| 18:00.52 | russellb | this is mawk apparently |
| 18:00.53 | russellb | not nawk |
| 18:01.17 | Qwell | it works on gawk |
| 18:01.22 | Qwell | what's awk --version say? |
| 18:01.36 | russellb | awk: not an option: --version |
| 18:01.57 | Qwell | yeah, mawk |
| 18:02.04 | Corydon76-dig | We need a version called squawk |
| 18:02.37 | Qwell | russellb: the change I'm thinking of was 139909 of build_tools/get_makeopts - does reverting that help? |
| 18:02.53 | Qwell | if so, we should figure out a different way to fix nawk |
| 18:02.58 | russellb | I think it was happening before that ... |
| 18:03.02 | Qwell | huh |
| 18:03.04 | russellb | but let me check |
| 18:04.56 | *** join/#asterisk-dev joetester2 (n=chatzill@216.191.34.13) |
| 18:05.19 | russellb | of course now i can't make it happen .. |
| 18:05.20 | russellb | sighs |
| 18:05.33 | Qwell | heh, 139909 may have actually fixed it - have you done a dist-clean since? |
| 18:05.41 | Qwell | (I'm testing that with mawk now) |
| 18:05.52 | russellb | why would i need to distclean |
| 18:06.32 | Qwell | to remove the .makeopts files |
| 18:06.34 | seanbright | didn't mean to break it more |
| 18:06.38 | kpfleming | so here's a thought: if i want to match 100 consecutive numbers, say 8897600 through 8897699, EXCEPT 8897655, how would i go about doing that the most efficient way possible? |
| 18:06.57 | Qwell | kpfleming: sh? |
| 18:07.00 | seanbright | seq? |
| 18:07.26 | kpfleming | no, in an extension pattern in extensions.conf |
| 18:07.38 | seanbright | yikes |
| 18:07.46 | Qwell | match 8897655 and goto i? |
| 18:07.53 | kpfleming | i have an idea for a new feature, but want to make sure there isn't a way |
| 18:07.53 | russellb | yeah ... |
| 18:07.54 | seanbright | yeah... |
| 18:07.56 | Corydon76-dig | kpfleming: pattern match on the general case, then a specific case for that number |
| 18:07.58 | kpfleming | no, i don't want to match that number |
| 18:08.15 | kpfleming | no, i don't want ANY match for that number |
| 18:08.17 | kpfleming | 404 NOT FOUND |
| 18:08.24 | Corydon76-dig | kpfleming: then put the Incomplete app for that extension |
| 18:08.32 | kpfleming | too late |
| 18:08.45 | kpfleming | the incoming channel driver will already have accepted the call |
| 18:08.56 | kpfleming | and the real match for that number might be in another context in a later include => |
| 18:09.09 | Corydon76-dig | Hmmm |
| 18:09.14 | Corydon76-dig | Guess not, then |
| 18:09.26 | Qwell | russellb: I can't reproduce with mawk :( |
| 18:09.37 | eliel | jsmith: This is my idea about appdocsxml, store the description, arguments etc, to be printed with *emphasised text*, <literal text> , etc, and have a colorization function to print this text with some colors |
| 18:10.04 | Corydon76-dig | kpfleming: you can do that with 3 pattern matches, I think |
| 18:10.08 | kpfleming | so.. how about noexten=>, which takes the same patterns but no application, and the same sorting rules |
| 18:10.13 | russellb | Qwell: I figured it out. It is trunk specific, and is because i have PRINT_DIR set |
| 18:10.18 | kpfleming | and if the match hits, then it means 'move on, search elsewhere' |
| 18:10.19 | Qwell | ahh |
| 18:10.55 | kpfleming | Corydon76-dig: you understand my point...the complexity of building patterns to avoid one (or two, or three) numbers gets high really fast |
| 18:11.04 | Corydon76-dig | kpfleming: meaning, no match in this context? |
| 18:11.08 | kpfleming | yep |
| 18:11.16 | kpfleming | even if there might be another match that would apply, it does not apply |
| 18:11.35 | Corydon76-dig | What about one for 'no match anywhere, stop searching'? |
| 18:11.40 | seanbright | support nightmare |
| 18:11.42 | seanbright | heh |
| 18:11.52 | Corydon76-dig | Essentially a blacklist for a specific pattern |
| 18:11.52 | kpfleming | sure, that might be useful too |
| 18:11.58 | eliel | jsmith: The problem with this schema is that if the document already has a *, <, >, etc we must find a way to not think this is a open and close char noting a literal, emphasis, etc... |
| 18:12.30 | seanbright | dynexten => path_to_something_that_returns_list_of_extensions.sh |
| 18:12.31 | seanbright | bam |
| 18:12.58 | jsmith | eliel: Can we just do an XSL Transform on the XML to generate the correct plain text (with or without colors)? |
| 18:13.01 | Corydon76-dig | So blacklist matches basically should match between exact matches and pattern matches? |
| 18:13.17 | Corydon76-dig | (in terms of ordering) |
| 18:13.18 | jsmith | eliel: I don't know the libxml stuff, but we should have to worry about those details |
| 18:13.19 | kpfleming | they would match in the same places as any other match constructed the same way |
| 18:13.25 | kpfleming | if they are exact, then exact |
| 18:13.34 | kpfleming | if they are patterns, then only ahead of less-specific patterns |
| 18:13.50 | kpfleming | no difference in sort order, just a difference in result |
| 18:13.52 | eliel | jsmith: I don't know.. thats a good idea, I will check it out... |
| 18:13.53 | Corydon76-dig | Tricky |
| 18:14.07 | Corydon76-dig | Tricky to debug, I mean |
| 18:14.08 | kpfleming | just a 'flag' on the extension itself telling the pbx what to do when the match hits |
| 18:14.11 | kpfleming | yeah, could be |
| 18:14.21 | jsmith | waves his hand in front of his face, and says "This is not the exten you are looking for" |
| 18:14.21 | kpfleming | not for the faint of heart, but if you need it, really really useful |
| 18:14.53 | Corydon76-dig | "exclude" and "blacklist" would be the keywords I would go for |
| 18:15.29 | kpfleming | well, exclude would seem orthogonal to include, but that's not the behavior. may have to use a different word |
| 18:15.39 | Corydon76-dig | Ah, true |
| 18:15.54 | jsmith | likes "noexten" |
| 18:16.16 | Corydon76-dig | or "-exten" |
| 18:16.22 | seanbright | nomatch |
| 18:16.30 | Corydon76-dig | nomatch is good |
| 18:16.32 | Qwell | exten !=> |
| 18:16.39 | Qwell | (I'm kidding) |
| 18:16.47 | seanbright | !Qwell |
| 18:17.17 | kpfleming | no, not nomatch, because it does match the pattern |
| 18:17.18 | jsmith | exten <= |
| 18:17.33 | jsmith | Change the direction of the arrow! |
| 18:17.36 | seanbright | heh |
| 18:17.38 | kpfleming | it's just not an extension |
| 18:17.52 | jsmith | Well, an extension isn't just an extension either |
| 18:17.52 | mvanbaak | libxslt |
| 18:17.54 | seanbright | except => |
| 18:17.54 | seanbright | ? |
| 18:17.56 | kpfleming | Qwell: that's not actually that bad |
| 18:18.03 | kpfleming | seanbright: oooh |
| 18:18.06 | mvanbaak | it's a lib using libxml2 to do xslt stuff |
| 18:18.19 | kpfleming | brb |
| 18:18.25 | Corydon76-dig | netxe => |
| 18:18.25 | mvanbaak | cur = xsltParseStylesheetFile( |
| 18:18.32 | mvanbaak | doc = xmlParseFile( |
| 18:18.40 | mvanbaak | res = xsltApplyStylesheet(cur, doc) |
| 18:18.55 | seanbright | (o)(o) _-~-_-=> |
| 18:18.59 | seanbright | that one ^^ |
| 18:20.31 | mvanbaak | that was for eliel and jsmith |
| 18:22.09 | eliel | mvanbaak: jsmith: the problem with this is that we need to decide at runtime if the terminal supports colors... we can't apply this transformation before parsing the document. |
| 18:22.18 | seanbright | exten => 88976[0-4]0,1,... |
| 18:22.18 | seanbright | exten => 889765[012346789],1,... |
| 18:22.18 | seanbright | exten => 88976[6-9]0,1,... |
| 18:22.26 | mvanbaak | there's more trouble with it eliel |
| 18:22.27 | seanbright | there. only 3 lines! |
| 18:22.42 | seanbright | except those 0s should be Xs |
| 18:22.53 | mvanbaak | because if we are going to do this, we loose the ability to do other stuff then displaying documentation |
| 18:22.56 | seanbright | and there should be underscores... |
| 18:22.58 | seanbright | oh well |
| 18:23.45 | eliel | mvanbaak: I have implemented a way to colorize the text and I think it is working fine, the problem is when the text has the chars involved in a literal, emphasis, etc.. like * < > ' '. |
| 18:24.48 | eliel | mvanbaak: If we agree that no literal, emphasis, etc, could be longer than a line (if there is a break) and I don't find the end until a \n then that is not a starting symbol. |
| 18:24.49 | mvanbaak | yeah, that will mess it up |
| 18:25.47 | mvanbaak | eliel: wont work, because you can have: this is 'supported' but not really |
| 18:25.51 | *** join/#asterisk-dev jameswf-home (n=james@cl-24.phx-01.us.sixxs.net) |
| 18:26.00 | mvanbaak | something like that. those characters can be used in normal lines as well |
| 18:26.21 | *** join/#asterisk-dev JimVanM (n=jimvanm@bas1-toronto63-1088810630.dsl.bell.ca) |
| 18:26.28 | eliel | supported will be colorized |
| 18:26.34 | Corydon76-dig | Afternoon, Jim |
| 18:27.00 | eliel | the problem is like "Caller*ID something more" |
| 18:27.31 | mvanbaak | yeah |
| 18:27.56 | mvanbaak | dont know if we can fix it once the xml tags are converted to normal characters |
| 18:28.01 | eliel | mvanbaak: or, i can leave the tags inside the base string, and let colorize put the special chars or the colors if a term color is supported. |
| 18:28.06 | jsmith | Don't let JimVanM know we're working on documentation stuff... he might want to get involved |
| 18:28.15 | mvanbaak | what about this: Caller*ID can be *hard* to read |
| 18:28.15 | jsmith | JimVanM: Oh, hey there! :-p |
| 18:28.23 | JimVanM | no chance, I'm still scarred |
| 18:28.39 | eliel | mvanbaak: *uck |
| 18:28.55 | mvanbaak | yup |
| 18:28.57 | Corydon76-dig | JimVanM: we going to meet for the first time at Astricon? |
| 18:29.12 | JimVanM | Corydon76-dig: I'll be there |
| 18:29.15 | eliel | mvanbaak: you are right... I will leave the tags in the base string and we will need to use the colorization function to print it... |
| 18:29.17 | mvanbaak | eliel: the problem would be solved if you only allow 1 single word between the special tags |
| 18:29.25 | kpfleming | seanbright: yes, only 3 lines... until you add one more 'wild' number that shouldn't match |
| 18:29.28 | kpfleming | and then another one |
| 18:29.31 | Corydon76-dig | JimVanM: sweet, I'll have to bring my books for your autograph |
| 18:29.31 | mvanbaak | but you cant ask that from the documenting ppl |
| 18:29.34 | kpfleming | and it gets really ugly |
| 18:29.47 | eliel | mvanbaak: yeaph |
| 18:29.51 | mvanbaak | kpfleming: I think it's a very nice new feature |
| 18:30.08 | kpfleming | blushes |
| 18:30.15 | JimVanM | Corydon76-dig: sure thing |
| 18:30.28 | mvanbaak | kpfleming: I have that kind of stuff from time to time, and most of the time I simply revert to #include patterns.py |
| 18:30.57 | mvanbaak | eliel: I think that will be the best way to do it (leaving the tags) |
| 18:31.29 | eliel | mvanbaak: ok |
| 18:31.45 | mvanbaak | eliel: since you already have to use a function to inspect the output, and that function has to know about supporting colors. so you can simply add an 'else replace with some funky asci char' |
| 18:32.39 | JimVanM | Corydon76-dig: you can clue-by-four me on this func_odbc stuff (which I am loving, but is costing me hair) |
| 18:32.47 | eliel | mvanbaak: yeaph, the only problem is that the function that knows if colors are supported is term_color, I will need to added another function in term.c to implement this in a nice way. |
| 18:33.08 | Corydon76-dig | JimVanM: I've moved on to adaptive stuff... ;-) |
| 18:33.36 | JimVanM | Corydon76-dig: adaptive? |
| 18:33.43 | Corydon76-dig | JimVanM: won't it be fun if your Asterisk machine decides you need more fields in your database and automatically adds them? |
| 18:34.13 | mvanbaak | depends |
| 18:34.15 | Corydon76-dig | with the right type and data length? |
| 18:34.19 | JimVanM | Corydon76-dig: LOL. define "fun" |
| 18:34.24 | mvanbaak | not on this database we had to deal with today |
| 18:34.50 | mvanbaak | customer called that a backuprun took longer then the timeframe between backups |
| 18:35.04 | mvanbaak | we found out the database was roughly 450GB |
| 18:35.05 | JimVanM | don't get me wrong, I'm all for a bit of masochism and all (else why would I be in this industry), but I'm enough of a newb that I |
| 18:35.13 | Corydon76-dig | JimVanM: or if your realtime database lacks a critical field, and instead of failing all queries, Asterisk just drops that column from the query? |
| 18:35.14 | JimVanM | m just happy to get the thing working, somedays |
| 18:35.29 | JimVanM | Corydon76-dig: yeah, I could see that being useful |
| 18:35.47 | mvanbaak | you dont want 'ALTER TABLE foo_that_is_450G ADD COLUMN calleridname CHARACTER VARYING(255)' |
| 18:35.52 | Corydon76-dig | JimVanM: essentially it frees us (the developers) by allowing us to add more fields as needed |
| 18:36.14 | *** join/#asterisk-dev jameswf-home (n=james@cl-24.phx-01.us.sixxs.net) |
| 18:36.22 | mvanbaak | eliel: yeah :( |
| 18:36.34 | Corydon76-dig | mvanbaak: the default configuration is simply to warn you... as a sysadmin, you decide if you want Asterisk adding or changing field lengths |
| 18:37.12 | mvanbaak | Corydon76-dig: I know :) was just referring to the 'fun' and 'automatically adds them' in the same line ;) |
| 18:37.56 | Corydon76-dig | JimVanM: the other adaptive part is in CDRs... add a field to the CDR table, add it to your dialplan, it's automatically populated... |
| 18:38.08 | Corydon76-dig | JimVanM: completely arbitrary fields for your CDRs |
| 18:38.23 | Corydon76-dig | JimVanM: and the option to rename standard CDR field names |
| 18:38.31 | mvanbaak | now THAT is an awesome feature |
| 18:38.32 | JimVanM | Corydon76-dig: I could see that being a useful kind of flexibility |
| 18:38.37 | mvanbaak | specially the filter => stuff |
| 18:38.53 | mvanbaak | JimVanM: Corydon76-dig really made it great by introducing a 'filter' option |
| 18:39.16 | mvanbaak | so you do: Set(CDR(foo)=log_this_in_db_a) |
| 18:39.34 | mvanbaak | and the cdr will only go the the DSN 'log_this_in_db_a' |
| 18:39.40 | mvanbaak | and _not_ to all the others |
| 18:39.53 | mvanbaak | that way you can log to a specific database based on a CDR field |
| 18:39.58 | Corydon76-dig | mvanbaak: not exactly how that works, though |
| 18:40.12 | Corydon76-dig | Your filter has to fail to match on the others |
| 18:40.14 | mvanbaak | erm, no sorry |
| 18:40.32 | mvanbaak | I have it running in production |
| 18:40.34 | mvanbaak | it's great |
| 18:41.24 | Corydon76-dig | But yes, you could have 13 different tables, and filter what goes into each, based upon CDR(accountcode), for example |
| 18:42.24 | Corydon76-dig | filter needs some work to make it more useful. It's a rather crude tool right now |
| 18:42.31 | mvanbaak | Corydon76-dig: was it you who introduced realtime for followme ? |
| 18:42.43 | Corydon76-dig | Yes |
| 18:42.50 | mvanbaak | ah |
| 18:42.57 | mvanbaak | this time I dont have to blame file ;) |
| 18:43.04 | mvanbaak | you broke compiling asterisk on OpenBSD |
| 18:43.08 | Corydon76-dig | Someone mentioned it on the -dev list, so I just coded it |
| 18:43.20 | Corydon76-dig | woot, that's a plus |
| 18:43.22 | mvanbaak | app_followme.c:892: warning: missing sentinel in function call |
| 18:43.37 | lmadsen | is that a bug or a feature? |
| 18:43.39 | lmadsen | :) |
| 18:43.41 | mvanbaak | if it's in trunk only, you can use the constant SENTINEL |
| 18:43.47 | mvanbaak | I introduced that some time ago |
| 18:44.08 | mvanbaak | want me to fix it ? |
| 18:44.30 | Corydon76-dig | but there is a sentinel there |
| 18:45.10 | mvanbaak | there is, but it's not of type (char *) |
| 18:45.25 | Corydon76-dig | Oh, foo on OpenBSD |
| 18:45.35 | kpfleming | no, the sentinel is supposed to be char * |
| 18:45.37 | mvanbaak | I fixed it locally |
| 18:45.43 | mvanbaak | should I commit it ? |
| 18:46.11 | Corydon76-dig | Sure |
| 18:46.11 | russellb | yeah, that's fine |
| 18:46.18 | lmadsen | JimVanM: I'm watching you... behave! |
| 18:47.14 | mvanbaak | thanks |
| 18:47.34 | mvanbaak | blegh |
| 18:47.57 | Corydon76-dig | mvanbaak: something wrong? |
| 18:48.07 | mvanbaak | 'your file apps/app_followme.c is probably out-of-date' |
| 18:48.18 | mvanbaak | ;) |
| 18:48.39 | mvanbaak | needs a faster connection to origsvn.digium.com |
| 18:48.56 | mvanbaak | I was wondering why it took so long to start sending data |
| 18:48.58 | JimVanM | lmadsen: be what? |
| 18:49.01 | mvanbaak | now I know you locked it ! |
| 18:49.58 | Corydon76-dig | giggles |
| 18:50.28 | mvanbaak | gheh. anywayz, thanks for fixing |
| 19:01.21 | Corydon76-dig | jsmith: what's the name of the new guy in your class, again? |
| 19:03.08 | jsmith | Corydon76-dig: David |
| 19:03.22 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 19:08.38 | seanbright | if anyone is an emacs user, i find myself using this a lot: http://pastebin.ca/1185561 |
| 19:09.18 | russellb | you mean, emacs is for noobs? |
| 19:09.19 | russellb | yes, i agree |
| 19:09.38 | *** mode/#asterisk-dev [-o seanbright] by seanbright |
| 19:09.48 | seanbright | this way i won't be tempted. |
| 19:11.08 | *** kick/#asterisk-dev [russellb!n=file@asterisk/developer-and-muffin-lover/file] by file (file) |
| 19:11.18 | seanbright | oh thank goodness. |
| 19:11.19 | seanbright | heh |
| 19:13.49 | *** part/#asterisk-dev seanbright (n=sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 19:13.52 | *** join/#asterisk-dev seanbright (n=sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 19:13.52 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 19:14.09 | *** join/#asterisk-dev russellb (n=russellb@asterisk/developer-and-stable-maintainer/drumkilla) |
| 19:14.09 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 19:14.29 | seanbright | wb russellb! |
| 19:14.41 | russellb | thx! |
| 19:14.46 | mvanbaak | wtf is that ? |
| 19:14.59 | seanbright | wtf is what? |
| 19:15.43 | mvanbaak | that shellfoo ? |
| 19:15.52 | mvanbaak | remove backup files or something ? |
| 19:15.59 | seanbright | removes emacs scratch files and auto recover files |
| 19:15.59 | Corydon76-dig | Pretty much, yes |
| 19:16.00 | seanbright | yes |
| 19:16.12 | Corydon76-dig | 'joe' leaves those behind, too |
| 19:16.46 | mvanbaak | and there's no 'set nobackups' option ? |
| 19:17.00 | seanbright | there might be |
| 19:17.07 | seanbright | but i don't want to stop it from backing up |
| 19:17.17 | seanbright | just want to be able to easily clean my working directory when i am done |
| 19:18.28 | Corydon76-dig | emacs compilation is its own brand of gross, though... |
| 19:19.04 | Corydon76-dig | seanbright: you know what the process is for emacs compilation, right? |
| 19:19.19 | Qwell | emerge emacs |
| 19:19.20 | mvanbaak | ah, so it's basically the same as the vim .swp files |
| 19:19.24 | seanbright | compiling within emacs or compiling emacs itself? |
| 19:19.31 | Corydon76-dig | emacs itself |
| 19:19.34 | seanbright | no |
| 19:19.38 | mvanbaak | but those get removed when you :quit vim |
| 19:19.38 | seanbright | i've never had to do it |
| 19:20.16 | Corydon76-dig | The core is a very simple Lisp interpreter. The entire compilation process is loading up Lisp files into memory to make a more complex Lisp interpreter |
| 19:20.30 | seanbright | nice |
| 19:20.36 | Corydon76-dig | and then, when it's done loading up all the files, a core snapshot is taken |
| 19:20.36 | seanbright | like gcc compiling itself |
| 19:20.46 | Corydon76-dig | i.e. a core dump |
| 19:20.54 | seanbright | heh |
| 19:21.15 | Corydon76-dig | When you run emacs, you're loading a core dump back into memory and re-executing it |
| 19:21.17 | mvanbaak | lol |
| 19:21.22 | seanbright | that's pretty awesome |
| 19:22.26 | Corydon76-dig | Well, it works... I don't know that I would classify it as awesome, though |
| 19:23.04 | tzafrir_laptop | mvanbaak, ah, but that's where the problem lies. You never quit using vim :-) |
| 19:23.38 | tzafrir_laptop | wanders off home wisteling |
| 19:24.02 | Corydon76-dig | tzafrir_laptop: for future reference, "whistling" |
| 19:30.14 | file | JimVanM: you should be working! |
| 19:30.59 | JimVanM | file: shhhh. you're not supposed to tell anyone. didn't you get your hush-money cheque this month? |
| 19:31.21 | file | JimVanM: oh, right! you are working at 110%! of course |
| 19:32.28 | *** join/#asterisk-dev Qwell (i=north@pdpc/sponsor/digium/Qwell) |
| 19:32.28 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 19:32.59 | mvanbaak | Corydon76-dig: about your 'emacs compilation is gross'... python does the same |
| 19:33.17 | mvanbaak | Corydon76-dig: it compiles the .py and dumbs the core snapshot to a .pyc |
| 19:33.44 | mvanbaak | Corydon76-dig: it's pretty common in 'compiling interpreter language files' |
| 19:36.10 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 19:36.10 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 19:36.57 | *** join/#asterisk-dev Qwell (i=north@pdpc/sponsor/digium/Qwell) |
| 19:36.57 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 19:38.21 | Qwell | glares at his IRC proxy |
| 19:40.18 | lmadsen | glares at his |
| 19:41.06 | *** join/#asterisk-dev unidinph (n=unidinph@209.216.196.2) |
| 19:50.01 | *** join/#asterisk-dev thx_man (n=thx_man@port-83-236-207-89.static.qsc.de) |
| 19:50.49 | *** join/#asterisk-dev wedhorn (n=nnnnnwed@123-243-209-34.static.tpgi.com.au) |
| 19:50.54 | *** join/#asterisk-dev joshaidan (n=joshaida@S0106001c1023e838.tb.shawcable.net) |
| 19:56.56 | eliel | mvanbaak: When supporting a color terminal, we should continue printing the chars like *callerid* colorized or just: callerid |
| 19:57.00 | eliel | colorized |
| 19:57.19 | JimVanM | file: you reminded me of how hard I was working, so I took a break |
| 19:58.08 | mvanbaak | hhmm |
| 19:58.35 | mvanbaak | eliel: are they colorized in 1.4/1.6 ? |
| 20:02.01 | mvanbaak | Corydon76-dig: didn't you put adaptive stuff into cdr_mysql in addons ? |
| 20:02.25 | Corydon76-dig | Yes |
| 20:02.42 | mvanbaak | k |
| 20:03.01 | mvanbaak | that explains the post on -dev about running DESC cdr on every CDR posting |
| 20:03.57 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 20:04.26 | eliel | no, if I have this in a terminal that supports color: <replaceable>eliel</replaceable> I should print: <eliel> with colors or just eliel with colors? |
| 20:05.10 | mvanbaak | eliel: I vote: <eliel> with colors |
| 20:05.23 | mvanbaak | for the ppl that dont see a lot of difference in the colors |
| 20:05.25 | eliel | mvanbaak: great, more easy :-) |
| 20:05.39 | mvanbaak | gheh |
| 20:08.13 | kpfleming | on every CDR post? shouldn't that only be done on a reload or something? |
| 20:08.40 | Corydon76-dig | Mmm, perhaps |
| 20:09.01 | Corydon76-dig | I'd forgotten it was done that way |
| 20:09.53 | Corydon76-dig | Do we have an addons-1.6.1 yet? |
| 20:10.47 | Corydon76-dig | We may need to keep addons and core in sync in 1.6.x, due to possible API changes |
| 20:11.08 | kpfleming | API changes are bad, remember? |
| 20:11.27 | Corydon76-dig | Yeah, but sometimes unavoidable |
| 20:11.38 | Corydon76-dig | like the upcoming codec expansion |
| 20:11.45 | kpfleming | we *may* have to treat addons as an independent project, and make it able to be built against both current and older APIs |
| 20:15.30 | mvanbaak | yes, the DESC <table> is done on every CDR post |
| 20:17.25 | wedhorn | mvanbaak: did you have a chance to check your skinny devices? |
| 20:17.55 | *** join/#asterisk-dev bbryant (n=Brett_Br@adsl-212-77-233.chs.bellsouth.net) |
| 20:17.55 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 20:18.22 | mvanbaak | wedhorn: let me check right now |
| 20:18.36 | wedhorn | thanks |
| 20:20.45 | mvanbaak | ok |
| 20:20.49 | mvanbaak | it's messed up |
| 20:20.59 | mvanbaak | big time |
| 20:21.16 | wedhorn | sort of guessed that, but how? |
| 20:21.31 | mvanbaak | let me tell you how my setup is and what happened |
| 20:21.50 | mvanbaak | when a call comes in from remote, it dials line1 on my 7960 and my 7905 |
| 20:22.02 | mvanbaak | I picked up line1 on my 7960 with the speaker button |
| 20:22.14 | mvanbaak | all ok so far |
| 20:23.09 | mvanbaak | if the 7905 also calls line1 on the 7960, the 7960 goes off speakermode and I can only talk to the remote line through the handset |
| 20:23.25 | mvanbaak | if I hit the speaker button I get the remote call back on speakerphone |
| 20:23.43 | mvanbaak | during all this, no indication that a second call comes in. not audible not visible |
| 20:24.21 | mvanbaak | the 7905 hangs up, and I keep talking to the remote call on line1 on my 7960 |
| 20:24.33 | mvanbaak | now the 7905 calls line2 on the 7960 |
| 20:24.56 | mvanbaak | the 7960 rings, the remote call on 7960-line1 stays on speakerphone |
| 20:25.03 | mvanbaak | so, a correct scenario |
| 20:25.30 | mvanbaak | if I hit the softkey for line2 on the 7960 it places line1 on hold and I talk to the 7905 |
| 20:26.31 | mvanbaak | if I hit the 'endcall' button on the 7960 while talking to line2(7905) it hangsup line1(remote) and the call on line2(7905) remains active on the speakerphone |
| 20:26.50 | mvanbaak | if I hit endcall again this call is hangup as well, and the 7960 goes back to idle |
| 20:27.49 | mvanbaak | during all this I get two warnings on the console (debug off, core verbose set to 1) |
| 20:27.54 | mvanbaak | [2008-08-26 22:19:40] WARNING[31742]: channel.c:2967 ast_prod: Prodding channel 'Skinny/6002@livingroom-7' failed |
| 20:27.59 | mvanbaak | [2008-08-26 22:19:40] WARNING[1609]: chan_skinny.c:1584 find_subchannel_by_reference: Could not find any lines that contained a subchannel with reference '7' on device 'livingroom' |
| 20:28.21 | mvanbaak | livingroom is the 7905 |
| 20:28.28 | wedhorn | the first issue is callwaiting (which needs work) |
| 20:28.28 | *** join/#asterisk-dev jameswf-home (n=james@dsl093-157-131.phx1.dsl.speakeasy.net) |
| 20:29.07 | mvanbaak | yeah, figured that |
| 20:29.10 | wedhorn | the endcall (1st) is probably a bad use of the call ref that gets sent to asterisk (and hence the second warning) |
| 20:29.50 | wedhorn | I don't have an "endcall" but can have a look at it |
| 20:30.08 | wedhorn | anyway, that wasn't actually what I was after |
| 20:30.36 | mvanbaak | k |
| 20:30.42 | mvanbaak | what you want me to do ? |
| 20:30.56 | wedhorn | can you offhook your 7960, note which line is active, onhook it and then call the other line. Can you answer the other line with a simple offhook? |
| 20:31.00 | mvanbaak | let me fire up my softphone so I can make multiple calls without billing my cellphone |
| 20:31.12 | wedhorn | only a single call is needed |
| 20:31.15 | mvanbaak | ok |
| 20:32.52 | mvanbaak | that is not possible |
| 20:33.05 | mvanbaak | if I offhook my 7960, and onhook it again |
| 20:33.15 | mvanbaak | I get busy tone out of it |
| 20:33.31 | mvanbaak | phone display shows idle |
| 20:34.18 | mvanbaak | http://pastebin.ca/1185645 |
| 20:34.20 | mvanbaak | cli output |
| 20:34.22 | wedhorn | the first offhook, onhook was just to identify which is the active line (you could also use 'skinny show debug' if you have my latest patch) |
| 20:34.39 | mvanbaak | still hearing busy tone |
| 20:34.39 | *** join/#asterisk-dev sruffell (n=sruffell@adsl-074-185-078-025.sip.bhm.bellsouth.net) |
| 20:34.39 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 20:34.53 | mvanbaak | have to power the phone, or restart asterisk for it to stop |
| 20:35.17 | mvanbaak | wedhorn: a simple offhook, onhook makes the phone unusable |
| 20:35.29 | wedhorn | think that needs a bit of work ;) |
| 20:35.33 | mvanbaak | yup |
| 20:35.45 | mvanbaak | anyways, it always uses the first line attached |
| 20:36.05 | mvanbaak | if I pound in a number, and offhook it, it will dial that number using 6000@office |
| 20:36.10 | mvanbaak | which is the first line |
| 20:36.50 | wedhorn | ok, can you call the other line and offhook it |
| 20:37.51 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@bzq-179-75-202.static.bezeqint.net) |
| 20:37.51 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 20:39.17 | mvanbaak | hhmm, that works great |
| 20:39.19 | mvanbaak | no problem |
| 20:39.24 | mvanbaak | here's the debug output |
| 20:39.42 | wedhorn | does it answer the non-active line? |
| 20:39.42 | mvanbaak | 6002(7905) calling 6001(line2 on 7960): |
| 20:39.57 | mvanbaak | it answers the incoming call on the second line |
| 20:39.58 | mvanbaak | yeah |
| 20:40.01 | mvanbaak | http://pastebin.ca/1185650 |
| 20:40.45 | mvanbaak | I dont have trouble answering a single incoming call |
| 20:40.51 | mvanbaak | no matter on what line it comes in |
| 20:41.07 | mvanbaak | incoming remote calls come in on 7960-line1 |
| 20:41.17 | mvanbaak | and internal calls come in on 7960-line2 |
| 20:41.23 | wedhorn | ok, on my phones in that situation, it would give me a dialtone on line2 (while line1 is still ringing) |
| 20:41.40 | mvanbaak | both work ok as long as I pickup the call by offhooking the handset |
| 20:41.59 | mvanbaak | if I want to answer the call by hitting the 'speaker' hardbutton I have to hit it twice |
| 20:42.15 | mvanbaak | first hit answers the call, but does not activate the speakermode |
| 20:42.20 | wedhorn | sorry, I meant a dialtone on line1 (while line2 is still ringing) |
| 20:42.24 | mvanbaak | second hit will activate the speakerphone |
| 20:42.57 | wedhorn | isn't the speaker button a hard button? |
| 20:43.01 | mvanbaak | it is |
| 20:44.06 | mvanbaak | ok, so chan_skinny is really a mess right now |
| 20:44.15 | wedhorn | which behaviour do you think we want, should offhook answer a ringing call on the non-default (for lack of a better word) or not |
| 20:44.22 | wedhorn | should it be configurable |
| 20:44.46 | wedhorn | yeah, a real mess, this conversation will keep me patching for a while |
| 20:45.02 | mvanbaak | I think offhook an a device that has a ringing call should answer that call |
| 20:46.02 | wedhorn | ok, it's easier |
| 20:46.02 | mvanbaak | offhook an a device that has multiple ringing calls should answer the oldest ringing call |
| 20:46.02 | wedhorn | not so easy |
| 20:46.02 | wedhorn | actually, not so hard |
| 20:46.23 | mvanbaak | I think the calls are already stored that way |
| 20:47.29 | mvanbaak | they are appended. so the first call will be the first in the list |
| 20:49.52 | wedhorn | yeah, but you'd want the first call to remain being indicated as "the" ringing call, probably easiest be adding ringing->sub to the device |
| 20:50.28 | wedhorn | easier to check rather than circulating through the subs everytime a new call comes in |
| 20:51.32 | wedhorn | this leads to another issue, sub handling, we do it two different ways at the moment (which is probably at the heart of your endcall issue) |
| 20:52.44 | wedhorn | do you see any reason not to let chan_skinny handle the sub identification (rather than using the ref that is sent with most(?) packet in modern phones only) |
| 20:53.00 | mvanbaak | no |
| 20:53.27 | mvanbaak | not right now |
| 20:54.07 | mvanbaak | but it might become needed when talking about 6 lines, couple on hold, couple running, and switching from line to line using the softkeys |
| 20:54.20 | wedhorn | is it possible on the new phones to interact with a background call? |
| 20:54.51 | mvanbaak | sure, simply hit the line softkey and you get that call, placing the active call on hold |
| 20:54.52 | wedhorn | the line changing (even with the softkeys) should be fine |
| 20:55.23 | wedhorn | that makes a background call active, can you end a call without switching to it? |
| 20:55.29 | *** join/#asterisk-dev korihor (n=korihor@200.7.99.2) |
| 20:55.37 | mvanbaak | no |
| 20:56.15 | mvanbaak | hhmm, there was a version of chan_skinny that was a lot less messed up than what we have now |
| 20:56.48 | wedhorn | yeah, a lot of it's to do with the softkeys |
| 20:57.06 | wedhorn | my old hardbutton phones work fairly well for normal call stuff |
| 20:58.08 | wedhorn | that's the second time you've said that in a week. Honestly, we'd probably only be rewriting a dozen or so procedures |
| 20:58.25 | mvanbaak | sorry |
| 20:58.54 | wedhorn | no worries |
| 20:58.54 | mvanbaak | it's just this habit I developed |
| 20:59.04 | mvanbaak | and it works fine here |
| 21:00.11 | mvanbaak | I run a couple of software projects, and everytime we end up in a situation like this, we stop, throw away the code in question, spend an hour, maybe two to document what we want, and do it all over again |
| 21:00.33 | seanbright | starting from scratch is *always* wrong |
| 21:00.41 | mvanbaak | never took us more then a week to come up with something that's easier to maintain, and works better |
| 21:01.05 | mvanbaak | I'm not saying starting from scratch |
| 21:01.17 | mvanbaak | but I think a lot of this module can be done differently |
| 21:01.26 | wedhorn | I think the issue is documenting what we want ;) (I want shared lines!) |
| 21:01.29 | mvanbaak | but it's too much to put in one simple patch on the tracker |
| 21:02.13 | mvanbaak | I mean, the whole transmit_* stuff is broken into several functions. that's a start. |
| 21:02.54 | wedhorn | the transmit_* stuff, do you think it's good or bad the way it is at the moment |
| 21:02.55 | mvanbaak | but the lines and subs etc we send to them are wrong sometimes. and some stuff gets in the way of things we really like to have in the driver |
| 21:02.56 | *** join/#asterisk-dev jameswf (n=james@dsl093-157-131.phx1.dsl.speakeasy.net) |
| 21:03.27 | mvanbaak | wedhorn: I think it's good |
| 21:03.37 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 21:03.50 | mvanbaak | wedhorn: I start to believe the patch it came with is one of the sources of the trouble I see |
| 21:04.36 | mvanbaak | dont know if it's the transfer stuff or the switch from sub->device as parameter to the transmit_* functions |
| 21:06.53 | mvanbaak | and that's also the reason why I'm saying this for the second time |
| 21:07.03 | wedhorn | possibly either of them. I wrote the change in the transit_ but from an oldphone perspective. The transfer stuff included a lot of stuff other than the transfer stuff (and the soft button stuff was all guesses for what I did to it) |
| 21:07.41 | mvanbaak | maybe we should sit down, write up what we really need, have a look at the current code as reference, and do it correctly once and for all |
| 21:07.57 | *** join/#asterisk-dev sruffell (n=sruffell@adsl-074-185-078-025.sip.bhm.bellsouth.net) |
| 21:07.57 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 21:08.44 | wedhorn | I can go along with that, but arguably some of the fixes are more simple than that (for example the dual sub grabbing procs) |
| 21:08.54 | wedhorn | fixing this would clean up the code a lot |
| 21:09.03 | mvanbaak | oh, don't get me wrong. |
| 21:09.07 | mvanbaak | I totally agree |
| 21:09.51 | mvanbaak | ok,... |
| 21:10.18 | wedhorn | and we've got lots of code replication that could be cleaned up by moving it off to single procs |
| 21:10.48 | mvanbaak | that needs fixing, we want shared lines, the building of devices should be fixed so we have 'build_device' and 'build_line' instead of doing it all in reload_config,... |
| 21:11.27 | wedhorn | hehe, I've been kicked several times for suggesting shared lines, I think it's a no-no |
| 21:11.53 | mvanbaak | yeah, specially now we have a SLA implementation inside asterisk |
| 21:12.41 | russellb | hopefully it works for skinny as well ... |
| 21:12.53 | russellb | assuming skinny has subscription support, then it should |
| 21:16.11 | mvanbaak | it has extension_state and 'regexten' support |
| 21:18.49 | wedhorn | no reason that SLA shouldn't work |
| 21:19.53 | wedhorn | one thing is that if we structure skinny to handle shared lines, it separates the line and device handling which has caused many issues |
| 21:22.11 | wedhorn | by separating them, you can't make assumptions about lines from devices or vice versa (many to many relation), which mean you don't inadvertently make a false assumption |
| 21:23.26 | mvanbaak | that's why we should go with the asterisk SLA implementation |
| 21:24.43 | wedhorn | my point was that generally the assumptions make tend to be wrong, with shared lines, you can't assume so you don't get it wrong |
| 21:24.53 | wedhorn | (shared line structure) |
| 21:25.18 | mvanbaak | I have a totally different thing going on in my mind |
| 21:25.22 | mvanbaak | russellb: are you here ? |
| 21:26.31 | mvanbaak | quick question, wont take more then 10 minutes max |
| 21:27.06 | *** join/#asterisk-dev DarkRift (n=dark@bas10-montreal02-1177583027.dsl.bell.ca) |
| 21:28.39 | russellb | I'm ... sort of here |
| 21:28.47 | mvanbaak | ok |
| 21:29.02 | mvanbaak | in chan_skinny we have: devices, lines and addons |
| 21:29.19 | mvanbaak | does it make sense to put them in astobj2 containers ? |
| 21:29.25 | russellb | lines and addons == buttons? |
| 21:29.44 | mvanbaak | not really |
| 21:30.02 | mvanbaak | a device holds one or more lines, and zero or more addons |
| 21:30.22 | russellb | right, but are those things actually buttons on the phone ... |
| 21:30.26 | russellb | or are addons like ... features or something |
| 21:30.56 | mvanbaak | an addon can hold lines and speeddials |
| 21:31.12 | mvanbaak | a device cannot be called, it's just the hardware |
| 21:31.21 | mvanbaak | you add lines and/or addons to it |
| 21:31.49 | mvanbaak | a line can have callerid, callwaiting, callstates etc |
| 21:32.04 | russellb | gotcha |
| 21:32.22 | russellb | well, with the current state of astobj2, devices could be in astobj2 |
| 21:32.27 | russellb | but the others, probably not |
| 21:32.35 | mvanbaak | yeah, that's what I was thinking |
| 21:32.38 | russellb | as you can not have an ordered container with astobj2 right now |
| 21:32.47 | mvanbaak | make the devices containers |
| 21:32.50 | russellb | and since your lines need to be in a specific order, that won't work |
| 21:32.54 | mvanbaak | holding lines, addons and speeddials |
| 21:33.06 | russellb | no ... the devices themselves should be objects, and you can store them in an astobj2 container |
| 21:33.15 | mvanbaak | yeah, sorry |
| 21:33.17 | russellb | you can't have lines be astobj2 objects, because then you can't keep them in order |
| 21:33.31 | russellb | and having random line order on people's phones is probably bad :) |
| 21:33.35 | mvanbaak | a container, holding all the devices |
| 21:33.40 | russellb | there ya go |
| 21:33.53 | russellb | conceptually, yes, the device is a container for those things |
| 21:33.57 | russellb | but you can't use astobj2 to do it |
| 21:34.15 | mvanbaak | I hear ya |
| 21:34.16 | russellb | until someone adds sorted containers to astobj2 |
| 21:34.19 | russellb | looks at putnopvut |
| 21:34.25 | mvanbaak | yeah, good point |
| 21:34.31 | putnopvut | looks at myself |
| 21:34.51 | mvanbaak | but a container to hold the devices is ok |
| 21:35.09 | russellb | seanbright: ping |
| 21:35.15 | russellb | seanbright: money for you on the -dev list :) |
| 21:35.45 | mvanbaak | I am fighting with realtime and skinny. the main problem is we have one big function to create the devices |
| 21:36.00 | mvanbaak | that function also attaches the lines and addons to it |
| 21:36.11 | mvanbaak | all in one big loop |
| 21:36.23 | mvanbaak | that's not going to work with realtime |
| 21:36.24 | russellb | sounds fun |
| 21:36.50 | mvanbaak | we need at least a seperate function to add lines to a device |
| 21:37.01 | russellb | nods |
| 21:37.05 | russellb | sounds reasonable :) |
| 21:37.48 | mvanbaak | an addon is just a buttonbox |
| 21:37.58 | mvanbaak | every button can be a speeddial or line |
| 21:38.04 | wedhorn | mvanbaak: that other thing is that lines and devices are created at startup. It would be sensible to create the lines at startup, but only create the device structures as required |
| 21:38.27 | wedhorn | would probably fit better with realtime as well |
| 21:38.53 | mvanbaak | wedhorn: I'm thinking, add devices and lines at startup from skinny.conf |
| 21:38.59 | mvanbaak | but use functions to do that |
| 21:39.12 | mvanbaak | instead of doing it all in reload_config() |
| 21:39.32 | mvanbaak | build_device is the main problem |
| 21:39.41 | mvanbaak | that function does everything |
| 21:40.01 | mvanbaak | make the device structure, add lines, speeddials, addons |
| 21:40.04 | wedhorn | also, we could separately configure lines in skinny.conf rather than under each device |
| 21:41.24 | mvanbaak | I cant do the realtime without seperating those |
| 21:41.54 | mvanbaak | I have the device stuff working in my skinny_realtime branch |
| 21:42.05 | mvanbaak | but got stuck on the adding of lines and speeddials |
| 21:42.15 | mvanbaak | and I did not even look at addons |
| 21:42.29 | mvanbaak | dont have any, so cannot test it |
| 21:43.30 | mvanbaak | seanbright: big mony on the -dev list ! |
| 21:43.33 | mvanbaak | collect ! |
| 21:44.17 | mvanbaak | russellb: thanks. I'll try to put the devices into an astobj2 container, and work from there |
| 21:45.16 | mvanbaak | but only after I seperated the device/line/addon building at module load |
| 21:46.21 | mvanbaak | wedhorn: a device can hold lines right now, not the other way around |
| 21:46.34 | mvanbaak | wedhorn: a line without a device is useless |
| 21:47.24 | mvanbaak | that's how it's now |
| 21:47.33 | mvanbaak | and I dont think we should do it differently |
| 21:47.57 | mvanbaak | unless we introduce a type parameter |
| 21:48.19 | mvanbaak | type=line/device/addon |
| 21:48.38 | mvanbaak | and link them in some sort of way |
| 21:49.09 | mvanbaak | where line can be attached to either a device or an addon |
| 21:49.24 | mvanbaak | and addon can be attached to a device |
| 21:49.56 | mvanbaak | that will make three database tables (and three types in skinny.conf) |
| 21:50.27 | wedhorn | a line without a device still should exist so we can send a reasonable rejection to core if it is called |
| 21:50.51 | wedhorn | however, if a device isn't connected, we don't really need to know about it |
| 21:51.45 | mvanbaak | so every line should have a member called device_id |
| 21:51.58 | mvanbaak | (or whatever identifier to a device) |
| 21:54.21 | mvanbaak | I still dont see why we should have lines without a device they are attached to |
| 21:55.08 | mvanbaak | besides that, it's not possible now neither |
| 21:55.42 | mvanbaak | looking at the code, you have a device, and you attach lines to it |
| 21:56.11 | mvanbaak | either the ammount of lines that a device can hold, or the ammount the device + configured addons can hold |
| 21:57.08 | mvanbaak | and that makes sense to me. why configure a line without a device ? |
| 21:57.32 | mvanbaak | it's useless. you cannot call it, you cannot use it to make calls |
| 21:57.45 | wedhorn | I'm suggesting that we change skinny.conf to have 3 sections [general], [devices] and [lines]. On startup, we parse [lines] and configure them. When a device connects, we parse the appropriate part of [devices] and configure it. |
| 21:57.51 | mvanbaak | or, I'm missing something |
| 21:58.35 | wedhorn | yeah, but when core tries to call it, you should send back that it's not currently connected as opposed to saying it doesn't exist |
| 21:59.01 | mvanbaak | hhmm |
| 21:59.18 | mvanbaak | that will get rid of the <line>@<device> as well |
| 21:59.33 | mvanbaak | so you simply dial (Skinny/<line>) |
| 21:59.52 | mvanbaak | (I know we can do that already) |
| 22:01.08 | mvanbaak | the [devices] section will have one or more 'line =>' statements correct ? |
| 22:14.16 | wedhorn | mvanbaak: yep, that would connect to lines defined in the [lines] section (rather than creating them on the fly as happens now) |
| 22:19.11 | wedhorn | i'm off to work |
| 22:19.35 | mvanbaak | I'm off to bed |
| 22:21.01 | mvanbaak | jpeeler: ping |
| 22:21.14 | jpeeler | mvanbaak: pong |
| 22:21.24 | mvanbaak | M11979 |
| 22:21.29 | MuffinMan | [feedback] [Asterisk] Resources/res_features 0011979: Asterisk crash when I park a call reported by jvandal (Karma: +3.25) http://bugs.digium.com/view.php?id=11979 |
| 22:21.44 | mvanbaak | report that your latest patch fixes the problem |
| 22:22.06 | jpeeler | yeah :) ... but the bug has split into two different problems i think |
| 22:22.19 | jpeeler | actually 3, 2 of them solved now |
| 22:22.51 | mvanbaak | :) |
| 22:23.00 | mvanbaak | just wanted to be sure you did not miss it |
| 22:23.12 | mvanbaak | sorry for sticking my nose into the issue |
| 22:23.14 | jpeeler | but as you can tell, i've had difficulty reproducing the original reporter's problem |
| 22:23.23 | jpeeler | it's cool |
| 22:23.55 | jpeeler | but the lack of response has made it difficult... |
| 22:24.01 | mvanbaak | yup |
| 22:24.41 | mvanbaak | btw, when in Phoenix, be sure to remind me I owe you a beer for the astobj2 stuff in the multiparking branch :) |
| 22:25.03 | jpeeler | mvanbaak: lol, i didn't do that much really |
| 22:25.04 | *** join/#asterisk-dev JimVanM (n=jimvanm@bas1-toronto63-1088810630.dsl.bell.ca) |
| 22:25.25 | mvanbaak | you did the last bit that was needed to get it into trunk |
| 22:25.45 | mvanbaak | without it, it would have become dead like it was before :) |
| 22:26.04 | jpeeler | i have a feeling more work will go into before it's all said and done, or released |
| 22:26.40 | mvanbaak | whehehehehe |
| 22:27.00 | mvanbaak | ok ok |
| 22:27.09 | mvanbaak | so I did some, you did some, olle did some |
| 22:27.20 | mvanbaak | we should give eachother beers :) |
| 22:27.31 | mvanbaak | there, all happy ;) |
| 22:28.06 | jpeeler | i do look forward to meeting you though |
| 22:28.14 | mvanbaak | yeah, same here |
| 22:28.17 | Corydon76-dig | Me three |
| 22:28.31 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-20-153.hsd1.sc.comcast.net) |
| 22:28.31 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 22:28.47 | mvanbaak | it will be great |
| 22:29.29 | mvanbaak | anyways, I really should go to bed now |
| 22:29.41 | mvanbaak | it's half past midnight here |
| 22:29.54 | Corydon76-dig | Early yet |
| 22:30.10 | mvanbaak | I have to start work at 6 AM. big day. new release of our software on our hosted platform |
| 22:30.17 | seanbright | ugh... now the real question is... do i finish the branch where i am backporting the cdr_tds changes, or do i actually take the bounty |
| 22:30.36 | mvanbaak | seanbright: both ! |
| 22:30.42 | Corydon76-dig | seanbright: take the bounty! Free money! |
| 22:30.52 | seanbright | heh |
| 22:31.11 | Corydon76-dig | seanbright: and be glad you're not a Digium employee, because we're not allowed to take bounties |
| 22:31.12 | mvanbaak | latero all. |
| 22:44.12 | kpfleming | wowza... svn 1.5 prompts you with conflicts as it finds them during 'svn update' |
| 22:46.08 | jsmith | kpfleming: Awesome! |
| 22:48.02 | seanbright | indeed |
| 22:48.29 | seanbright | --accept postpone |
| 22:48.32 | seanbright | ^^^ your friend |
| 23:09.23 | *** join/#asterisk-dev korihor (n=korihor@200.7.99.2) |
| 23:15.51 | *** part/#asterisk-dev philippel (n=p_lindhe@pool-98-111-70-106.sttlwa.fios.verizon.net) |
| 23:24.26 | kpfleming | seanbright: lots of people today on -users asking about the freetds/cdr_tds mess |
| 23:25.39 | seanbright | kpfleming: yeah i know |
| 23:25.50 | seanbright | kpfleming: working on it now (trying to collect a bounty too) |
| 23:32.04 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 23:41.20 | seanbright | kpfleming: ping |
| 23:53.56 | *** join/#asterisk-dev anonymouz666 (n=anonymou@200.218.193.6) |
| 23:54.02 | seanbright | what i would like to do is completely replace cdr_tds in 1.4 with the version that works with all versions of freetds |
| 23:54.12 | seanbright | it is functionally identical |