| 00:40.31 | *** join/#asterisk-dev superscrat (~asanders@173-17-133-2.client.mchsi.com) |
| 00:48.26 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-jkqrrftkczyxujhy) |
| 02:22.33 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 02:22.33 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 02:26.21 | *** join/#asterisk-dev sgriepentrog (~sgriepent@2602:30a:2ef2:840:20c:29ff:fe4f:cac8) |
| 02:27.21 | *** join/#asterisk-dev superscrat (~asanders@173-17-133-2.client.mchsi.com) |
| 02:27.25 | *** join/#asterisk-dev Ta^3 (~tacvbo@187.188.107.19) |
| 03:32.09 | *** join/#asterisk-dev jagruti_ (~root@182.70.116.47) |
| 03:32.44 | *** part/#asterisk-dev jagruti_ (~root@182.70.116.47) |
| 07:34.34 | *** join/#asterisk-dev bulkorok (~Benjamin@p5099b1e7.dip0.t-ipconnect.de) |
| 08:11.53 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 08:11.53 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:18.38 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 08:18.38 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:32.24 | *** join/#asterisk-dev Jamuel (~Adium@67.180.156.186) |
| 08:35.02 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:b111:4b:e7f2:db3e) |
| 10:12.03 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 10:12.03 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:37.51 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 11:37.52 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 13:08.46 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 13:28.09 | *** join/#asterisk-dev leedm777 (~leedm777@50-81-28-152.client.mchsi.com) |
| 13:36.52 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 13:36.52 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:41.27 | russellb | just came across some cool features of clang to let annotate functions and variables to do thread safety checks, would be cool for asterisk (if you could build with clang) -- https://github.com/openvswitch/ovs/blob/master/include/openvswitch/compiler.h#L53 |
| 13:41.54 | russellb | that's just some macros in another project that's using them |
| 13:42.10 | russellb | but has a big comment block that explains what they are |
| 13:46.53 | mjordan | that would be handy. |
| 13:47.05 | mjordan | we can sorta compile with clang. |
| 13:47.08 | mjordan | "sorta" |
| 13:47.19 | mjordan | probably should update that patch |
| 13:47.35 | russellb | better than totally blowing up |
| 13:48.16 | russellb | looks like it was attempted in gcc, but they gave up and just did clang -- https://gcc.gnu.org/ml/gcc/2012-04/msg00714.html |
| 13:48.53 | mjordan | that seems to be the pattern these days |
| 14:16.03 | *** join/#asterisk-dev superscrat (~asanders@173-17-133-2.client.mchsi.com) |
| 14:17.03 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:17.03 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:30.25 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 14:30.25 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 14:30.35 | *** part/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 14:43.34 | *** join/#asterisk-dev sgriepentrog (~sgriepent@2602:30a:2ef2:840:20c:29ff:fe4f:cac8) |
| 14:49.47 | *** join/#asterisk-dev superscrat (~asanders@173-17-133-2.client.mchsi.com) |
| 14:57.16 | *** join/#asterisk-dev superscrat (~asanders@173-17-133-2.client.mchsi.com) |
| 15:16.16 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 15:16.16 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 15:23.15 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-rwcvvkofjwysvkaf) |
| 15:23.15 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 15:26.05 | *** join/#asterisk-dev superscrat (~asanders@173-17-133-2.client.mchsi.com) |
| 15:31.46 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-qbfcuhelomibfmrl) |
| 15:35.45 | *** join/#asterisk-dev superscrat (~asanders@173-17-133-2.client.mchsi.com) |
| 15:36.29 | *** join/#asterisk-dev superscrat (~asanders@173-17-133-2.client.mchsi.com) |
| 15:46.25 | mjordan | so, I think we're doing something a little wrong in the bridging core |
| 15:46.49 | mjordan | bridge_make_compatible is supposed to make an incoming channel compatible with the bridge capabilities |
| 15:47.10 | mjordan | where most bridge capabilities are "all audio", except for softmix, who is strange and weird and sits in a corner thinking deep emo thoughts about slin |
| 15:47.22 | mjordan | however, we don't actually make things compatible |
| 15:47.57 | mjordan | we just check to see if the format capabilities are equivalent (not compatible, but equivalent), and if not, we get the first capability off the bridge and set the channel read/write format to that |
| 15:48.03 | mjordan | which has got to be all sorts of wrong |
| 15:48.27 | mjordan | that is, we haven't pick the best format from the bridge capabilities for that channel |
| 15:48.33 | mjordan | we've just picked a random one |
| 15:48.43 | putnopvut | Yeah, sounds like it's quite possible to pick an incompatible format. |
| 15:48.52 | file | 'tis preference order of the channel |
| 15:48.54 | putnopvut | And definitely not the "best" format |
| 15:48.55 | mjordan | well, even if it was compatible, it may be a terrible transcoding choice |
| 15:49.06 | mjordan | file: in this case, it is the preference order of the bridge |
| 15:49.11 | mjordan | best_format = ast_format_cap_get_format(bridge->technology->format_capabilities, 0); |
| 15:49.23 | mjordan | file: another point of thought |
| 15:49.28 | file | nods |
| 15:49.31 | mjordan | when profiling, I noticed that we do a lot of format comparisons |
| 15:49.48 | mjordan | chan_pjsip_read: we do a format comparison on every frame |
| 15:50.06 | mjordan | what's odd about it is that we're merely looking to see if the far device has decided to give us a format that is not in our native formats |
| 15:50.23 | mjordan | however, if our native formats are what is negotiated, then (a) that should never happen; and (b) if it did, the device is an ass |
| 15:51.13 | mjordan | I'm okay with having an 'ah hell, that's bad' condition there, but I think we could short circuit it slightly but doing a native pointer comparison between the format on the frame and the format on the channel, and only bothering with the capability container walk if it is different |
| 15:51.48 | mjordan | because 99.99999% of the time, a device isn't going to change from g722 to ulaw mid-stream - particularly if ulaw wasn't even negotiated |
| 15:52.09 | file | some channel drivers treat nativeformats as all negotiated, some don't |
| 15:52.28 | mjordan | true. In this case, that's what I'm making chan_pjsip do, and so this only applies there. |
| 15:52.34 | putnopvut | What about chan_pjsip in particular, since that's the specific one mjordan was talking about? |
| 15:52.38 | mjordan | I know that block of code exists in lots of places. |
| 15:53.24 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-wolwuqbfejxwxzts) |
| 15:53.28 | file | putnopvut, I have two answers for that... I don't think it used to - but it may now |
| 15:53.43 | mjordan | it doesn't right now, but I'm going to make it do that |
| 15:54.02 | mjordan | because stripping all negotiated codecs out of the capabilities but the most preferred is bad |
| 15:55.11 | coreyfarrell | I want to create an ast_xml_doc with an empty root element <docs/> then load more XML files with each root element as a child of <docs/>. is this possible or am I just crazy? I could probably do it with xmlParseChunk but I'm not sure we can count on that being available to make it a requirement. |
| 15:56.37 | mjordan | hm. |
| 15:56.52 | coreyfarrell | the goal would be to allow each module to supply it's own xmldoc file with <module name=".."> as the root element for the module, then load that as a child of the master doc. |
| 15:56.54 | mjordan | you can do that, so long as the DTD schema supports it. |
| 15:57.04 | mjordan | essentially, you have a DOM, and another DOM |
| 15:57.17 | mjordan | and you take the children of the second DOM and append them to the root of the first DOM |
| 15:57.24 | mjordan | and just keep doing that |
| 16:02.37 | coreyfarrell | hmmm... so I can use ast_xml_add_child to add the root element of child_doc as a child of the root of master_doc, then just destroy child_doc without breaking master_doc? I'll give it a try thanks |
| 16:09.47 | mjordan | well |
| 16:13.44 | coreyfarrell | at asterisk startup I want to effectively open an xml document that could be constructed with the shell script: echo '<?xml-stylesheet type="text/xsl" href="appdocsxml.xslt"?><docs xmlns:xi="http://www.w3.org/2001/XInclude">';cat /var/lib/asterisk/documentation/en_US/*.xml;echo '</docs>' |
| 16:14.59 | coreyfarrell | where en_US/*.xml would be a file for each module, plus core.xml for stuff from sbin/asterisk |
| 16:16.13 | coreyfarrell | each file on it's own would be valid XML, but will contain invalid XPointer includes (pointing to nodes provided by other files). |
| 16:24.49 | mjordan | Hum. |
| 16:24.59 | mjordan | You'll get some wackiness when the XPointers are resolved during loading |
| 16:30.11 | *** join/#asterisk-dev coreyfarrell (~coreyfarr@24-177-3-44.dhcp.nwtn.ct.charter.com) |
| 16:32.07 | coreyfarrell | damn window manager freezed.. last msg I saw was about XPointers being resolved during load.. the plan is to create a function that will open all the child documents before processing XPointers |
| 16:33.42 | *** join/#asterisk-dev leedm777 (leedm777@nat/digium/x-udwqqzwfmaqhoruq) |
| 16:33.53 | mjordan | it may work |
| 16:33.59 | mjordan | it's been awhile since I've looked at when that was resolved |
| 16:34.33 | coreyfarrell | it's part of ast_xml_open |
| 16:42.58 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 16:42.58 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 16:58.00 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 17:15.32 | *** join/#asterisk-dev superscrat (asanders@nat/digium/x-vohgpblwuhdyshbt) |
| 17:22.02 | coreyfarrell | is it ok to use $(eval $(call ...)) in asterisk makefiles? example of what I want to do: http://pastebin.ubuntu.com/10280668/ - I'm open to suggestions for a better way to have a single statement associate additional sources with a module |
| 17:28.12 | mjordan | coreyfarrell: my make-foo is not as strong as others - you might want to hit the -dev list with that and see what others think |
| 17:31.58 | coreyfarrell | I've been meaning to do an email to start discussion about module loader improvements in general, I'll try to get something together this week |
| 17:46.00 | gtjoseph | We should just use systemd for module loading. :-) |
| 17:51.05 | file | glares |
| 17:54.48 | gtjoseph | A cold shiver just ran down my back. |
| 17:56.45 | seanbright | each module becomes its own process |
| 17:56.58 | gtjoseph | there you go |
| 17:57.15 | seanbright | and using message passing means no thread contention |
| 17:57.18 | seanbright | simplifies everything |
| 17:57.40 | seanbright | and then rewrite asterisk in erlang |
| 17:57.42 | file | seanbright, I look forward to seeing your contribution |
| 17:57.46 | seanbright | heh |
| 17:58.52 | seanbright | i just like creating work for others |
| 17:59.00 | file | that being said in the grand scheme of things from a user perspective while there's some annoyances re: dependencies it generally works for them |
| 18:00.06 | gtjoseph | The principle is sound, the implementation leaves a little to be desired. |
| 19:12.14 | pabelanger | Ooooh |
| 19:12.35 | pabelanger | I manage to write a thin test_runner for asterisk using the python unit test library |
| 19:13.23 | pabelanger | Also ported to python tornado :) |
| 19:23.40 | *** join/#asterisk-dev sgriepentrog (~sgriepent@172.56.0.126) |
| 19:28.11 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 19:28.11 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:33.59 | mjordan | so... |
| 19:34.22 | mjordan | pabelanger: I'm not against that, but I'm not sure I want to drop a nuke into the existing test infrastructure |
| 19:34.49 | mjordan | how are you envisioning it being used? |
| 19:36.14 | pabelanger | mjordan, Ya, not sure this is good for upstream |
| 19:36.35 | pabelanger | but, argument could be make to move this back into twisted |
| 19:36.36 | *** join/#asterisk-dev leedm777 (leedm777@nat/digium/x-wgwqilgtscotkhgn) |
| 19:37.17 | pabelanger | My main issue right now with the testsuite, is all the code that sandboxes asterisk and the custom testrunner that's been built. |
| 19:37.35 | pabelanger | While they work and have grown into what we have today |
| 19:37.44 | pabelanger | if I was to do it again, I would likely remove / revisit that logic |
| 19:40.12 | mjordan | There's pros/cons. |
| 19:40.24 | mjordan | It makes a lot of files, but it's very easy for an instance of Asterisk to 'spill over' into other tests |
| 19:43.21 | pabelanger | Ya, I don't have issues how it works today. I would just want change / update certain parts of it. Namely, skipping the section of code that sandboxes asterisk each time a test runs. |
| 19:43.28 | mjordan | How are you planning on preventing a test from leaving 'artifacts' in Asterisk that impact subsequent tests? |
| 19:43.48 | pabelanger | another issue, is remove the dependency on asterisk source code required on the local system |
| 19:44.13 | pabelanger | mjordan, for me, I'm nuking the OS between runs |
| 19:44.27 | pabelanger | and rotating files as needed |
| 20:00.00 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 20:00.00 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 20:09.24 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 20:09.25 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:30.38 | wdoekes | pabelanger: nuking the OS between test runs or between individual tests? |
| 20:31.28 | pabelanger | wdoekes, test runs |
| 20:32.22 | wdoekes | so you reuse one or more asterisk instances for more than one test |
| 20:35.42 | pabelanger | Yes, right now I am just dealing with dialplan unit tests |
| 20:35.49 | pabelanger | so, for each dialplan test |
| 20:35.52 | pabelanger | I create a new channel |
| 20:36.05 | pabelanger | I don't care if asterisk is new or old |
| 20:36.20 | pabelanger | because I only care about what is happening on the new channel |
| 20:36.28 | pabelanger | so, I just rotate logs between channel tests |
| 20:36.30 | pabelanger | and that works |
| 20:43.06 | coreyfarrell | pabelanger: how would a test that requires 2 or 3 instances of asterisk work without a sandbox for each? |
| 20:45.26 | pabelanger | coreyfarrell, I don't need to do that yet. But right now I'm not using asterisk to test against asterisk. Plan to use pjproject / sipp for that |
| 20:45.59 | pabelanger | however, if I needed to launch asterisk to test with asterisk, I'd spin up a 2nd VM / instance and connect remotely to each |
| 20:46.35 | pabelanger | right now, my requirement for the test runner I am doing. Is asterisk is not local to the test runner. So, right now, I'm forced to use AMI for everything |
| 21:07.14 | pabelanger | Now, I really want.... *CLI> dialplan show coverage |
| 21:07.16 | pabelanger | :D |
| 21:08.32 | coreyfarrell | that would be awesome, except I think it would have to be dialplan coverage show |
| 21:09.19 | pabelanger | blitzrage, ^ I cannot remember, what is the format for CLI sytax |
| 21:09.23 | pabelanger | syntax* |
| 21:09.51 | coreyfarrell | pabelanger: the thing with dialplan show coverage is it's already in use... dialplan show <context> |
| 21:10.19 | pabelanger | Ah |
| 21:10.20 | pabelanger | ya |
| 21:10.26 | pabelanger | I see what you means now |
| 21:10.54 | coreyfarrell | plus you would want: "dialplan coverage export" to generate a full report |
| 21:11.35 | coreyfarrell | and dialplan coverage reset |
| 21:45.20 | *** join/#asterisk-dev Jamuel (~Adium@67.180.156.186) |
| 21:58.44 | *** join/#asterisk-dev [TK]D-Fender (~joe@64.235.216.2) |
| 22:24.13 | *** join/#asterisk-dev mbowie (~mbowie@162.212.36.9) |
| 23:22.44 | *** join/#asterisk-dev fornax (~fornax@85.183.43.221) |
| 23:27.40 | *** part/#asterisk-dev mjordan (mjordan@nat/digium/x-rwcvvkofjwysvkaf) |
| 23:35.34 | *** join/#asterisk-dev Trevizoli (bd2fd731@gateway/web/freenode/ip.189.47.215.49) |
| 23:50.32 | *** part/#asterisk-dev Trevizoli (bd2fd731@gateway/web/freenode/ip.189.47.215.49) |