| 01:13.25 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 01:13.26 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 01:45.34 | *** part/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 03:59.36 | *** join/#asterisk-dev Deeewayne (~dwayne@c-76-29-230-45.hsd1.al.comcast.net) |
| 03:59.36 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 05:22.49 | *** join/#asterisk-dev oej (~olle@h87-96-134-129.dynamic.se.alltele.net) |
| 05:22.49 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:08.16 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 06:30.42 | *** join/#asterisk-dev oej (~olle@h87-96-134-129.dynamic.se.alltele.net) |
| 06:30.43 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:51.37 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:3c77:f7ed:9ed7:d63e) |
| 07:26.37 | *** join/#asterisk-dev oej (~olle@h87-96-134-129.dynamic.se.alltele.net) |
| 07:26.37 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:03.15 | *** join/#asterisk-dev oej (~olle@h87-96-134-129.dynamic.se.alltele.net) |
| 08:03.15 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:05.01 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 08:05.02 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 08:19.08 | *** join/#asterisk-dev oej (~olle@h87-96-134-129.dynamic.se.alltele.net) |
| 08:19.09 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:30.00 | *** join/#asterisk-dev hehol (~hehol@217.9.101.222) |
| 08:33.21 | *** join/#asterisk-dev oej (~olle@h87-96-134-129.dynamic.se.alltele.net) |
| 08:33.21 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:47.40 | oej | Morning folks |
| 08:48.02 | WIMPy | Good morning |
| 09:10.47 | *** join/#asterisk-dev zerohalo (~zerohalo@74.61.196.236) |
| 10:26.17 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:5e0:adb4:9a4c:4265) |
| 10:50.17 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 10:50.18 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 10:59.18 | *** join/#asterisk-dev ccesario (~ccesario@189.29.37.189) |
| 11:59.53 | *** join/#asterisk-dev F|shie (~chatzilla@39.47.7.106) |
| 12:10.18 | *** join/#asterisk-dev F|shie (~chatzilla@39.47.84.180) |
| 12:11.59 | F|shie | hello all, im trying to follow this tutorial, http://ofps.oreilly.com/titles/9781449303822/c03-AudioManipulation_id302347.html#TriggeringAudioViaDTMF , but instead of playing audio into channel i want to record the audio, on the audio extension, is it possible to do so? |
| 12:17.43 | F|shie | any1 have an idea? =/ |
| 13:02.31 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-chcrkpgsdyxatsue) |
| 13:02.31 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:03.45 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-fxhrnnlsojuhboly) |
| 13:05.45 | *** join/#asterisk-dev F|shie (~chatzilla@39.47.242.230) |
| 13:40.06 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 13:50.16 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:50.16 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:00.39 | *** join/#asterisk-dev zerohalo (~zerohalo@74-94-141-204-ma.hfc.comcastbusiness.net) |
| 14:01.43 | *** join/#asterisk-dev hehol (~hehol@217.9.101.222) |
| 14:12.33 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 14:12.33 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:13.31 | Kobaz | i really hate deadlocks |
| 14:16.25 | Marquis42 | Awww... But they're so fun! ;) |
| 14:17.33 | Kobaz | yes yes |
| 14:18.55 | Kobaz | asterisk needs better-better backtraces |
| 14:19.11 | Kobaz | is the new backtrace stuff in 1.8 or 1.10? |
| 14:20.59 | putnopvut | Kobaz: it's in 1.8 |
| 14:21.18 | putnopvut | I assume you're talking about the "BETTER_BACKTRACES" menuselect option and not something even newer than that. |
| 14:22.05 | Kobaz | you know, i thought it wa son by default |
| 14:22.07 | Kobaz | lemme see |
| 14:22.34 | Kobaz | oh no |
| 14:22.36 | Kobaz | it's not enabled |
| 14:22.41 | Kobaz | that's why the backtraces look the same |
| 14:24.47 | Kobaz | i kind of thought something was missin |
| 14:24.49 | Kobaz | g |
| 14:24.52 | leifmadsen | Kobaz: ya not enabled by default, at least not in 1.8 |
| 14:24.55 | Kobaz | Now provides excellent information, including file, line, and function name. |
| 14:24.57 | leifmadsen | might be in 10... ? |
| 14:24.58 | Kobaz | ooooOoOOO |
| 14:25.03 | Kobaz | holy crap that's amazing |
| 14:25.12 | leifmadsen | Kobaz: thank Corydon76-home :) |
| 14:25.24 | leifmadsen | and whoever else reviewed it |
| 14:26.27 | Kobaz | yeah. this is going to make debugging deadlocks a bit easier |
| 14:27.04 | putnopvut | Yes, better backtraces is pretty badass |
| 14:27.36 | Kobaz | iw as looking foward to the better backtraces and then i kind of forgot about it because it looked the same |
| 14:27.51 | Kobaz | didn't realize it's been off |
| 14:29.54 | Kobaz | it's been long enough |
| 14:33.04 | Kobaz | god damnit |
| 14:33.46 | Kobaz | i guess i will get to use the better backtraces today |
| 14:33.49 | Kobaz | another deadlock |
| 14:35.07 | Kobaz | i need to rewrite some crap, this is going to suc |
| 14:42.42 | Kobaz | oh fuck |
| 14:42.45 | Kobaz | man |
| 14:43.00 | Kobaz | crash in core show locks with better backtraces enabled |
| 14:43.54 | mjordan | that's suboptimal |
| 14:45.14 | Kobaz | especially when it just dropped 50 calls |
| 14:46.45 | mjordan | :-( did you get a core file at least? |
| 14:47.09 | Kobaz | yeah |
| 14:49.42 | Kobaz | https://issues.asterisk.org/jira/browse/ASTERISK-19815 |
| 14:52.07 | Kobaz | if (!file) { file = ""; } |
| 14:52.11 | Kobaz | that's my fix for now |
| 14:52.20 | Kobaz | right after if (!bfd_find_nearest_line(bfdobj, section, syms, offset - section->vma, &file, &func, &line)) { |
| 14:52.23 | Kobaz | fule is null |
| 14:52.27 | Kobaz | file, rather |
| 14:53.34 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:53.34 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 14:57.04 | *** join/#asterisk-dev zerohalo (~zerohalo@67.103.230.22) |
| 14:58.18 | mjordan | Kobaz: looks like func being an empty string / NULL will be handled |
| 14:58.26 | Kobaz | nope |
| 14:58.44 | Kobaz | if ((lastslash = strrchr(file, '/'))) { |
| 14:58.55 | mjordan | func, not file :-) |
| 14:59.02 | Kobaz | that crashes on nul |
| 14:59.08 | Kobaz | oh |
| 14:59.09 | Kobaz | right |
| 14:59.17 | Kobaz | doing like 50 things right now |
| 14:59.20 | mjordan | right, on the file parameter. I was looking at the others, to see if we accessed them as well |
| 14:59.24 | Kobaz | yeah |
| 14:59.25 | Kobaz | ah okay |
| 14:59.41 | file | is never NULL |
| 15:01.37 | Kobaz | prove it! |
| 15:01.53 | file | that's an awfully personal thing to do |
| 15:02.33 | Kobaz | hehe |
| 15:02.50 | Kobaz | wow |
| 15:03.06 | Kobaz | i've never gotten a 500 internal server error from asterisk on a sip call before |
| 15:03.14 | Kobaz | all kinds of new stuff today |
| 15:04.24 | Kobaz | i wonder why file would ever be null |
| 15:05.09 | mjordan | Kobaz: not sure, but we probably should sanitize whatever that call gives us regardless. |
| 15:05.34 | Kobaz | yeah |
| 15:05.44 | Kobaz | file: why are you null? |
| 15:05.50 | file | because I choose to be. |
| 15:06.34 | Kobaz | ah hah, i knew it |
| 15:06.52 | Kobaz | 2012-04-30 10:36 AM * file is never NULL |
| 15:07.20 | file | correct |
| 15:07.20 | file | I'm not NULL |
| 15:07.20 | file | I'm null |
| 15:11.17 | opticron | I think file is really None in disguise |
| 15:12.24 | Kobaz | so i'll go and commit that fix then |
| 15:12.34 | Qwell | opticron: I'm gonna go with NaN |
| 15:12.42 | Kobaz | needs to go into 1.8 and 1.10 and trunk |
| 15:24.23 | *** join/#asterisk-dev bklang (~bklang@2001:470:8:5de:225:ff:fe49:f8cd) |
| 15:25.01 | pabelanger | Kobaz: s/1.10/10/ |
| 15:25.21 | Kobaz | yeha one of those |
| 15:30.24 | *** join/#asterisk-dev oej (~olle@h87-96-134-129.dynamic.se.alltele.net) |
| 15:30.24 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 15:41.36 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 15:53.44 | kpfleming | Kobaz: we have an S_OR macro to do what you did logger.c. just a style point, though, no difference in code. |
| 15:55.51 | Kobaz | ah okay |
| 15:56.07 | Qwell | if he was setting it to anything other than "", it would be slightly different, because S_OR checks ast_strlen_zero |
| 15:57.58 | kpfleming | ahh, true |
| 16:47.14 | Kobaz | $ merge10trunk 364650 |
| 16:47.18 | Kobaz | svnmerge: no integration info available |
| 16:48.35 | Qwell | that's no good |
| 16:48.40 | Kobaz | nope |
| 16:48.56 | Qwell | checking |
| 16:49.07 | Qwell | the prop is set.. |
| 16:49.16 | Qwell | You sure you're in a trunk checkout? |
| 16:49.27 | Kobaz | URL: https://origsvn.digium.com/svn/asterisk/trunk |
| 16:49.32 | Kobaz | Repository Root: https://origsvn.digium.com/svn/asterisk |
| 16:49.35 | Qwell | any prop diff? |
| 16:49.46 | Kobaz | $ svn diff |
| 16:49.46 | Kobaz | $ |
| 16:50.14 | Qwell | worksforme O.o |
| 16:50.18 | Kobaz | aw |
| 16:50.43 | russellb | svn revert -R . |
| 16:50.50 | russellb | and then try again |
| 16:51.15 | Kobaz | no go |
| 16:51.36 | Qwell | update repotools, maybe? |
| 16:51.40 | russellb | svn pg branch-10-integrated ? |
| 16:51.42 | Kobaz | yeah, did that before |
| 16:51.43 | russellb | does it exist? |
| 16:51.47 | Qwell | russellb: -merged |
| 16:51.51 | russellb | yes that |
| 16:51.52 | russellb | :) |
| 16:51.53 | kpfleming | or 'svn pl .' |
| 16:52.06 | Kobaz | oh |
| 16:52.15 | Kobaz | you gotta 'make' also |
| 16:52.24 | Kobaz | after updating repotools |
| 16:52.27 | Kobaz | okay that's better |
| 16:54.03 | Kobaz | hmmm |
| 16:54.29 | Kobaz | i now have a property conflict on . |
| 16:54.39 | Qwell | yes that happens |
| 16:54.50 | kpfleming | it's documented on the wiki page, in fact |
| 16:54.53 | Kobaz | ah k |
| 16:55.00 | Qwell | it tried to bring over the 1.8 merge, and failed, because that prop is not in trunk |
| 16:55.46 | Kobaz | ah okay |
| 16:55.58 | Kobaz | i merged from 1.8 instead and its happier |
| 16:56.06 | Qwell | no, you want to merge from 10 |
| 16:56.19 | Qwell | You did it right the first time - the wiki says how to resolve the problem |
| 16:56.30 | Kobaz | oh okay |
| 16:56.35 | Kobaz | reverts |
| 16:56.44 | Kobaz | i was ognna look at the wiki but mthen you said the 1.8 merge |
| 16:59.53 | Kobaz | i found a thing on automerge conflicts, but it doesn't seem to be applicable |
| 17:00.36 | Kobaz | deverloper branches and branch mergnig, maybe this is |
| 17:11.21 | Kobaz | so i looked at those two pages, haven't found it yet |
| 17:12.22 | Qwell | subversion usage |
| 17:13.06 | Qwell | 2.3, big green box |
| 17:13.51 | Kobaz | hmm, green |
| 17:14.12 | Kobaz | 2.3 is branch merge orver |
| 17:14.31 | Kobaz | order.. yeah i'm familiar with that, that's what I did first and then got a prop conflict so i thought i did something wrote |
| 17:14.48 | Kobaz | i did 8to10 and now i'm doing 10totrunk |
| 17:16.02 | Kobaz | oh |
| 17:16.03 | Kobaz | svn resolved . |
| 17:16.24 | Kobaz | that's not a green box, that's blue with a green check icon |
| 17:30.46 | pabelanger | Kobaz: you need to update your local copy of the svnmerge script |
| 17:31.02 | pabelanger | To get the new message format stff |
| 17:31.05 | pabelanger | stuff* |
| 17:31.25 | pabelanger | <PROTECTED> |
| 17:31.30 | pabelanger | reads backscroll |
| 17:33.08 | Kobaz | yeah updating repotools was the first thing i did |
| 17:33.16 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189-25-40-55.user.veloxzone.com.br) |
| 17:48.28 | Qwell | Running tests for Asterisk 1.8.11.0 |
| 17:48.28 | Qwell | --> Cannot run test 'tests/apps/voicemail/leave_voicemail_nominal' |
| 17:48.29 | Qwell | --- --> Minimum Version: 1.8 (False) |
| 17:48.32 | Qwell | Am I doing something wrong? O.o |
| 17:48.39 | Qwell | 1.8.11.0 is definitely >> 1.8 |
| 17:49.39 | kpfleming | except for sufficiently large values of 1.8 |
| 17:49.40 | opticron | may have something to do with the recent version stuff going in to the testsuite to handle digiumphones releases and the like |
| 17:50.46 | Qwell | opticron: the test in version.py says OK |
| 17:50.58 | opticron | huh |
| 17:53.10 | Qwell | <PROTECTED> |
| 17:53.10 | Qwell | <PROTECTED> |
| 17:53.10 | Qwell | <PROTECTED> |
| 17:53.10 | Qwell | <PROTECTED> |
| 17:53.16 | Qwell | that fails |
| 17:53.42 | kpfleming | then whoever committed something that broke that unit test should be flogged. |
| 17:54.00 | Qwell | kpfleming: I just added that test. |
| 17:54.03 | Qwell | No such test existed.. |
| 17:54.08 | mjordan | hm. |
| 17:54.10 | kpfleming | oh |
| 17:54.20 | mjordan | That's because "1.8" is not a version that it will recognize. |
| 17:54.22 | kpfleming | well, good thing to have hadded it then |
| 17:54.27 | Qwell | mjordan: why the heck not? |
| 17:54.27 | mjordan | 1.8.0.0 is |
| 17:54.31 | mjordan | or 1.8.0 |
| 17:54.41 | Qwell | All the voicemail tests are minversion: 1.8 |
| 17:54.50 | kpfleming | so these are actualy versions, not API versions |
| 17:54.51 | mjordan | which implies an SVN branch of 1.8 |
| 17:54.56 | kpfleming | s/actualy/actual/ |
| 17:55.09 | mjordan | in which case, an SVN branch is always greater then a tag |
| 17:55.24 | Corydon76-home | mjordan: that seems to be a rather useless specification, then |
| 17:55.27 | kpfleming | notes that implicit behavior is terrible and should be avoided |
| 17:55.28 | Qwell | Then shouldn't the minversion be something like SVN-branch-1.8? |
| 17:55.42 | mjordan | Corydon76-home: not defending it, merely explaining |
| 17:55.45 | Corydon76-home | Or 1.8-branch ? |
| 17:56.04 | kpfleming | i can't see how that would be useful in any case, it's too non-specific |
| 17:56.10 | mjordan | no argument here. |
| 17:56.27 | mjordan | If someone would like to update the version parsing to change how it handles branches, I'd be glad to ship it. I'm not a fan. |
| 17:57.01 | kpfleming | wait |
| 17:57.22 | Qwell | I don't think the version parsing is wrong at all |
| 17:57.26 | kpfleming | we're not saying that turning a plain branch specification into '1.8.latest' is bad, but that shouldn't allowed as 'minversion' or similar in the tests |
| 17:59.04 | mjordan | so, my guess is that originally, the version.py module didn't really handle tags. The original way of treating 'minversion' was to prevent tests written from 1.8 from being executed against 1.4 or 1.6.2 - since everything was branches |
| 17:59.52 | mjordan | when tests against regressions were written, it became more important that tests have a minversion that was a specific revision of a branch, to prevent execution of the testsuite against older versions from running tests that would fail |
| 18:01.01 | kpfleming | i think it's reasonable that test specifications would only be allowed to include actual full version numbers, not ranges |
| 18:01.41 | mjordan | Which can be done - but then the minversion: should be a tag. |
| 18:01.48 | kpfleming | correct |
| 18:01.56 | kpfleming | that was what i was saying, in a different way |
| 18:02.23 | mjordan | 1.8 is not a tag. Its not actually a branch either, that should be SVN-branch-1.8-rXXXXXX |
| 18:02.35 | kpfleming | and if someone checkouts a non-current revision of the relevant branch, it's possible that tests will fail because the code is not new enough. no big loss. |
| 18:03.19 | kpfleming | well, if you want to get into including revision numbers, sure. but that complicates things, because now minversion would have to be "1.8.11.0 OR SVN-branch-1.8-rXXXXXX" |
| 18:03.37 | mjordan | it actually already does parse and understand SVN revision numbers |
| 18:03.39 | mjordan | for better or worse. |
| 18:04.02 | kpfleming | but we don't have conjuctive or disjunctive logic for specifying version matches |
| 18:04.05 | Qwell | mjordan: yes, but how is the testsuite to know that 1.8.11.0 is greater than SVN-branch-1.8-r300000 |
| 18:04.13 | mjordan | Qwell: it doesn't |
| 18:04.31 | mjordan | it assumes that any SVN branch is greater then any tag of that branch |
| 18:04.43 | mjordan | (again, not defending the current implementation) |
| 18:04.58 | kpfleming | so, as the risk of trying to make progress, instead of hacking on the code all over again, why don't we create a wiki page where we *design* the version specification/matching behavior, and then we can code to that? |
| 18:05.19 | mjordan | no objections here. I'd love to see that module be redone. |
| 18:05.34 | kpfleming | most likely all the tests will have to be edited as well, but that's tolerable. |
| 18:09.04 | kpfleming | since this is all python, there should be a relatively easy way to be able to use 'expressions' for version matching |
| 18:09.31 | kpfleming | although the remaining LUA tests are going to get to the point where they will never get run... |
| 18:10.53 | mjordan | kpfleming: the LUA tests have their own way of doing versioning. |
| 18:11.02 | kpfleming | right, but they aren't part of this party |
| 18:11.08 | kpfleming | as long as they don't get broken, though |
| 18:40.11 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@bzq-218-155-147.cablep.bezeqint.net) |
| 18:40.11 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 18:56.38 | pabelanger | Qwell: you are comparing a branch to a tag. That will fail |
| 18:57.04 | Qwell | correct, which means minversion: 1.8 is wrong, which is used on like every test |
| 18:57.23 | kpfleming | right. as i said, tests should not be able to specify branches, ever. |
| 18:57.36 | Qwell | I'm going to sed the crap out of the tree |
| 18:57.38 | kpfleming | the 'version under test' can be a branch, though. |
| 18:57.48 | pabelanger | Right, minversion should be removed and use the skip: property |
| 18:58.04 | pabelanger | at least that is how I envisioned it |
| 18:58.49 | mjordan | I disagree with that. |
| 18:59.40 | mjordan | the minversion can be a tag version, which can be the first version in a particular release branch, if that test supports being run on every release of that branch. |
| 19:00.00 | kpfleming | change that first 'can' to 'must' for now, at least |
| 19:00.03 | mjordan | If a test gets added for all releases of Asterisk 10, you wouldn't want to put a 'skip:' for every release of Asterisk 1.8 in there |
| 19:02.04 | pabelanger | the issue is, checking a test against a branch, also has to include a revision. Where a tag is more specific. So, yes, minversion should be only used for tags, not branches\ |
| 19:02.31 | pabelanger | which causes a problem is you run automate tests against a branch |
| 19:02.38 | kpfleming | expression: (version >= 10.0) OR ((version >= 1.8.11.0) and (features INCLUDES digiumphones) |
| 19:02.47 | pabelanger | starting to go crazy with our versioning system for the testsuite |
| 19:03.31 | kpfleming | this is why i proposed writing it up on a wiki page earlier. right now a number of people have different ideas of how it should work, and the code can't meet all of those. |
| 19:04.17 | mjordan | pabelanger: kpfleming: qwell: ASTERISK-19818 |
| 19:04.34 | pabelanger | It would be good to check how other project handle there versioning of their testsuite too |
| 19:05.13 | kpfleming | mjordan: ok, so there's version matching, and then there's feature matching after/on top of that |
| 19:06.02 | pabelanger | kpfleming: Should JIRA still be prompting me to use a SSL cert? Because it is |
| 19:06.29 | pabelanger | and if I cancel it, I cannot login to JIRA |
| 19:06.48 | kpfleming | pabelanger: issues.asterisk.org always tells the browser that if the browser wants to supply a cert, it can. if the browser has no certs installed, the user won't see the request. |
| 19:07.30 | pabelanger | kpfleming: Right, however removing the SSL cert and trying to log into JIRA fails. |
| 19:07.37 | pabelanger | The only way I can access it is using the cert |
| 19:07.51 | kpfleming | then your account has not been properly modified. let me check it. |
| 19:08.27 | pabelanger | k |
| 19:08.38 | kpfleming | well, it has been properly modified. i don't know why it's failing. i'll have to look further. |
| 19:09.01 | russellb | maybe compare to mine, because i never had that problem ... |
| 19:09.28 | Qwell | russellb: You left before the cert change. leifmadsen, however.. |
| 19:09.29 | pabelanger | Ya, I always had JIRA issues, even when we first moved to the new system. serafie can confirm that |
| 19:09.42 | kpfleming | pabelanger: you had issues with everything :-) |
| 19:09.44 | russellb | Qwell: ah, k :) |
| 19:10.17 | kpfleming | pabelanger: what is your non-digium email address? |
| 19:10.30 | pabelanger | paul.belanger@polybeacon.com |
| 19:10.50 | Qwell | pabelanger: mind if I switch repotools authors file to use that, while we're at it? |
| 19:11.00 | pabelanger | Qwell: yes |
| 19:11.05 | Qwell | yes you mind? |
| 19:11.10 | pabelanger | Yes, DO IT! |
| 19:11.25 | kpfleming | pabelanger: ok, i've updated the database, i don't know how long JIRA will take to see the change, but i can watch for it and let you know when it should work again |
| 19:11.56 | pabelanger | k, I'll retry in a bit |
| 19:12.23 | kpfleming | please don't try before i tell you the change has taken effect |
| 19:12.30 | kpfleming | otherwise it won't be useful |
| 19:13.02 | kpfleming | file: so the ICE work you have documented on the wiki page is always between Asterisk and the remote endpoint, right? we're not trying to pass ICE candidates or other details between channels at this point? |
| 19:13.26 | file | kpfleming: correct |
| 19:13.48 | kpfleming | i'd suggest including that on the wiki, so that people don't misunderstand this and assume it applies to directmedia mode. |
| 19:16.07 | file | adds it as a note so it sticks out like... uh... yellow fruit |
| 19:16.45 | Qwell | file: like squash? |
| 19:17.07 | file | sure |
| 19:17.08 | kpfleming | file: are externip/localnet settings used at all when ICE/STURN/TURN are being used? i'd expect them to be unnecessary. |
| 19:17.27 | file | kpfleming, they are not used at all - completely independent |
| 19:17.48 | file | kpfleming, and I have pondered the idea of passing through ICE information but being a B2BUA complicates things a lot for that and makes it hard to do it properly |
| 19:18.01 | kpfleming | that's what i figured. so the new stuff would be the preferred mechanism for Asterisk 11 and later, but the old stuff will stay around for those who wish to use it. |
| 19:19.35 | file | if any of your endpoints don't support ICE then externip/localnet are relevant |
| 19:19.41 | kpfleming | sure |
| 19:19.56 | kpfleming | which right now will be most of them |
| 19:20.03 | file | aye |
| 19:22.21 | file | I wonder what hardphones support it... |
| 19:24.01 | kpfleming | bets that it is none |
| 19:24.46 | file | crazy talk |
| 19:29.59 | kpfleming | file: how many of them support T.38 V4 and SDPCapNeg? |
| 19:30.10 | file | ...none |
| 19:43.24 | leifmadsen | Qwell: if it isn't already can you update the repotools authors list for me as well? |
| 19:45.33 | Qwell | leifmadsen: to what? |
| 19:45.41 | leifmadsen | leif@leifmadsen.com |
| 19:47.57 | *** join/#asterisk-dev SuD (~alex@90.175.32.209) |
| 19:47.59 | *** part/#asterisk-dev SuD (~alex@90.175.32.209) |
| 19:58.34 | leifmadsen | Qwell: thaks! |
| 19:58.36 | leifmadsen | thanks too |
| 20:05.54 | *** join/#asterisk-dev yetanotheruser (~user@p4FDC1FE7.dip.t-dialin.net) |
| 20:06.35 | kpfleming | pabelanger: the email address change has taken effect in JIRA. |
| 20:06.41 | kpfleming | you can try logging in again. |
| 20:07.35 | pabelanger | kpfleming: success |
| 20:07.52 | kpfleming | ok. serafie: it appears that him still having an @digium.com email address was the culprit. |
| 20:08.16 | serafie | OK. |
| 20:08.58 | kpfleming | at least, that's the only thing that I changed :-) |
| 20:53.56 | Qwell | kpfleming: I'm having an issue with AST_MODFLAG_GLOBAL_SYMBOLS, and I'm not really sure what to do about it. |
| 20:54.31 | russellb | i got 99 problems, but global symbols ain't one |
| 20:54.55 | Qwell | basically, that's set on a module, but that module needs format_* to be loaded first. All of the load order stuff is correct, but the modules are loaded in 2 passes - the first pass gets all the GLOBAL_SYMBOLS modules |
| 20:55.45 | russellb | so maybe the first pass should be removed in favor of load order being specified as needed |
| 20:56.17 | Qwell | I don't know what weird side-effects there might be from that. I expect it's done for a pretty good reason. |
| 20:56.23 | russellb | or load priority |
| 20:56.25 | russellb | whatever it is |
| 20:56.48 | russellb | well, i'm thinking that first pass was before there was a generic load priority mechanism |
| 20:56.55 | russellb | and in general, it's what you want |
| 20:56.56 | Qwell | likely so |
| 20:57.00 | russellb | you just hit a case where it doesn't work |
| 20:59.23 | Qwell | That would be a hell of a change for 1.8/10. |
| 21:00.04 | russellb | would need some serious vetting |
| 21:09.12 | Qwell | maybe not... |
| 21:16.56 | *** join/#asterisk-dev Agro (~Agro@108-79-20-223.lightspeed.hstntx.sbcglobal.net) |
| 21:17.41 | Agro | Does an ast_frame represent a certain time frame of data? |
| 21:23.25 | russellb | sort of, sometimes :-) |
| 21:23.42 | russellb | there are different types of frames, some signaling, some media ... |
| 21:23.58 | Agro | Oh... |
| 21:24.01 | russellb | frames that have audio (AST_FRAME_VOICE IIRC) are usually 20 ms of audio, but not always, could be anything |
| 21:24.10 | Agro | Right |
| 21:24.19 | Agro | Could I detect a tone from a single ast_frame's data? |
| 21:24.28 | russellb | if it had enough data, sure |
| 21:24.40 | russellb | but usually it takes more than 20ms I think |
| 21:24.43 | Agro | o |
| 21:24.43 | russellb | (I'm not a DSP guy) |
| 21:25.07 | russellb | see tone detection in main/dsp.c |
| 21:25.42 | Agro | Yeah, I transferred all the functions I needed oevr |
| 21:25.47 | Agro | I can't tell where I'm getting an error |
| 21:26.04 | Agro | If you do know, this is the correct way to get data from an ast_frame, right? http://pastebin.com/xzvJQTYn |
| 21:26.17 | Agro | over a period of x seconds, of course |
| 21:26.49 | russellb | that's not quite right ... |
| 21:26.59 | russellb | couple of big issues: |
| 21:27.01 | Agro | ah, so thats where my error is... |
| 21:27.23 | russellb | 1) you shouldn't use wall time for how many ms you have processed. you should do that by the amount of data you process. |
| 21:27.49 | russellb | 2) your code is assuming there is one sample of audio per frame. it's usually quite a bit more than that. there is a samples field in the frame IIRC. |
| 21:28.06 | russellb | so you're saving off the first sample of each frame, and throwing away the other 159 or whatever |
| 21:28.13 | Agro | oh |
| 21:28.31 | Agro | ah, so I have to loop within that to get more data? |
| 21:28.50 | russellb | well, or just do a big memcpy from ast_frame->data.ptr |
| 21:28.53 | russellb | or whatever you want to do with it |
| 21:29.09 | Agro | i guess memcpy then. length is length of data, right? |
| 21:29.24 | russellb | i think so :) |
| 21:29.38 | Agro | ok, ill optimize the code |
| 21:29.42 | russellb | good luck |
| 21:29.56 | Agro | oh, also, is there anyway to tell how much data you'll be inputting? |
| 21:30.07 | Agro | because im doing this: sampledata = (short*) malloc(10000 * sizeof(short)); |
| 21:30.07 | russellb | hm? |
| 21:30.30 | Corydon76-home | russellb: with 8000Hz audio, a 20ms frame should get you 160 samples, which should be enough to detect a tone |
| 21:30.32 | Agro | or should I allocate memory based on the next frame I'm reading |
| 21:30.34 | russellb | well, i don't know, you tell me, i don't know what you're doing |
| 21:30.51 | russellb | but you can always realloc() the buffer if you realize it's not big enough while processing |
| 21:30.55 | Agro | right |
| 21:31.33 | russellb | Corydon76-home: then maybe the code just requires more for debouncing purposes. *shrugs* |
| 21:32.27 | Corydon76-home | The shortest tone in the PSTN spec is 33ms |
| 21:32.43 | Agro | ah, for the time detection, theres a field delivery in ast_frame. i think thats what I need |
| 21:33.05 | Corydon76-home | (for payphones) |
| 21:34.20 | russellb | Agro: or see ast_samp2tv() |
| 21:34.20 | Agro | oh thanks |
| 21:34.20 | Corydon76-home | I was talking to someone recently who wanted to be able to detect payphone payment signals |
| 21:40.57 | Agro | i think this looks much better, of course without the time http://pastebin.com/R0jiZabX |
| 21:43.22 | Qwell | russellb: I *think* I've got something reasonable that won't change things (that were written correctly...) dramatically. |
| 21:43.43 | *** join/#asterisk-dev Kobaz (~kobaz@its.kobaz.net) |
| 21:44.18 | Qwell | currently, we run through the list twice, do all our dlopen magic, push stuff onto a heap, pop it off in order, and start the resource. so, that made 2 separate heaps, meaning 2 separate priorities |
| 21:44.33 | Qwell | short version: I combined the heaps |
| 21:45.36 | Qwell | 2 separate priority lists, I should say |
| 21:46.40 | Qwell | I think I'll post a proof of concept review tomorrow. |
| 21:47.06 | Qwell | Corydon76-home: you might actually be interested in scrollback as well |
| 21:47.17 | Corydon76-home | Qwell: having written the priority codes, I'd be interested in seeing it. It bugged me, too, but I didn't see a good way around it. |
| 21:47.39 | Qwell | well, here, I'll pastebin my idea code. obviously the code is crap, so ignore that part of it |
| 21:47.45 | Corydon76-home | But at the time, I didn't have any conflicts... |
| 21:48.34 | Qwell | super quick and dirty, seriously, the code is bad. I just wanted to make sure it did what I expected. http://pastebin.com/JwwxxSeB |
| 21:48.42 | Qwell | and it does appear to |
| 21:49.00 | Corydon76-home | I'm thinking about it, now, and if we have fine-grained enough priorities, we may not need a separate globals load list at all... |
| 21:49.38 | Qwell | well, the global list is there so that you can do the lazy loading |
| 21:50.03 | Qwell | exporting symbols, etc |
| 21:50.48 | Corydon76-home | Well, the primary reason is exporting symbols. But as long as the exported symbols are loaded before they are referenced, and that's what priority order is supposed to do... |
| 21:50.58 | Qwell | right, exactly |
| 21:51.12 | Qwell | well, mostly |
| 21:51.51 | Qwell | anyways, I do think we still need the two passes, it's just a matter of what is actually done on the pass, and what is done afterwards |
| 21:52.37 | Corydon76-home | The value you're passing to load_resource() is hokey |
| 21:52.44 | Qwell | yes I know |
| 21:52.56 | Qwell | I said it was dirty. :p |
| 21:53.50 | Qwell | I could've just duplicated that block and made it a static 0 or 1. I cheated. That certainly wouldn't get committed |
| 21:57.13 | Corydon76-home | What's the support status of RHEL 5? |
| 21:57.50 | Corydon76-home | If you look in load_dynamic_module(), there's a hack in there to code around a problem in that release series (to deal with a bug in gcc 4.1) |
| 21:59.29 | Corydon76-home | So that's probably a release to test with (CentOS 5) to verify that your change won't break anything. |
| 22:01.04 | Corydon76-home | The hack deals with the nonoptreq flag on modules, which will always be set on modules with global symbols, which is why it's relevant |
| 22:01.22 | Corydon76-home | s/always/only/ |
| 22:02.58 | Corydon76-home | Thank you, Red Hat. |
| 22:04.29 | Agro | is this valid code for ast_frame data getting, http://www.usfirst.org/roboticsprograms/frc/2012-kit-of-parts-technical-resources |
| 22:04.34 | Agro | ._. not htat |
| 22:04.40 | Agro | http://pastebin.com/R0jiZabX |
| 22:05.37 | Corydon76-home | Agro: basically, but you need an escape clause for when ast_read() returns NULL. |
| 22:05.43 | Agro | okay |
| 22:06.15 | Corydon76-home | If there isn't a frame to read, it'll return &ast_null_frame, which is a different beast. |
| 22:06.20 | Agro | :) |
| 22:07.02 | Agro | oh? asterisk is crashing when it reads the code... |
| 22:07.33 | Corydon76-home | Which code? |
| 22:07.42 | Agro | the code i pasted |
| 22:07.55 | Agro | maybe its when i increment the pointer |
| 22:08.15 | Corydon76-home | btw, it's better to use a structure with AST_FRIENDLY_OFFSET, so you don't have to copy the memory; you can just use it directly from the frame |
| 22:08.54 | Corydon76-home | What's sptr? |
| 22:09.24 | Corydon76-home | Oh, you can't do that realloc thing with sptr, once you change the value |
| 22:10.12 | Corydon76-home | The ptr you pass to realloc MUST be a value returned from malloc, or it will abort(). |
| 22:10.53 | Corydon76-home | And realloc returns a value; you MUST receive it. |
| 22:11.29 | Corydon76-home | Because once you realloc, it's possible (even likely) for the new pointer to be in a completely new location. |
| 22:12.45 | Corydon76-home | Memory management aside, the reading of the frame values is otherwise correct. |
| 22:22.25 | *** join/#asterisk-dev Agro (~Agro@108-79-20-223.lightspeed.hstntx.sbcglobal.net) |
| 22:22.35 | Agro | sorry Corydon76-home, is there anything you said after i quit? |
| 22:22.55 | Corydon76-home | Agro: Not after you quit, but it was a timeout, so it's possible, quite a lot |
| 22:23.03 | Corydon76-home | Agro: what's the last thing you saw? |
| 22:23.09 | Agro | What's sptr? |
| 22:23.17 | Agro | then i said i forgot to change that to dataptr |
| 22:23.34 | Corydon76-home | Everything about your memory management is wrong. |
| 22:23.55 | Agro | oh, how? |
| 22:24.07 | Corydon76-home | 1. You cannot change the value you receive from malloc; that value MUST be placed intact back into realloc(). |
| 22:24.58 | Corydon76-home | 2. You must receive the value back from realloc(), verifying that it is not NULL (return value), because the location of your memory segment can (and probably will) change. |
| 22:25.22 | Agro | ok, but what do i do if it is null? |
| 22:25.39 | Agro | quit the script i guess |
| 22:25.52 | Corydon76-home | free() the last successful returned ptr and exit |
| 22:26.16 | Agro | ok, and what am i doing wrong with the malloc and realloc? didnt quite understsand because ive never used realloc |
| 22:27.02 | Corydon76-home | The value you get back from malloc (or realloc) is special. Yes, it's a memory location, but that value MUST be passed back into realloc or free |
| 22:27.38 | Agro | oh, if i ever want to use it again ok |
| 22:27.39 | Corydon76-home | Internally, the library uses that value as a handle, which it looks up into a table. If the value isn't in the table, it assumes memory corruption and abort()s |
| 22:27.54 | Agro | ah thats why |
| 22:28.45 | Corydon76-home | There's only one value that you can safely pass to realloc that isn't a memory segment, and that's NULL. |
| 22:29.05 | Agro | oh |
| 22:29.08 | Corydon76-home | and when you pass NULL to realloc, it behaves identically to malloc() |
| 22:30.07 | Agro | ohh ok ok |
| 22:54.02 | Agro | Is tehre a quick function I can write for an asterisk module to reload the module ? |
| 23:01.45 | Agro | Corydon76-home, to debug an error after I put all the realloc stuff in, I logged the length of the frame data, most of them are 320, but a few are 7864616 and they are crashing the code |
| 23:28.05 | kpfleming | Agro: are you sure those frames actually contain data? are they AST_FRAME_VOICE? |
| 23:28.17 | Agro | yeah getting the code |
| 23:28.57 | Agro | kpfleming, http://pastebin.com/qYXTLhvj |
| 23:30.18 | kpfleming | your math is wrong. f->datalen is the number of bytes in the frame's data, not the number of samples. f->samples is the number of samples. |
| 23:30.46 | Agro | oh i have to replace all instances of f->datalen with f->samples? |
| 23:30.52 | kpfleming | i don't know |
| 23:30.58 | kpfleming | but you certainly do in the realloc() call |
| 23:31.30 | Agro | okay, that means i have to do it throughout the whole loop |
| 23:31.33 | kpfleming | and you can't increment dataptr if you are going to pass it to realloc() again |
| 23:31.41 | kpfleming | no, it does not mean that |
| 23:31.49 | Agro | well i use it in the same way |
| 23:31.57 | kpfleming | you do? |
| 23:32.15 | kpfleming | you don't see the differnce between the call to realloc() and the call to memcpy()? |
| 23:32.27 | Agro | wait but cant i do that? |
| 23:32.35 | kpfleming | do what? |
| 23:32.44 | Agro | realloc and increment |
| 23:33.04 | kpfleming | no. if you increment the pointer, it no longer points to the beginning of the block, and is not a valid value to pass to realloc(). |
| 23:33.11 | kpfleming | Corydon76-home told you this earlier |
| 23:33.33 | Agro | how do i get everything inside one block of data then? |
| 23:33.47 | kpfleming | there are a *lot* of problems with this code, and unfortunately there are problems with your understanding of C that I don't have time to try to correct |
| 23:34.07 | Agro | well, ive never dealt directly with C |
| 23:34.25 | kpfleming | converting a stream of frames into a single block of data will be somewhat difficult, but this approach won't work |
| 23:34.25 | Agro | i mostly use C++ but it looks like I have to use C |
| 23:34.25 | kpfleming | yes, i can see that :_) |
| 23:34.52 | Agro | ill think up of something else then |
| 23:37.48 | kpfleming | what you want to do can certainly be done, but you'll need to learn some C to understand how to do memory management |
| 23:38.17 | kpfleming | but generally, if you are looking for a tone in an audio stream, you don't need to collect all the audio from the stream, you can do it frame-by-frame until you see a result |
| 23:51.46 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 23:51.46 | *** mode/#asterisk-dev [+o file] by ChanServ |