| 00:04.33 | *** join/#asterisk-dev sasargen (n=chatzill@68.245.248.89) |
| 00:10.58 | jpeeler | codefreeze-lap: around? |
| 00:11.07 | codefreeze-lap | yep |
| 00:11.27 | jpeeler | i'm wondering if setting the AST_FLAG_BRIDGE_HANGUP_RUN on a channel to skip running the h extension is proper or not |
| 00:12.27 | *** part/#asterisk-dev Deeewayne (n=Deeewayn@nat/digium/x-2f8d81f2b8350d23) |
| 00:13.04 | seanbright | holy crap |
| 00:14.05 | seanbright | think i found a bug in the gcc preprocessor |
| 00:14.18 | seanbright | either that or i am insane |
| 00:14.18 | Qwell | umm, yay? |
| 00:15.35 | seanbright | heh |
| 00:16.08 | seanbright | yup |
| 00:17.06 | seanbright | http://seanbright.pastebin.com/d53270910 |
| 00:18.00 | seanbright | the commas in the variable declarations are being parsed as separate arguments to AST_INLINE_API for some reason |
| 00:19.33 | jpeeler | wonders where codefreeze-lap went |
| 00:19.44 | codefreeze-lap | jpeeler: sorry |
| 00:20.24 | jpeeler | codefreeze-lap: no worries, i thought you would know it off the top of your head |
| 00:20.37 | codefreeze-lap | jpeeler: there's two places the h-exten gets run. If you run it in one spot, then you don't want to do it again in the other. That's what the flag does. |
| 00:20.50 | putnopvut | seanbright: oi |
| 00:21.15 | jpeeler | codefreeze-lap: right, what i am suggesting is would it be considered hackish to set the flag in the case that i don't want it run at all |
| 00:21.21 | jpeeler | or asking rather |
| 00:21.27 | putnopvut | seanbright: so any commas will be parsed? Even though they're inside curly braces? |
| 00:22.14 | codefreeze-lap | jpeeler: I can easily picture chan/peer reversal situations where such might be appropriate... what's the situation you are looking at? |
| 00:22.43 | *** join/#asterisk-dev drumkilla (n=russell@asterisk/digium-open-source-team-lead/russellb) |
| 00:22.43 | *** mode/#asterisk-dev [+o drumkilla] by ChanServ |
| 00:22.54 | jpeeler | i don't even know if this is something that should be done... but i figured i would go ahead and see if i could do it just in case |
| 00:24.00 | jpeeler | codefreeze-lap: this particular scenario is for looking at a caller hanging up by pressing * while waiting for an agent to become available |
| 00:25.57 | *** join/#asterisk-dev kamanashisroy (n=kamanash@119.30.34.4) |
| 00:26.17 | codefreeze-lap | shakes head. Queues. I just started looking at trying to do there what I just did for Dial, with unanswered dial attempts... some probs to clean up with various bad dial attempts... |
| 00:26.19 | seanbright | putnopvut: no... just those in the declaration apparently |
| 00:26.40 | seanbright | putnopvut: sorry, variable declarations. might just be if there are commas in the first line. i haven't dug too much into it. |
| 00:27.32 | codefreeze-lap | jpeeler: well, let's see.... if it's a caller, he should have a pbx... and if he jumps ship, he should get an h-exten run... |
| 00:27.56 | jpeeler | unless i do what i set with setting the flag |
| 00:28.08 | jpeeler | but you're saying the h extension should definitely be run |
| 00:28.31 | codefreeze-lap | It *looks* like that is what should happen; why not? |
| 00:29.19 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 00:30.15 | jpeeler | just because before i don't think it was possible |
| 00:30.38 | jpeeler | unless you did some dialplan magic to make it work |
| 00:31.36 | jpeeler | i don't think i'm wrong about that... |
| 00:32.50 | codefreeze-lap | jpeeler: I have to go now and get ready to go out and visit somebody. But please, explain the situation here... and if I have enough energy left when I get back, and you are still on line, we can discuss it further in 2-3 hours. |
| 00:33.01 | file | jpeeler: why wouldn't it work? |
| 00:33.08 | codefreeze-lap | tomm. morn if not |
| 00:33.21 | jpeeler | codefreeze-lap: ok |
| 00:33.51 | codefreeze-lap | no, explain the exact situation, get it out here, and I'll read it when I return. |
| 00:34.03 | codefreeze-lap | Because I'm not seeing the situation |
| 00:34.12 | jpeeler | alright |
| 00:34.20 | *** join/#asterisk-dev ManxPower (n=manxpowe@24.196.31.252) |
| 00:34.27 | jpeeler | first i will make sure i'm right... |
| 00:35.21 | jpeeler | i guess my lack of understanding of how the h extension is supposed to work might be at play |
| 00:37.42 | file | jpeeler: ummm there's not much to it... it is supposed to execute when a channel that is executing dialplan logic hangs up |
| 00:38.08 | jpeeler | every time? |
| 00:38.27 | jpeeler | even when dial is not used? |
| 00:38.33 | kpfleming | yes |
| 00:38.33 | file | yes |
| 00:38.38 | russellb | yes |
| 00:38.42 | kpfleming | yes |
| 00:38.46 | russellb | si |
| 00:38.46 | file | YeS |
| 00:39.03 | ManxPower | exten => h is executed when the CALLING party hangs up. |
| 00:39.16 | kpfleming | true |
| 00:39.17 | ManxPower | you don't have to use a Dial if you only have a calling party. |
| 00:39.32 | kpfleming | the called party can also execute dialplan logic via M() and stuff like that |
| 00:39.39 | ManxPower | To do post processing when the called party hangs up, use the "g" option of Dial |
| 00:40.33 | jpeeler | ok, i was just being stupid, wrong context |
| 00:44.46 | ManxPower | *nod* I believe special extensions are not accessable if they are in an include =>'d context |
| 00:55.02 | Corydon76-dig | Why wouldn't they? |
| 00:55.30 | russellb | that would be bizarre if so ... |
| 00:58.50 | ManxPower | Corydon76-dig: It's just what I've seen in the real world. |
| 00:59.42 | ManxPower | Maybe I should have said something like "exten h and i (at least) don't match by default if they are in an include =>'d context |
| 01:02.30 | Corydon76-dig | I still don't see why not |
| 01:03.04 | Corydon76-dig | Now if you're talking about a macro context, I agree |
| 01:03.20 | ManxPower | maybe I'll plug a phone into my server and test it out sometime. |
| 01:05.40 | ManxPower | maybe I experienced the problem when I was using macros. |
| 01:06.01 | ManxPower | I've not had to change my macros in any significant ways in *years* |
| 01:06.31 | Corydon76-dig | Yeah, you can't put "h" in a macro and expect it to work |
| 01:07.54 | Marquis42 | I just ran the test, and the h extension is run in an included context. |
| 01:08.05 | kpfleming | it should be |
| 01:08.18 | kpfleming | the matching logic doesn't special case any particular extensions AFAIK |
| 01:08.27 | Marquis42 | I thought so as well, but my curiosity got the better of me so I had to check. |
| 01:08.42 | ManxPower | I'll go run some tests |
| 01:09.00 | Marquis42 | This, FWIW, is on trunk. No idea if that should/could/does make a difference. |
| 01:09.26 | russellb | It's _possible_ that it was some code that got lost at some point ... there was a big rewrite of exten matching code for 1.4 |
| 01:09.30 | russellb | and again for trunk |
| 01:12.24 | *** part/#asterisk-dev macli (n=macli@nmc.brc.ubc.ca) |
| 01:12.26 | Marquis42 | russellb: I've been working on that fix to app_read (by the circuitous path of changing ast_readstring_full), and I was wondering if it makes any sense to have a special-case return value for signifying that the user hit # without entering any digits. The reason I say that is because the only time it's an issue is when ast_app_getdata is looping through a list of files. So I can fix it there and not have to be touching the |
| 01:12.28 | Marquis42 | other uses of ast_readstring. |
| 01:13.09 | russellb | ummmm, I don't know, I'd have to look ... |
| 01:13.19 | russellb | can't at the moment |
| 01:13.26 | russellb | if you want to post to the -dev list, I can try to answer later |
| 01:13.34 | Marquis42 | I can do that, no problem. |
| 01:14.06 | russellb | thanks |
| 01:16.55 | ManxPower | "i" seems to work. "h" does not. I'll test some more |
| 01:18.37 | ManxPower | http://pastebin.ca/1276462 |
| 01:18.40 | russellb | which version? |
| 01:18.56 | ManxPower | 1.2 |
| 01:19.05 | russellb | interesting ... |
| 01:19.11 | russellb | so i wonder if this "feature" got lost in 1.4 |
| 01:19.18 | russellb | and if so, do we want it to come back, heh |
| 01:19.23 | ManxPower | take a look at the pastebin to make sure I didn't do something stupid? |
| 01:19.45 | russellb | Yeah, I see it .. looks fine to me |
| 01:19.46 | ManxPower | russellb: I've started playing with 1.6 |
| 01:20.05 | ManxPower | At least I was not *totally* wrong. |
| 01:27.52 | Corydon76-dig | russellb: I figured out an innovative way to do tab-completion of all numbers between 0 and 2.1 billion |
| 01:28.12 | russellb | heh |
| 01:28.27 | russellb | just tab complete the next digit? |
| 01:28.27 | Corydon76-dig | 1 completes to 1, 10, 10..., 11, 11..., 12, 12... etc. |
| 01:29.33 | Corydon76-dig | It doesn't really tab-complete, but it does give you a hint that digits are available in that argv slot |
| 01:29.45 | russellb | nods |
| 01:30.19 | Corydon76-dig | So, patch uploaded to 13969 |
| 01:30.27 | putnopvut | M13969 |
| 01:30.29 | MuffinMan | [ready for testing] [Asterisk] General 0013969: [patch] Need tab completion of "core set debug X filename.c" reported by jtodd (Karma: +26.75) http://bugs.digium.com/view.php?id=13969 |
| 01:31.01 | putnopvut | oh you really are going to tab-complete numbers... |
| 01:31.23 | Corydon76-dig | putnopvut: I think that's an innovative way to do it, don't you agree? |
| 01:31.50 | putnopvut | I figured you'd do it through conversion to string and some strncmps. |
| 01:31.50 | Corydon76-dig | 21 maximum possibilities each time |
| 01:32.02 | putnopvut | Let me look at it to see what you really do. |
| 01:32.29 | snuff-work | thanks for the comment on that macro thing putnopvut :) |
| 01:32.49 | putnopvut | snuff-work: I must have forgotten. What macro thing? :) |
| 01:33.19 | snuff-work | M13783 |
| 01:33.21 | MuffinMan | [confirmed] [Asterisk] Channels/chan_sip/Registration 0013783: [patch] Cannot register with sip providers that require '@' in the username reported by navkumar (Karma: +1.00) http://bugs.digium.com/view.php?id=13783 |
| 01:33.27 | putnopvut | ah, that. |
| 01:33.39 | putnopvut | Yeah, I screwed it up to begin with, so I figured I should fix it, too :) |
| 01:38.06 | putnopvut | Corydon76-dig: I see what you've done there. Interesting... |
| 01:38.49 | putnopvut | Any reason you chose 21 as the upper bound of the for loop? |
| 01:39.22 | putnopvut | Is it because INT_MAX is approx 2.1 billion on most systems? |
| 01:39.56 | putnopvut | I guess the main question is...why would you want to tab-complete numbers? |
| 01:43.53 | seanbright | to 'suggest' to the user that numbers are a possible option |
| 01:43.55 | seanbright | ? |
| 01:44.46 | russellb | yeah |
| 01:44.49 | russellb | that is correct. |
| 01:44.52 | seanbright | sweet |
| 01:45.06 | russellb | we should also suggest roman numerals |
| 01:45.11 | seanbright | hawt |
| 01:45.21 | russellb | and perhaps emoticons |
| 01:45.22 | putnopvut | I just put a note on the issue regarding my opinion of tab-completing numbers. |
| 01:45.27 | seanbright | core set verbose xii |
| 01:45.34 | seanbright | ohhh |
| 01:45.38 | seanbright | runs off to read |
| 01:46.02 | russellb | lol @ putnopvut's simplification of the problem |
| 01:46.05 | seanbright | heh |
| 01:46.09 | russellb | that's not a bad idea, either .. |
| 01:46.22 | putnopvut | I just don't see the value in tab-completing individual numbers, especially since they can't really be "completed" by the CLI. |
| 01:47.24 | seanbright | well, the problem with <number> is that if that gets completed, it's not a valid argument |
| 01:47.50 | putnopvut | it would show up as a "suggestion" when you press tab, not as an actual attempt to put it in-place. |
| 01:47.57 | seanbright | MAYBE it should suggest <bikeshed> |
| 01:48.02 | putnopvut | lol! |
| 01:48.15 | russellb | it will get inserted if <number> is the only valid completion at that point |
| 01:48.21 | seanbright | correct |
| 01:48.23 | russellb | core set debug <tab> |
| 01:48.28 | russellb | will add <number> to your command |
| 01:48.30 | russellb | which is not ideal. |
| 01:48.34 | putnopvut | no it won't. |
| 01:48.39 | russellb | sure it will |
| 01:48.44 | putnopvut | It will give you the choice of "atleast" or "<number>" |
| 01:49.01 | putnopvut | But yeah, I'm just being a douche. |
| 01:49.04 | seanbright | totally |
| 01:49.08 | russellb | lol |
| 01:49.10 | putnopvut | There are other cases where a number is the only valid input. |
| 01:49.13 | russellb | core set debug atleast <tab> |
| 01:49.20 | putnopvut | like that ^ |
| 01:49.28 | seanbright | the REAL question is... how totally arbitrary debug and verbose levels actually are |
| 01:49.38 | putnopvut | seanbright: totally arbitrary |
| 01:49.39 | russellb | that's not a question |
| 01:49.40 | seanbright | only that isn't a question |
| 01:49.58 | russellb | and how useless most of LOG_DEBUG is |
| 01:49.59 | russellb | heh |
| 01:50.04 | seanbright | yeah |
| 01:50.18 | seanbright | i mean, what are truly meaningful values for the numeric argument? |
| 01:50.19 | putnopvut | It's useful in some places. |
| 01:50.19 | seanbright | 1-5? |
| 01:50.22 | seanbright | 1-10? |
| 01:50.27 | russellb | 1 to 5 is most of it |
| 01:50.31 | russellb | 1 to 3 is most of it. |
| 01:50.31 | seanbright | done |
| 01:50.33 | russellb | 1 is most of it. |
| 01:50.38 | seanbright | complete 1 through 5 |
| 01:50.39 | awk_r | heh |
| 01:50.42 | putnopvut | seanbright: there's a debug level 100 statement in app_voicemail in trunk. |
| 01:50.50 | awk_r | putnopvut, you would |
| 01:50.52 | seanbright | putnopvut: i don't have to guess who added that |
| 01:50.55 | russellb | heh, there are some silly outliers in the stats, yes |
| 01:50.59 | seanbright | the aforementioned douche |
| 01:51.06 | kpfleming | you guys are going about this all the wrong way |
| 01:51.06 | putnopvut | That's me! |
| 01:51.19 | seanbright | kpfleming is right |
| 01:51.22 | seanbright | remove logging altogether |
| 01:51.29 | kpfleming | clearly the proper method is to run an awk process over all the code identifying all possible values, then compile that list in so you can tab complete it |
| 01:51.33 | awk_r | core set verbose -3 |
| 01:51.38 | russellb | lol! |
| 01:51.40 | seanbright | kpfleming: genius! |
| 01:51.43 | kpfleming | duh |
| 01:51.45 | file | kpfleming: brilliant |
| 01:51.49 | russellb | at runtime! |
| 01:51.49 | awk_r | done! |
| 01:52.02 | russellb | Here's what we'll do ... |
| 01:52.06 | seanbright | wait |
| 01:52.09 | seanbright | is this going to be serious? |
| 01:52.15 | putnopvut | I hope not |
| 01:52.17 | kpfleming | are you sitting down? |
| 01:52.21 | russellb | we'll change ast_debug() to include a magic constructor function that registers it's debug level as being used in the source |
| 01:52.23 | seanbright | laying, actually |
| 01:52.29 | kpfleming | russellb: way ahead of you |
| 01:52.49 | awk_r | core set verbose <tab> now yields: 1, 2, 3, 4, 5, 10, 20, 50, 101, waffle, and kpfleming |
| 01:53.16 | putnopvut | the waffle verbosity is totally useless. |
| 01:53.16 | file | waffle? I should make breakfast plans with a friend this weekend |
| 01:53.24 | seanbright | add it to backtrace.txt... "Set your debug level to waffle" |
| 01:53.24 | putnopvut | It just changes all nouns and verbs to "waffle" |
| 01:53.25 | kpfleming | i am going home now |
| 01:53.32 | russellb | cya kpfleming ! |
| 01:53.33 | kpfleming | please don't break the world |
| 01:53.38 | russellb | will try :) |
| 01:53.50 | russellb | that would be unfortunate while you're trying to drive home |
| 01:54.04 | putnopvut | "Rate My Dialplan Contest" |
| 01:54.11 | russellb | eep |
| 01:54.41 | seanbright | the ad revenue alone! |
| 01:54.53 | *** join/#asterisk-dev snuff-work (n=jsewell@203.19.141.34) |
| 01:54.53 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 01:54.54 | russellb | i'm totally putting ascii art boobs in my dialplan |
| 01:55.21 | seanbright | we need an obfuscated dialplan contest |
| 01:55.34 | seanbright | everybody wins! |
| 01:55.54 | snuff-work | and u can't cheat with funky odbc procedures |
| 01:55.54 | file | encrypted dialplan. |
| 01:56.01 | snuff-work | lmao encrypted |
| 01:56.14 | russellb | asterisk has to decrypt on every priority lookup? |
| 01:56.20 | file | russellb: yes |
| 01:56.33 | russellb | how about 100% compression? |
| 01:56.36 | snuff-work | we need to use all the extra CPU cycles for something |
| 01:56.47 | file | russellb: 110% compression in fact |
| 01:56.51 | russellb | 100% file compression and 0 bitrate voice codecs |
| 01:56.57 | russellb | that's the future of asterisk |
| 01:57.04 | snuff-work | rainbow tables |
| 01:57.13 | putnopvut | That is some low-bandwidth media there |
| 01:57.15 | russellb | infinite recording space and infinite calls in non-zero bandwidth |
| 01:57.32 | putnopvut | I sense a floating point exception in your future |
| 01:57.35 | russellb | infinite calls with no bandwidth even |
| 01:57.57 | russellb | think how rich we could be! |
| 01:59.43 | *** join/#asterisk-dev jtodd (n=jtodd@249.sub-70-222-193.myvzw.com) |
| 01:59.55 | seanbright | 10s of 10s of dollars |
| 02:00.18 | file | nods to jtodd |
| 02:00.48 | putnopvut | steals file's chair while he's nodding. |
| 02:01.22 | file | putnopvut: meanie :( |
| 02:01.34 | putnopvut | I didn't take your good chair. |
| 02:02.01 | file | putnopvut: I will take... your mini fridge |
| 02:04.05 | russellb | randomly attacks awk_r with IE5 |
| 02:05.52 | awk_r | redirects russellb to mozilla.org. |
| 02:07.48 | russellb | installs file as his firewall |
| 02:08.02 | file | I would make a bad firewall |
| 02:08.10 | russellb | do you burn easily? |
| 02:08.28 | file | yes |
| 02:08.33 | file | I also spontaneously combust |
| 02:08.34 | russellb | that is sad |
| 02:08.47 | russellb | are you implying that you have done so in the past? |
| 02:08.55 | file | I will neither confirm or deny that |
| 02:09.20 | russellb | k |
| 02:09.22 | awk_r | russellb, http://tinyurl.com/6x2jhb |
| 02:09.39 | russellb | eep |
| 02:10.06 | awk_r | that site makes for some good-much fun |
| 02:30.26 | *** join/#asterisk-dev obnauticus (n=lol@about/windows/regular/obnauticus) |
| 02:33.40 | seanbright | build warnings/errors about not paying attention to fread/fwrite return values gets merged |
| 02:33.44 | seanbright | correct? |
| 02:33.57 | russellb | nods |
| 02:34.07 | seanbright | sweet. |
| 02:34.55 | putnopvut | is going home now. |
| 03:53.13 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@bzq-179-75-202.static.bezeqint.net) |
| 03:53.13 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 05:22.15 | *** join/#asterisk-dev sruffell (n=sruffell@nat/digium/x-031e5f89f8473124) |
| 05:22.15 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 05:27.41 | *** join/#asterisk-dev CunningPike (n=arodgers@S010600095b33697f.vc.shawcable.net) |
| 05:39.56 | *** join/#asterisk-dev obnauticus (n=lol@about/windows/regular/obnauticus) |
| 07:05.55 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 07:30.35 | *** part/#asterisk-dev snuff-work (n=jsewell@203.19.141.34) |
| 07:43.53 | *** join/#asterisk-dev Daviey (n=Daviey@ubuntu/member/daviey) |
| 07:48.41 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 07:48.41 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:51.04 | oej | morning |
| 08:17.25 | *** join/#asterisk-dev philipp64 (n=chatzill@63.224.43.239) |
| 08:25.14 | snuff-home | ello oej |
| 08:25.25 | oej | Hello Snuff |
| 08:25.44 | snuff-home | thinks its a tad hot over here.. 30C atm |
| 08:26.14 | snuff-home | what's the weather over there? |
| 08:57.34 | ManxPower | 27F |
| 08:58.52 | wedhorn | How about that: 27C here |
| 09:51.32 | *** join/#asterisk-dev eliel (n=Eliel@200.183.52.134) |
| 09:51.33 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 10:20.13 | *** join/#asterisk-dev IguanaNed (n=me@CPE000625db3f84-CM00111ae43f1e.cpe.net.cable.rogers.com) |
| 10:44.37 | eliel | M13969 |
| 10:44.39 | MuffinMan | [ready for testing] [Asterisk] General 0013969: [patch] Need tab completion of "core set debug X filename.c" reported by jtodd (Karma: +26.75) http://bugs.digium.com/view.php?id=13969 |
| 10:45.11 | eliel | A issue with low priority gets more attention than the others... he |
| 10:45.55 | *** join/#asterisk-dev qdk (n=qdk@212.27.19.21.bredband.3.dk) |
| 10:46.27 | tzafrir_laptop | eliel, what happens if I use a asterisk.conf without the new compat directive? |
| 10:46.41 | tzafrir_laptop | What will be my delimiter? |
| 10:47.04 | eliel | "," comma |
| 10:47.41 | tzafrir_laptop | Where does it default to 1? |
| 10:47.51 | tzafrir_laptop | asterisk.c only sets it if it sees the directive |
| 10:48.37 | eliel | let me check twice |
| 10:53.46 | eliel | tzafrir_laptop: i am compiling, i will finish testing again in a minute, but i am setting a flag only if < 1.5 otherwise it is being set as 0 by default |
| 10:54.01 | eliel | and flag_setted ? "|" : "," |
| 10:54.08 | tzafrir_laptop | ah, ok |
| 10:54.57 | tzafrir_laptop | err.... what is "version" exactly? |
| 10:56.12 | eliel | the value of app_delim, app_set, etc... |
| 10:56.21 | eliel | the concept you mean? |
| 10:57.07 | eliel | it is a float |
| 10:59.26 | tzafrir_laptop | hmmm.... it depends on the order of scanning |
| 10:59.43 | tzafrir_laptop | version *must* be the first directive. Which is wrong |
| 11:00.03 | tzafrir_laptop | consider: |
| 11:00.13 | tzafrir_laptop | [compat](+) |
| 11:00.25 | tzafrir_laptop | version = 1.2.3 ; just making this up |
| 11:00.53 | tzafrir_laptop | the above version directive will have no effect on previous items |
| 11:01.25 | tzafrir_laptop | (not something specific to your patch. Problem exists with current code) |
| 11:04.02 | eliel | why you will put 1.2.3? this is a compatibility section, you are not supposed to change something in 1.X.Y that is not compatible with version 1.X.(Y-1) |
| 11:04.12 | tzafrir_laptop | hmm... does asterisk.c ever get reloaded? |
| 11:04.24 | tzafrir_laptop | eliel, ignore the number |
| 11:04.29 | eliel | tzafrir_laptop: dont think so |
| 11:04.52 | eliel | the template will work without a problem though... |
| 11:05.15 | tzafrir_laptop | because people only used the provided sample |
| 11:06.06 | tzafrir_laptop | Depending on the order of parameters makes asterisk config files tricky to write automatically |
| 11:06.18 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 11:07.11 | eliel | tzafrir_laptop: we are not defining version = X we are using app_delim=X, res_agi=X where X is the actual version... |
| 11:07.45 | eliel | when using templates the order is a problem always... also when using it in dialplan contexts |
| 11:09.22 | eliel | well... the problem with templates is if you repeat a definition that is coming from a template... but if the intersection is null, then you don't have any problem with that template |
| 11:18.18 | eliel | tzafrir_laptop: thanks for looking at the code |
| 11:28.47 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 12:41.13 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:41.13 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 12:42.23 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 13:10.13 | *** join/#asterisk-dev eliel (n=Eliel@189.8.113.140) |
| 13:10.13 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 13:22.22 | *** join/#asterisk-dev russellb (n=russellb@asterisk/digium-open-source-team-lead/russellb) |
| 13:22.22 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 13:28.36 | *** join/#asterisk-dev mbranca (n=matteo@93-62-230-243.ip24.fastwebnet.it) |
| 13:51.34 | *** join/#asterisk-dev moy (n=moy@69.150.142.130) |
| 13:53.24 | russellb | seanbright: ping |
| 14:02.39 | *** join/#asterisk-dev jasonwoot (n=some@bookit-dev.com) |
| 14:15.52 | eliel | russellb: did you try: ast_channel_alloc(0, AST_STATE_DOWN, 0, 0, "", "", "", 0, ""); instead of ast_channel_alloc(0, AST_STATE_DOWN, 0, 0, "", "", "", 0, "%s", "") ? |
| 14:16.45 | russellb | yup, if you do that, you get a warning about an empty format string |
| 14:17.21 | *** join/#asterisk-dev jtodd (n=jtodd@nat/digium/x-345a703cca1bbe47) |
| 14:18.04 | eliel | aaah, ok |
| 14:20.13 | oej | jtodd: You're alive! |
| 14:39.01 | oej | I guess it was just a jtodd-bot ;-) |
| 14:41.46 | *** join/#asterisk-dev dioedu (n=dioedu@201.7.117.114) |
| 14:45.35 | jtodd | no, not a bot, but a human with too many windows and not enough time. |
| 14:46.58 | lmadsen | time is of the essence |
| 14:48.38 | mvanbaak | jtodd: the 'core set debug 2 chan_sip.c' stuff now works, thanks to Corydon76-dig |
| 14:48.50 | mvanbaak | can you test the patch so we can commit it ? |
| 14:49.29 | eliel | i have already done that |
| 14:49.33 | eliel | there ir a litle problem |
| 14:50.22 | oej | shouldn't be chan_sip.c ? Isn't it for the modules? |
| 14:50.32 | oej | chan_sip.so |
| 14:50.34 | eliel | when you put "core set debug at<TAB>" it should not try to autocomplete the numbers |
| 14:50.49 | oej | Involving names of source code modules on top of module names would be too confusing |
| 14:51.35 | lmadsen | I would agree with that. My instinct would be the .so, not the .c |
| 14:51.56 | *** join/#asterisk-dev kamanashisroy (n=kamanash@119.30.34.4) |
| 14:52.27 | eliel | I would use just the module name without extension |
| 14:53.17 | eliel | what if the modules are embedded |
| 14:53.25 | eliel | in the core |
| 14:54.24 | russellb | the filename will still show up the same even if they are embedded |
| 14:54.42 | russellb | the debug/verbose stuff doesn't work via module name, so that isn't going to work |
| 14:55.06 | russellb | __FILE__ was the only thing automatically available to use and check against |
| 14:55.13 | *** join/#asterisk-dev putnopvut (n=putnopvu@nat/digium/x-32732d9c0f3baa83) |
| 14:55.13 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:57.50 | eliel | ok, thats the answer... leave everything as it is now.. |
| 14:59.29 | eliel | hmmm, what if we register the files with a type, so we know what type of file is.. module|core |
| 14:59.45 | oej | It doesn't make sense for the user. We load modules by .so - surely you could make a hack to replace .c with .so, russellb. Come on, give us some user-friendlyness |
| 14:59.54 | russellb | It's not just .c to .so |
| 15:00.00 | russellb | Not all modules are a single source file |
| 15:00.17 | russellb | For modules, it's possible we could check the AST_MODULE define since we have that now, too ... |
| 15:00.34 | russellb | I'd be fine with adding that |
| 15:00.36 | russellb | shouldn't be hard. |
| 15:01.04 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 15:03.52 | *** join/#asterisk-dev mog (n=mog@nat/digium/x-cc586e1affc13458) |
| 15:03.52 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 15:05.34 | eliel | what if we remove the extension? also when loading modules... libraries sonames work like that (??)... |
| 15:05.54 | *** join/#asterisk-dev sruffell (n=sruffell@adsl-074-185-078-025.sip.bhm.bellsouth.net) |
| 15:05.54 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:05.55 | eliel | because we have modules and core files like rtp.c, etc... |
| 15:07.23 | *** join/#asterisk-dev codefreeze-lap (n=murf@72.21.67.40) |
| 15:07.23 | *** mode/#asterisk-dev [+o codefreeze-lap] by ChanServ |
| 15:09.07 | eliel | nooo, it makes no sense... |
| 15:14.45 | *** join/#asterisk-dev Pazzo (n=ugelt@reserved-225136.rol.raiffeisen.net) |
| 15:16.13 | russellb | However, we're getting a ways beyond just talking about what is required to add tab completion :) |
| 15:19.58 | eliel | yeap |
| 15:21.29 | *** join/#asterisk-dev linuxer_igor (n=linuxer_@mlsrj200152096p202.mls.com.br) |
| 15:26.02 | eliel | russellb: I have upload a review request with a patch to make backward compatible all the applications with the | parameter separator |
| 15:27.45 | lmadsen | if anyone has any bugs they wish to have tested today, pls msg me with some bug numbers |
| 15:28.28 | eliel | lmadsen: http://reviewboard.digium.com/r/79 |
| 15:28.47 | eliel | is related with chan_dahdi application |
| 15:29.22 | lmadsen | app/fun! |
| 15:29.32 | lmadsen | eliel: coolio, I'll see what I can do |
| 15:29.59 | Marquis42 | lmadsen: 13943? |
| 15:30.02 | Marquis42 | M13943 |
| 15:30.04 | MuffinMan | [confirmed] [Asterisk] Applications/app_minivm 0013943: [patch] Multiple bugs in app_minivm reported by Marquis (Karma: +14.25) http://bugs.digium.com/view.php?id=13943 |
| 15:30.06 | eliel | you can download the patch if you want from the review board. |
| 15:30.25 | *** join/#asterisk-dev iulius (n=iulius@mail1.technologieshq.com) |
| 15:30.39 | lmadsen | Marquis42: oh sweet! I had forgotten. I will put it on the stack. |
| 15:31.03 | Marquis42 | lmadsen: Thanks! |
| 15:31.14 | eliel | Marquis42: I have changed Minivm xml documentation, maybe your patch will have trouble applying to latest trunk... |
| 15:31.53 | eliel | lmadsen: thanks |
| 15:31.54 | seanbright | russellb: pong |
| 15:31.54 | Marquis42 | eliel: I don't think it will, but I can try it. The changes I made were all to code and I'm pretty sure patch will figure out the right thing to do. |
| 15:31.59 | seanbright | russellb: sorry, should have test compiled |
| 15:32.42 | lmadsen | slaps seanbright on the wrist with a tiny ruler |
| 15:33.17 | seanbright | hey! that was slightly uncomfortable |
| 15:33.33 | putnopvut | throws fritos at seanbright |
| 15:33.43 | eliel | Marquis42: Hunk #1 FAILED at 207. |
| 15:33.46 | eliel | :) |
| 15:33.47 | lmadsen | eats some of the fritos |
| 15:34.06 | lmadsen | I saw these new chips from Miss Vickies last night that were Rosemary and Basil... I almost bought them to try them out |
| 15:34.08 | codefreeze-lap | I've mentioned before the one company where, if you break the build, they throw you into the lake in the back yard, off the dock... |
| 15:34.22 | seanbright | putnopvut: review a pastebin for me? |
| 15:34.28 | putnopvut | codefreeze-lap: that's pretty extreme. |
| 15:34.28 | seanbright | re: app_voicemail |
| 15:34.33 | putnopvut | seanbright: all righty |
| 15:34.40 | seanbright | un momento |
| 15:35.54 | codefreeze-lap | putnopvut: Yeah, the guy telling me about said they threw him in, he just about drowned, got a huge sinus infection, looked in pretty bad shape. Made mental note to myself: Don't throw folks in lake for breaking build. |
| 15:36.25 | Marquis42 | eliel: Yeah, that's probably true. I completely forgot about the variable renaming and that's certainly in the docs as well.... I'll upload a new patch to the bug. |
| 15:39.38 | seanbright | putnopvut: http://pastebin.ca/1276924 |
| 15:40.09 | seanbright | putnopvut: the point: to make sure that \n's in new emailbody and pagerbody are properly escaped to \r\n when IMAP_STORAGE is used |
| 15:40.23 | putnopvut | I see. |
| 15:40.31 | seanbright | otherwise imap servers cry |
| 15:40.40 | seanbright | about bare newlines |
| 15:42.31 | putnopvut | I see a potential problem. |
| 15:42.34 | seanbright | shoot |
| 15:42.53 | putnopvut | If someone is using IMAP storage and has emailbody=\n |
| 15:43.03 | putnopvut | I think that would cause a buffer underflow. |
| 15:43.14 | *** join/#asterisk-dev fred-tmft (n=fred-tea@c-69-244-180-112.hsd1.mi.comcast.net) |
| 15:43.15 | seanbright | you are correct |
| 15:43.22 | seanbright | if (str->str[str->used - 1] != '\r') { |
| 15:43.30 | putnopvut | yes, there. |
| 15:43.41 | *** part/#asterisk-dev fred-tmft (n=fred-tea@c-69-244-180-112.hsd1.mi.comcast.net) |
| 15:43.44 | seanbright | there you mean? |
| 15:43.45 | putnopvut | So I think you need to be sure that str->used is non-zero. |
| 15:43.54 | seanbright | k |
| 15:44.02 | seanbright | yup |
| 15:44.36 | lmadsen | putnopvut: good hustle |
| 15:45.21 | seanbright | if (!str->used || str->str[str->used - 1] != '\r') { |
| 15:45.24 | seanbright | putnopvut: ^^^ |
| 15:45.37 | seanbright | is that the only thing you see wrong? |
| 15:46.32 | putnopvut | that was the first thing I saw. I need to take one more look just to be sure. |
| 15:46.32 | seanbright | k |
| 15:47.57 | *** join/#asterisk-dev Deeewayne (n=Deeewayn@nat/digium/x-c38cc5dfda2eb496) |
| 15:47.57 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 15:48.17 | putnopvut | As far as your patch goes, it seems right. |
| 15:48.17 | russellb | seanbright: I'll let it slide this time :-p |
| 15:48.32 | seanbright | putnopvut: is there a 'but' to follow? |
| 15:48.33 | putnopvut | I do notice, however, a pre-existing potential for a memory leak, though. |
| 15:48.51 | seanbright | emailbody and/or pagerbody not being free'd? |
| 15:48.57 | seanbright | russellb: awesome, thanks :) |
| 15:49.14 | putnopvut | seanbright: exactly. I need to double check to be sure that's not done earlier during a reload. |
| 15:49.33 | seanbright | putnopvut: it appears to already be done |
| 15:49.34 | putnopvut | and it is, so nevermind. |
| 15:49.41 | seanbright | splendid |
| 15:49.47 | putnopvut | "Ship it!" |
| 15:49.50 | seanbright | heh |
| 15:50.23 | seanbright | thanks for the review |
| 15:52.01 | putnopvut | The only other thing I might suggest is changing the value parameter of substitute_escapes to not be const since it is modified in that function. |
| 15:52.13 | putnopvut | Then you could also get rid of the cast. |
| 15:52.13 | *** join/#asterisk-dev shazaum (n=shazaum@unaffiliated/shazaum) |
| 15:52.37 | seanbright | it's not modified... |
| 15:52.59 | seanbright | value is only read |
| 15:53.15 | putnopvut | ah, you're right. You modify the ast_str, not current or value. |
| 15:53.27 | seanbright | correct. because the size of the string will increase. |
| 15:53.32 | seanbright | \n -> \r\n |
| 15:53.39 | seanbright | so i need a new bugger. |
| 15:53.42 | seanbright | s/gg/ff/ |
| 15:54.20 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.130.105) |
| 16:08.08 | *** join/#asterisk-dev IgorG (n=igorg@host-92-124-184-228.pppoe.omsknet.ru) |
| 16:09.32 | eliel | "<oej> I think we have to let go. Say thankyou and farewell to image support..." |
| 16:10.00 | oej | I don't see the point of adding format_png. Anyone seen any clients besides the old gnophone that uses it? |
| 16:10.22 | lmadsen | not I... |
| 16:11.14 | eliel | The idea here is to remove SendImage and format_jpeg... |
| 16:11.24 | eliel | and all the code related to image support? |
| 16:11.33 | oej | The client's I have seen now sends URLs instead |
| 16:11.43 | oej | Well, according to the new policy we don't remove stuff |
| 16:11.48 | lmadsen | aye |
| 16:11.58 | oej | But I don't see a point in adding to what we have to support for functions that no one really uses |
| 16:12.10 | Corydon76-dig | Yeah, the main issue with images is that the entire image must fit into a single frame |
| 16:12.26 | Corydon76-dig | so you get to deal with MTU and other things like that |
| 16:12.33 | lmadsen | yuck... |
| 16:12.33 | oej | Fun, very fun. |
| 16:12.56 | russellb | I don't think _anyone_ uses image support |
| 16:12.58 | russellb | it seems pointless |
| 16:12.58 | oej | Image as an application is actually mentioned in RFC3261 |
| 16:13.19 | Corydon76-dig | and even so, the maximum image size is 64k, minus headers |
| 16:13.20 | oej | SDP/RTP is "session" but we can send an INVITE with IMAGE as a session type too... |
| 16:13.54 | russellb | yeah, it's basically just gnophone |
| 16:13.55 | oej | The only reason I see for keeping the code, is the remote future possibility to insert images in a video stream for IVRs |
| 16:13.58 | russellb | which I don't know if anyone uses ... |
| 16:14.15 | russellb | hm, that's an interesting thought |
| 16:14.15 | oej | generate image to disk, read it with format_* and send it out in the video stream |
| 16:14.21 | russellb | yeah |
| 16:14.37 | oej | I don't know how many patents we might have to break to do that, but it's a thought. |
| 16:15.18 | Corydon76-dig | Do we even support any patented video types? |
| 16:15.58 | kpfleming | H.263 and H.264 are covered by patents |
| 16:16.27 | *** join/#asterisk-dev IgorG (n=IgorG@host-92-124-184-228.pppoe.omsknet.ru) |
| 16:21.27 | oej | We never touch video. We just pass it on, pass it on. |
| 16:21.37 | oej | That's not touching any patents, as far as I know |
| 16:21.46 | *** join/#asterisk-dev outtolunc (n=me@c-67-188-204-139.hsd1.ca.comcast.net) |
| 16:21.57 | kpfleming | correct |
| 16:22.05 | kpfleming | the patents cover encoding and decoding, not transport |
| 16:22.10 | kpfleming | transport is format agnostic |
| 16:22.36 | oej | But if we start producing videos, like converting pngs to 264, then we propably have to move to another country. |
| 16:23.05 | Corydon76-dig | Or transcoding videos |
| 16:23.23 | Corydon76-dig | transcoding video would be killer |
| 16:23.35 | eliel | for that we will need new hardware thought he |
| 16:23.46 | jtodd | The specter of GPU processing raises its head again. |
| 16:24.09 | jtodd | Hopefully Joe Benden will post some discussions re: GPU transcoding next week as a summary of some offline discussions we've had. |
| 16:24.35 | jtodd | Summary: Audio transcoding on GPU is probably not practical without extensive work. Video: probably much more likely. |
| 16:25.20 | oej | Yes, that's what I've heard too. met some guys working on open GPU something. |
| 16:25.29 | jtodd | Tesla cards from NVIDIA with 350(?) gflops for $1400. |
| 16:25.32 | oej | Weird open soruce people |
| 16:25.43 | oej | Cool site of the week http://goingtorain.com/ |
| 16:25.52 | oej | Especially good in Seattle and Stockholm |
| 16:26.23 | lmadsen | neat! |
| 16:26.25 | kpfleming | is that just a page that says 'YES' in large friendly letters? |
| 16:26.27 | lmadsen | not going to rain in toronto today |
| 16:26.35 | lmadsen | says 'no' here |
| 16:26.50 | file | maybe here! |
| 16:26.57 | Qwell | oej: http://isitchristmas.com/ |
| 16:27.20 | oej | Even better! |
| 16:27.21 | Qwell | http://www.hasthelargehadroncolliderdestroyedtheworldyet.com/ |
| 16:27.54 | jtodd | I was about to post a sarcastic comment like "http://canihaveapony.com" but apparently all possible domain names are taken, even the most unlikely ones. |
| 16:28.48 | Corydon76-dig | jtodd: you don't think creatively enough: http://canihazap0wnie.com |
| 16:29.30 | jtodd | Corydon76-dig: Good point. I keep forgetting to s/o/0/ for all my domain names. |
| 16:30.04 | Corydon76-dig | p0wned! |
| 16:30.31 | jtodd | So a quick and totally informal survey: Is there anyone here that has used MRCP? (first, I'll count responses, and then ask more questions if !=0) |
| 16:30.45 | lmadsen | wonders what MRCP is :) |
| 16:30.51 | jtodd | OK, that's -1. |
| 16:30.53 | lmadsen | lol |
| 16:30.56 | Qwell | jtodd: http://www.hastanybodyusedmrcphere.com/ |
| 16:31.01 | Qwell | NO. |
| 16:31.10 | jtodd | So at least my question has resulted in a response that is !=0 thus far. |
| 16:31.18 | Qwell | lmadsen: d'oh |
| 16:31.34 | kpfleming | jtodd: -1 |
| 16:31.36 | lmadsen | s/!=0/>0/ |
| 16:31.55 | file | jtodd: depends on your definition of used! I'm sure a system I have called into has used it but personally nyet |
| 16:32.08 | kpfleming | oh, you are in pedantic mode today |
| 16:32.30 | jtodd | file: I'll smack you with a haddock later. |
| 16:33.45 | Corydon76-dig | chattr file -pedantic |
| 16:33.57 | file | moo |
| 16:36.59 | kpfleming | Corydon76-dig: +10 points for using 'chattr' in IRC |
| 16:38.22 | Corydon76-dig | Heh |
| 16:41.32 | Juggie | mrcp is a voice rec protocol isnt it. |
| 16:41.52 | Juggie | (lmadsen!) |
| 16:54.24 | kpfleming | Corydon76-dig: i have a test box here in my office running Ubuntu Hardy that generates the 'not thread safe' warning every time asterisk 1.4 is run |
| 16:54.31 | kpfleming | would you like access to it? |
| 16:55.09 | lmadsen | (Juggie!) |
| 16:55.40 | Juggie | did you see the game last night? (continue chat in #*-doc) |
| 16:58.01 | putnopvut | kpfleming: interesting. did you apt-get install build-essential on that or did you individually obtain the necessary prereqs for Asterisk to build? |
| 16:58.35 | kpfleming | build-essential |
| 16:58.42 | kpfleming | plus lots of other stuff |
| 16:59.11 | mvanbaak | aptitude purge ubuntu-nothreads |
| 16:59.12 | mvanbaak | ;) |
| 16:59.52 | kpfleming | no such package found |
| 16:59.53 | kpfleming | :-) |
| 16:59.56 | putnopvut | dang |
| 17:00.54 | mvanbaak | btw, is it correct that when I compile asterisk with DONT_OPTIMIZE I now get [CPP] <some_file.c> -> <some_file.i> |
| 17:00.58 | mvanbaak | ? |
| 17:00.58 | jtodd | FWIW, there's the voip-users-conference starting right now. |
| 17:00.58 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.10.119) |
| 17:01.02 | mvanbaak | cant recall it did that before |
| 17:02.01 | kpfleming | mvanbaak: yes, i committed changed to do that |
| 17:02.05 | mvanbaak | and a second line: [CCi] <some_file.i> -> <some_file.o> and a third line: [LD] <some_file.o> -> <some_file.so> |
| 17:02.07 | kpfleming | i think i announced them on the dev list as well |
| 17:02.17 | mvanbaak | hhmm, must have missed them |
| 17:02.21 | kpfleming | that only happens when both dev-mode and DONT_OPTIMIZE are on |
| 17:02.27 | mvanbaak | indeed |
| 17:02.41 | mvanbaak | does it need more space on the HD to compile asterisk ? |
| 17:02.45 | kpfleming | see the list post and the commit message for the rational |
| 17:02.49 | kpfleming | a slight amount |
| 17:02.52 | kpfleming | but the benefits are worth it |
| 17:03.00 | mvanbaak | ah |
| 17:03.48 | mvanbaak | then I just found the reason why I cant finish building asterisk on my CF card powered box anymore :) it runs out of space right after the codecs |
| 17:04.12 | mvanbaak | it was a close call before the last svn up, but now it wotn finish |
| 17:04.24 | mvanbaak | <--- removes devmode and dontoptimize |
| 17:04.31 | kpfleming | sory |
| 17:04.42 | kpfleming | get a bigger CF card, they are cheap now :-) |
| 17:05.10 | kpfleming | if you aren't running gdb on that box, then turn off dont-optimize |
| 17:05.19 | kpfleming | that's the only reason to turn it on, but dev-mode has other uses |
| 17:05.40 | *** join/#asterisk-dev rukoiatka (n=alfa@nat/digium/x-7d3ffb79bdb64f45) |
| 17:37.47 | *** join/#asterisk-dev M1s3ry (n=M1s3ry@nat/digium/x-92e23c614d92766a) |
| 17:58.26 | eliel | mvanbaak: autocomplete is ready (i think) i have tested the last patch and is working fine. |
| 17:58.34 | eliel | M13969 |
| 17:58.36 | MuffinMan | [ready for testing] [Asterisk] General 0013969: [patch] Need tab completion of "core set debug X filename.c" reported by jtodd (Karma: +26.75) http://bugs.digium.com/view.php?id=13969 |
| 17:59.53 | eliel | also with this commit there is a new janitor to start autocompleting numbers |
| 18:03.53 | bkruse | M14012 |
| 18:03.55 | MuffinMan | [new] [Asterisk] PBX/General 0014012: Channel "hangs" reported by dveiga (Karma: neutral) http://bugs.digium.com/view.php?id=14012 |
| 18:04.23 | bkruse | This bug also exists in 1.4 as well, it seems. |
| 18:08.12 | putnopvut | Interesting. How do you actually trigger that behavior? |
| 18:11.15 | putnopvut | But I agree with the patch. I'd also clarify in the doxygen above collect_digits that the waittime is in milliseconds. |
| 18:14.59 | bkruse | putnopvut: I am trying to reproduce now... |
| 18:16.05 | bkruse | putnopvut: Happy BDAY :X |
| 18:18.20 | bkruse | putnopvut: I really have no idea how that is called....looking through the code |
| 18:20.56 | Corydon76-dig | kpfleming: Yes, could you get me access to that machine? |
| 18:22.46 | *** join/#asterisk-dev chadcrew (n=chadcrew@pool-71-174-182-10.bstnma.east.verizon.net) |
| 18:25.12 | *** join/#asterisk-dev Deeewayne (n=Deeewayn@nat/digium/x-4c8f970a9e5c7a94) |
| 18:25.12 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 18:30.39 | *** join/#asterisk-dev qdk (n=qdk@212.27.19.21.bredband.3.dk) |
| 18:43.17 | *** join/#asterisk-dev moy (n=moy@189.169.89.20) |
| 19:02.53 | kpfleming | Corydon76-dig: see jabber pm |
| 19:51.05 | *** join/#asterisk-dev flujan (n=flujan@internet.nube.com.br) |
| 19:55.02 | lmadsen | tzafrir_laptop: I noticed you created a new branch today in regards to sysfs stuff. Does that have anything to do with 7613? |
| 19:55.04 | lmadsen | M7613 |
| 19:55.06 | MuffinMan | [feedback] [DAHDI-linux] zaptel (the module) 0007613: [patch][post 1.4] automatic configuration for analog channels reported by tzafrir (Karma: +112.25) http://bugs.digium.com/view.php?id=7613 |
| 19:56.04 | tzafrir_laptop | lmadsen, basically, yes |
| 19:56.40 | lmadsen | tzafrir_laptop: based on your response, I assume it has to do with something more generic, but that issue could be resolved with your branch? |
| 19:57.16 | tzafrir_laptop | Yes. Though I don't see this branch merged before 2.1.0 is released |
| 19:57.54 | lmadsen | np. I'm just looking at the oldest bugs on the tracker right now to see their status, and that happened to jump out at me since I saw a branch you created in re: to sysfs |
| 19:58.08 | lmadsen | just happy to know something may happen with it :) |
| 20:16.40 | *** part/#asterisk-dev flujan (n=flujan@internet.nube.com.br) |
| 20:21.58 | lmadsen | russellb: are build issues (for freebsd) to be fixed in 1.2? |
| 20:24.31 | russellb | eh, depends what they are |
| 20:24.34 | russellb | if it's just warnings, no |
| 20:24.44 | seanbright | uint vs. unsigned int |
| 20:25.22 | russellb | for something that trivial, if it makes it so it will build for people, I'm ok with it |
| 20:25.32 | lmadsen | russellb: okie, thanks for the info |
| 20:25.38 | Qwell | why are we even using uint anywhere? |
| 20:25.39 | lmadsen | seanbright: you wanna take that one? I will reopen |
| 20:25.51 | seanbright | lmadsen: sure |
| 20:25.55 | seanbright | it could take me hours though |
| 20:26.01 | Qwell | if you want it to be an exact size, use uint32_t |
| 20:26.10 | russellb | seanbright: seriously? |
| 20:26.19 | seanbright | russellb: no? |
| 20:26.26 | russellb | k. |
| 20:26.29 | seanbright | heh |
| 20:26.35 | lmadsen | shakes seanbright |
| 20:26.42 | lmadsen | seanbright: opened and assigned |
| 20:26.47 | kpfleming | yeah, uint disappeared recently for some reason |
| 20:26.54 | kpfleming | saw that in some non-asterisk code as well |
| 20:27.03 | lmadsen | causes seanbright to have shaken baby syndrome |
| 20:27.14 | seanbright | enough with the shaking |
| 20:27.20 | seanbright | i just had chipotle |
| 20:27.32 | lmadsen | I will be in the other room then |
| 20:27.37 | seanbright | k |
| 20:28.35 | seanbright | wow |
| 20:28.54 | seanbright | forgot that 1.2 doesn't use the autotools |
| 20:30.16 | eliel | mmm, so, we are going to maintain 1.2 forever, every time something change in some OS... |
| 20:31.04 | eliel | -1 |
| 20:31.13 | seanbright | well let's hope that 'unsigned int' isn't deprecated :) |
| 20:35.19 | eliel | he |
| 20:44.49 | kpfleming | seanbright: we're switching to quantumsigned int |
| 20:47.14 | seanbright | so here's the thing... i can't fix this |
| 20:47.56 | seanbright | (don't have commit access to 1.3) |
| 20:48.00 | seanbright | (1.2 either) |
| 20:48.50 | kpfleming | bummer |
| 20:48.56 | seanbright | i know |
| 20:48.58 | kpfleming | we can fix that |
| 20:49.00 | kpfleming | hang on |
| 20:49.02 | seanbright | super |
| 20:49.14 | seanbright | just give me root access on that box |
| 20:49.16 | seanbright | and vpn access |
| 20:49.17 | seanbright | kthx |
| 20:49.20 | seanbright | heh |
| 20:49.44 | kpfleming | you are now the only non-digium person with commit access to asterisk/branches-1.2 |
| 20:50.11 | russellb | don't screw it up! |
| 20:50.11 | seanbright | wow |
| 20:50.14 | russellb | :-p |
| 20:50.14 | seanbright | svn delete |
| 20:50.15 | seanbright | heh |
| 20:50.26 | kpfleming | it's all revertable |
| 20:50.33 | seanbright | it's like my birthday |
| 20:50.39 | seanbright | only a month too soon |
| 20:54.04 | seanbright | and of course merge24 is broken |
| 20:58.06 | codefreeze-lap | Hmm, the CDR design thread sparked a pretty flame war over top posting! whew! |
| 20:58.30 | codefreeze-lap | uh, /pretty/pretty healthy/... |
| 21:06.15 | Corydon76-dig | I hardly think that qualifies as a flame war |
| 21:06.28 | putnopvut | a flame skirmish? |
| 21:07.57 | seanbright | fisticuff |
| 21:08.16 | kpfleming | kerfluffle |
| 21:17.06 | tzanger | heh |
| 21:17.13 | tzanger | if only that were all that there was to complain about |
| 21:18.21 | *** join/#asterisk-dev sprite-- (n=sprite@12.228.1.97) |
| 21:20.22 | sprite-- | Will Asterisk's devs implement functionality if paid? |
| 21:20.40 | Juggie | yes, contact sales@digium.com |
| 21:20.55 | seanbright | well |
| 21:21.04 | seanbright | no need to go straight to them... :) |
| 21:21.17 | Juggie | seanbright may take your money too :P |
| 21:21.29 | seanbright | i would happily do so |
| 21:21.55 | seanbright | esp. if it's easy and i can over-estimate and under-deliver |
| 21:22.13 | russellb | We are not doing custom development work |
| 21:22.26 | russellb | You can contact sales@digium.com if you'd like, and they'll put you in touch with some of our official development partners |
| 21:22.40 | Juggie | russellb, digium doesnt do custom dev anymore? |
| 21:22.42 | russellb | Also, as seanbright has pointed out, there are some folks in here that are interested in such work, as well |
| 21:22.44 | russellb | no |
| 21:22.54 | seanbright | how do i get on the official development partners list? |
| 21:23.02 | seanbright | gotta grease you? |
| 21:23.04 | seanbright | heh |
| 21:23.51 | Juggie | so i get a new machine @ work |
| 21:23.57 | Juggie | and its a Core2Duo 2.5ghz |
| 21:24.00 | Juggie | which is great |
| 21:24.07 | russellb | we have a partner program of some sort |
| 21:24.07 | russellb | I don't know the details |
| 21:24.09 | russellb | you'd have to contact the sales folks |
| 21:24.13 | Juggie | 4gigs of ram and an EIGHTY gig hdd |
| 21:24.13 | seanbright | meh |
| 21:24.14 | kpfleming | contact our services department, rod montgomery |
| 21:24.18 | seanbright | ok |
| 21:24.26 | Juggie | talk about lopsided. |
| 21:24.28 | sprite-- | russellb: Thanks :) |
| 21:25.06 | Juggie | russellb, how long have you been not doing custom dev. |
| 21:25.20 | russellb | seanbright is a very active member of the Asterisk development community, so I'd give him a chance :) |
| 21:25.24 | russellb | Juggie: *shrugs* |
| 21:25.34 | sprite-- | russellb: I have C/C++ experience just no linux dev experience so I'm going to attempt it myself first. Basically what I need is a non-locking bridge functionality. Like bridge a channel and instead of locking in bridge function it continues in dialplan and the ability to issue an unbridge at any time. Do you see any obvious obstacles to this? |
| 21:25.59 | russellb | That's going to be darn near impossible |
| 21:26.04 | seanbright | i'll pass on this one |
| 21:26.05 | seanbright | heh |
| 21:26.28 | Juggie | sprite--, what you probally want to do is kick the user out of the bridge using AMI |
| 21:27.38 | sprite-- | Well I need my dialplan to continue after the convo is bridged, but I'm not sure if it's even possible with the architecture of Asterisk. Like what if I have 2 bridged channels and I want to play a soundclip? |
| 21:28.12 | Juggie | use meetme to do the bridge and join a local channel into the meetme play your clip and leave. |
| 21:28.16 | russellb | There are ways to do it today, but should probably be discussed in #asterisk |
| 21:28.25 | russellb | yeah, what Juggie said is a way to do that today |
| 21:28.33 | Juggie | i did that on 1.0 so i'm sure it still works. |
| 21:29.16 | kpfleming | or your local channel could run AGI or ExternalIVR to stay alive and continue running logic to decide what to do |
| 21:29.29 | russellb | kpfleming: nice. |
| 21:29.35 | sprite-- | The problem with MeetMe is that it's not very resource effective though. I need a bunch of current convos. I suppose Asterisk in a cluster with MeetMe rooms could work but it seems like there has to be a better way. |
| 21:29.37 | Juggie | right, your local channel could be the brains of your bridge |
| 21:29.58 | Juggie | sprite--, file was working on a new bridge branch |
| 21:30.07 | kpfleming | you don't have any choice |
| 21:30.20 | russellb | that's the only want to do what you want today |
| 21:30.22 | kpfleming | if you want the two parties connected together *and* you want to play sounds to them, you have to conference them |
| 21:30.30 | Juggie | you can look there for new functionaltiy i'm not sure what the status is, i'm out of the loop. |
| 21:30.56 | kpfleming | it wouldn't matter, because playing sounds to only one party would necessitate (temporarily) breaking the bridge anyway |
| 21:31.39 | Juggie | didnt file's branch facilitate multi party bridges? i'll have to dig up the branch |
| 21:31.42 | sprite-- | Ok cool. So conference, 2 channels + 1 local controller channel seems to be what I want to do. I was going to use Adhearsion to intergrate it with the webfrontend running RoR. |
| 21:31.59 | kpfleming | Juggie: a multi-party bridge is a conference |
| 21:32.33 | Juggie | right... i just thought using his api there may be a way to play audio in it without officially calling it a conference room |
| 21:32.44 | sprite-- | I should be able to do 30 of these 3 way conferences (2 parties + 1 controller channel) on one modern machine or is that over ambitious? |
| 21:32.45 | kpfleming | you can call it whatever you want |
| 21:32.52 | kpfleming | sprite--: that's a piece of cake |
| 21:33.22 | Juggie | sprite--, as kpfleming said so long as your not transcoding thats easy |
| 21:33.35 | sprite-- | Ok cool, no worries then :) |
| 21:33.36 | sprite-- | Thanks |
| 21:34.17 | kpfleming | even with transcoding... 60 channels transcoded to/from g.729 does not require a terribly beefy machine |
| 21:34.22 | kpfleming | the conference mixing itself is cheap |
| 21:34.30 | kpfleming | actually, you have to transcode anyway to conference |
| 21:34.52 | sprite-- | I read somewhere something that said MeetMe uses one linked list for all channels and it requires to get locked everytime someone joins or leaves and that it wouldn't handle more than 15 conferences or so. |
| 21:35.53 | kpfleming | you can read lots of things lots of places |
| 21:36.06 | kpfleming | whether they were ever true, or continue to be true, is debatable :-) |
| 21:36.21 | Juggie | even if that were true |
| 21:37.04 | Juggie | i dont see how like lets say, 30 rooms w/ even 5 people each |
| 21:37.17 | sprite-- | Hardware is cheap anyways, I'll just plan on clustering. It seems MeetMe will do what I need. |
| 21:37.23 | Juggie | could possibly generate enough locking/unlocking |
| 21:37.30 | Juggie | people dont usually leave/part that much :) |
| 21:37.41 | kpfleming | yes, it depends on the call length as well |
| 21:57.18 | *** join/#asterisk-dev qdk (n=qdk@79.138.254.85.bredband.3.dk) |
| 22:23.03 | *** join/#asterisk-dev mbranca (n=matteo@93-62-230-243.ip24.fastwebnet.it) |
| 22:32.32 | *** join/#asterisk-dev DarkRift (n=dark@65.92.170.174) |
| 22:47.36 | *** part/#asterisk-dev Deeewayne (n=Deeewayn@nat/digium/x-4c8f970a9e5c7a94) |
| 23:08.39 | lmadsen | jsmith-away: wb! |