| 00:05.44 | *** join/#asterisk-dev serafie (~erin@user-24-214-173-250.knology.net) |
| 00:14.32 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-uxfqjswvrdmrvqdj) |
| 00:31.42 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 00:31.42 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 00:32.06 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-xtovfzppihzegydc) |
| 00:32.06 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 00:54.29 | WIMPy | Ok, if anyone is interested in some rather strange results regarding timing, you may want to read http://wimpy.yeti.dk/pastebin |
| 00:55.01 | WIMPy | I wanted to find out about the timing of AstDB writes, but instead I found out about timing related to channeltype. |
| 00:55.14 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |
| 00:56.39 | WIMPy | Maybe I should re-test with the current trunk version as that seems to be a lot more extreme, but it may or may not be related. |
| 00:58.22 | Marquis42 | WIMPy: Interesting results. I don't think I have anything intelligent to add to the conversation, but strange indeed. |
| 01:15.00 | *** join/#asterisk-dev serafie (~erin@user-24-214-173-250.knology.net) |
| 01:24.28 | *** join/#asterisk-dev italorossi (~italoross@187.61.168.117) |
| 01:27.46 | WIMPy | I added results for the current version. The results are quite interesting as well. |
| 01:30.16 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-xtovfzppihzegydc) |
| 01:34.32 | WIMPy | Wrong conclusion. i forgot the factor 4. |
| 03:47.53 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 03:47.53 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 05:07.00 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.204) |
| 06:32.06 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 06:32.06 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 07:12.30 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:c76:33e7:8943:1fb0) |
| 07:28.00 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.204) |
| 07:50.07 | *** join/#asterisk-dev bulkorok (~chatzilla@85.183.61.47) |
| 08:31.31 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.204) |
| 09:32.33 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.243) |
| 09:55.50 | *** join/#asterisk-dev vlad_starkov (~vlad_star@195.239.220.131) |
| 09:57.07 | *** join/#asterisk-dev vlad_sta_ (~vlad_star@212.44.137.202) |
| 09:58.31 | *** join/#asterisk-dev vlad_starkov (~vlad_star@195.239.220.131) |
| 11:10.44 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 11:10.44 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 11:32.08 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 12:18.28 | *** join/#asterisk-dev vlad_starkov (~vlad_star@195.239.220.131) |
| 12:34.54 | *** join/#asterisk-dev vlad_starkov (~vlad_star@195.239.220.131) |
| 12:56.32 | *** join/#asterisk-dev vlad_starkov (~vlad_star@195.239.220.131) |
| 13:10.20 | *** join/#asterisk-dev spditner (~simon@206-248-134-4.dsl.teksavvy.com) |
| 13:29.29 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-xhnttzsocrgqzyes) |
| 13:41.33 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-kswnuzcswpbtcfkk) |
| 13:48.13 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 13:50.00 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:50.00 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:22.20 | file | opticron, are you going to update the CLI/AMI commands review? |
| 14:28.06 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-idctgxrbkpyiqbyw) |
| 14:34.44 | opticron | I'm in the process right now |
| 14:34.52 | opticron | it was another one that got eaten by the pjsip rename |
| 14:37.00 | putnopvut | leedm777: opticron: I just did a bit of grepping through trunk and noticed there are quite a few RAII_VAR declarations for ast_json pointers that use ao2_cleanup as the destructor. Is that correct? Should they be using ast_json_unref instead? |
| 14:37.40 | leedm777 | putnopvut: that would be wrong, and should fail spectacularly. |
| 14:37.58 | putnopvut | 9 places in trunk. |
| 14:38.09 | putnopvut | I've probably copied that in some of my branches that have not been committed yet. |
| 14:38.13 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.189) |
| 14:38.18 | opticron | fun |
| 14:38.26 | file | yeah that got me in bucket land and then I had to thwap myself so as to remember it in the future |
| 14:38.29 | putnopvut | leedm777: If it's a straight replacement, I'll use some sed magic to fix that up. |
| 14:38.37 | leedm777 | putnopvut: those are ast_json_payload, which is an AO2 object. |
| 14:38.44 | putnopvut | oh |
| 14:38.48 | putnopvut | well peas |
| 14:39.06 | putnopvut | Well, carry on then! |
| 14:39.46 | opticron | file, updated |
| 14:39.50 | file | k |
| 14:40.03 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.189) |
| 14:40.59 | opticron | wanders off to recover res_sip threadpool options |
| 14:41.12 | putnopvut | res_sip? What's that? |
| 14:41.50 | opticron | no idea |
| 14:41.56 | opticron | but it's in one of my branches |
| 14:42.09 | opticron | or was, anyway |
| 14:43.55 | leedm777 | renames res_pjsip to res_u2615 |
| 14:44.45 | Marquis42 | lol |
| 15:01.06 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.189) |
| 15:09.46 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:09.47 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:10.50 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 15:10.50 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 16:09.31 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189-25-41-60.user.veloxzone.com.br) |
| 16:33.43 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.189) |
| 16:42.49 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.75) |
| 17:20.02 | WIMPy | O, so I guess most of you didn;t see it yesterday evening, but I made some more tests and the result is that current trunk versions have a severe performance issue in dialplan processing of about |
| 17:20.11 | WIMPy | factor 4 to 10. |
| 17:20.20 | WIMPy | http://wimpy.yeti.dk/pastebin for the story and the results so far. |
| 17:21.20 | WIMPy | So th eunexplained dialplan lookups leading to dundi lookups were not the real issue. |
| 18:20.47 | seanbright | hmmm, so just got a new batch of transcoder cards |
| 18:21.16 | seanbright | one of the packages has a resistor rolling around loose in the packaging |
| 18:21.21 | *** join/#asterisk-dev mjordan1 (~mjordan@nat/digium/x-ddbyesyhmlfocpwz) |
| 18:21.21 | *** mode/#asterisk-dev [+o mjordan1] by ChanServ |
| 18:36.09 | leedm777 | gets lost in file's bucket review |
| 18:36.31 | file | gives leedm777 a map |
| 18:36.32 | mjordan1 | there's a joke in there |
| 18:37.59 | file | leedm777, I hope that once in it will make ARI even more awesome! |
| 18:38.17 | leedm777 | file: as do I |
| 18:39.21 | Marquis42 | I will openly admit to being excited about it. :) |
| 18:39.47 | mjordan1 | Marquis42: and I haven't forgotten about MWI. Feature freeze just sort of preempted everything else :-) |
| 18:40.20 | Marquis42 | Understood, no worries. Thanks! |
| 19:02.50 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.43) |
| 19:02.53 | putnopvut | WIMPy: so I can partially explain some of the behavior you saw in your test you linked to. When performing a loop of Set() calls, nothing is servicing the media on the channels. So as you would have seen, audio frames either fill some buffer or otherwise are not read during the time you are iterating. As far as *why* the sets are taking so much longer in trunk, I'm not sure. |
| 19:03.23 | putnopvut | One thing that has not been changed much at all is the PBX execution. Bridging can't play into what you're seeing since no bridge is created for a one-way call. |
| 19:04.20 | putnopvut | And in a loop of Set() calls, the only thing running is the PBX. There are no channels being created. There aren't really anything being created. |
| 19:04.41 | file | well, snapshots |
| 19:05.53 | putnopvut | during Set calls? |
| 19:06.31 | file | as it moves through the dialplan, and Set calls |
| 19:06.57 | putnopvut | Hm, are the snapshots created in the PBX thread? |
| 19:07.11 | file | yes |
| 19:08.09 | putnopvut | Yep, indeed. |
| 19:09.32 | putnopvut | So WIMPy. A test to try: in main/pbx.c, comment out the call to ast_channel_publish_varset() and see if your test has improved performance. |
| 19:19.01 | mjordan1 | was the test run between 11/trunk or just between channel drivers? |
| 19:23.40 | putnopvut | It's always scary when you have an automerge conflict to resolve in your branch when there's been a tonne of changes/renames going on. In my case, the lone conflict was in the CHANGES file. |
| 19:23.44 | putnopvut | I'm okay with that. :) |
| 19:24.11 | leedm777 | putnopvut: what's scary are the changes that should have conflicted, but didn't |
| 19:24.30 | putnopvut | Indeed. |
| 19:24.37 | putnopvut | In my case, I didn't actually expect conflict at all. |
| 19:24.39 | leedm777 | I've had several cases recently where I would have expected at least a tree conflict, and svn happily merged away my changes. |
| 19:24.47 | putnopvut | Yay! |
| 19:25.38 | leedm777 | Then I had the other case where my merge resulted in a no-op change to a file, and it gave me a tree conflict anyways. |
| 19:34.00 | file | you two disappoint me |
| 19:34.08 | file | you were *1* away from a total of 42 |
| 19:36.42 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 19:36.42 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 20:11.44 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 20:11.44 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 20:14.05 | opticron | leedm777, is there a sorcery equivalent to your suggestion for implicitly creating a config section with defaults using aco_set_defaults()? I didn't see one from my searching, but I may have missed it |
| 20:15.06 | file | there is not |
| 20:15.39 | file | (at least at sorcery level) |
| 20:17.34 | opticron | I guess I could always detect if an object of that type was created and if not, create one and populate it with defaults, but that sounds like quite a bit more work for the same result |
| 20:20.03 | opticron | and possibly still having to set the results in two place |
| 20:20.03 | opticron | s |
| 20:20.25 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.236) |
| 20:20.35 | opticron | s/results/defaults |
| 20:22.37 | newtonr | pabelanger: Was your patch for ASTERISK-21966 still in progress? |
| 20:23.24 | pabelanger | newtonr: that fax? |
| 20:23.43 | pabelanger | leifmadsen: where is your bot? |
| 20:23.54 | newtonr | pabelanger: yeah your summary was "When FXS detects a fax, we should also disable callwaiting" |
| 20:24.04 | pabelanger | newtonr: Ya, still need to post that online |
| 20:24.10 | pabelanger | have it locally some place |
| 20:26.05 | newtonr | pabelanger: sweet! throw a reviewboard link on there when you get it on there, or let me know and I'll link it. |
| 20:26.41 | pabelanger | trying to finish up a contract, should have more time in the next week or two |
| 20:27.20 | newtonr | pabelanger: Okie dokie. I re-cycled the Feedback state so I shouldn't bug you again for another two weeks :D |
| 21:02.31 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 21:05.44 | leedm777 | file: do you have any objections to this patch? The empty regex doesn't compile on OS X. https://gist.github.com/leedm777/6135304 |
| 21:07.46 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |
| 21:08.19 | leifmadsen | pabelanger: might be down |
| 21:08.48 | leifmadsen | pabelanger: certain chars will crash it, I have some fixes on my bot at work (which is the same bot with tweaks for our own jira) but I haven't had a chance to merge them upstream |
| 21:11.31 | file | Nope |
| 21:31.45 | mjordan1 | putnopvut: file: leedm777: quick naming question |
| 21:32.05 | mjordan1 | we have ast_bridge_features which are features for channels in a bridge |
| 21:32.17 | mjordan1 | we have bridge_basic, which is a terrible name, as it is a bridge that understands and uses features |
| 21:32.29 | mjordan1 | unfortunately, ast_bridge_feature[s] runs into naming conflicts fast |
| 21:32.49 | mjordan1 | how do y'all feel about bridge_feature_bridge or bridge_features_bridge or something along those lines? |
| 21:32.52 | putnopvut | ast_bridge_that_enables_features_to_be_used |
| 21:33.17 | putnopvut | I'm fine with the channel one being ast_channel_bridge_features |
| 21:34.22 | mjordan1 | ohs nos |
| 21:34.31 | mjordan1 | I was hoping to avoid renaming that. It gets.... pervasive. |
| 21:34.39 | leedm777 | I'm meh about 'bridge' showing up twice in the same name. |
| 21:34.50 | putnopvut | ditto, bro |
| 21:35.14 | mjordan1 | I don't like that either. |
| 21:35.41 | mjordan1 | OR. |
| 21:35.51 | mjordan1 | I just punt and we keep the increasingly inaptly named "bridge_basic" |
| 21:36.02 | mjordan1 | sort of like a certain trilogy that is 5 books long |
| 21:36.39 | leedm777 | It makes sense, in the same way that any protocol that has 'simple' in its name is in no way simple. |
| 21:37.06 | mjordan1 | snarky comments shall be added |
| 21:38.34 | mjordan1 | FYI: the best part is that some bridge_features is defined in bridge_basic.h |
| 21:38.38 | mjordan1 | HILARITY |
| 21:42.07 | jsmith | Seriously? |
| 21:43.36 | mjordan1 | jsmith: the features bridge thing? |
| 21:43.43 | jsmith | mjordan1: Yeah... |
| 21:43.48 | mjordan1 | Yeah. |
| 21:44.21 | mjordan1 | In its defense, the 'basic bridge' was basic at one point |
| 21:46.00 | jsmith | Yeah, and common sense was common at one point too :-p |
| 21:48.05 | mjordan1 | well, right now we have "ast_bridge_basic", which is rather feature-ful and is about is Simple as SOAP, or "ast_bridge_feature_bridge" or "ast_bridge_bridge_feature", both of which make my eyes sad |
| 21:48.24 | mjordan1 | longs for namespaces |
| 21:48.44 | putnopvut | ast_features_bridge works as long as you don't mind it not starting with ast_bridge_ |
| 21:49.00 | mjordan1 | yeah.... |
| 21:49.13 | mjordan1 | That is possible. I'll mull it over while I break beer with Qwell |
| 21:49.20 | putnopvut | okay |
| 21:49.26 | mjordan1 | putnopvut: coming? |
| 21:49.37 | mjordan1 | jsmith: I'd take suggestions if you want to have a dog in the fight :-) |
| 21:49.42 | putnopvut | mjordan1: yes |
| 21:49.51 | putnopvut | I may as well just stop where I am. |
| 21:49.52 | mjordan1 | but luckily, this will be very hidden from the users. It's just pickiness in the API |
| 21:49.55 | mjordan1 | same here |
| 21:50.01 | putnopvut | Stopping point isn't easily reached within the next couple of minutes. |
| 21:50.30 | file | Hack the planet! |
| 21:50.42 | jsmith | mjordan1: ast_bridge_common_feature_bridge? |
| 21:50.45 | jsmith | ducks and hides |
| 21:50.52 | mjordan1 | jsmith: better than my suggestion |
| 21:51.10 | mjordan1 | happy one-day post feature freeze everyone - drink beer and be merry :-) |
| 21:51.11 | mjordan1 | later |
| 21:51.17 | jsmith | Cheers! |
| 21:51.19 | putnopvut | ast_bridge_that_allows_features_to_be_used_by_channels_that_have_had_the_proper_permissions_set_prior_to_entry_into_the_bridge |
| 21:51.27 | mjordan1 | putnopvut: +10 |
| 21:51.29 | *** part/#asterisk-dev mjordan1 (~mjordan@nat/digium/x-ddbyesyhmlfocpwz) |
| 21:51.33 | file | I will code instead, kthx |
| 21:57.13 | jsmith | file: Just as long as you're working on res_bucket_odbc :-p |
| 21:59.09 | file | nope! |
| 22:06.09 | WIMPy | Now putnopvut is also already gone. :-( Isn't it some rather fundamental issue if we just jet media frames queue up while processing the dialplan? |
| 22:06.52 | WIMPy | Im mean it can always take longer than you expect when using (fast)AGI, DB accesses CURL or whatever. And we can't use it later anyway. |
| 22:07.13 | file | some applications that do such things will put the channel into autoservice, which services it |
| 22:08.00 | WIMPy | Shouldn't that always happen, unless the application handles it? |
| 22:08.27 | file | in a perfect world there would be something servicing the channel at all times |
| 22:08.31 | WIMPy | In the current situation it showed during normal use. |
| 22:08.51 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 22:09.27 | file | when using a switch autoservice is used |
| 22:09.28 | WIMPy | But the effects of not doing so are quite bad. |
| 22:10.33 | WIMPy | wonders if that could be part of the explanation for race conditions wehn using switches. |
| 22:11.55 | WIMPy | starts to feel like just having had tons of luck when anything ever worked so far. |
| 23:30.12 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 23:30.12 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |